Infrastructure Migration

The entire JIRE platform was running on a single CentOS instance on a Linode virtualized server.

This made things like Scalability, background processing and database optimization nearly impossible and things like zero downtime deployment, disaster recovery and file storage a constant challenge.

With growing usage and functional requirements, Gunner proposed to migrate the JIRE to AWS, which would increase hosting cost but reduce overall resource cost, allow JIRE to grow and increase performance of the existing product.

Gunner inherited the old infrastructure on Linode, so there was a lot of undocumented quirks about the architecture that we had to straighten out during the migration process.

One of the most important goals of this project was to remove the need to have someone constantly monitoring and managing the architecture.

Secondly, JIRE had requested a number of feature enhancements to their platform that just couldn't be accomplished with the old setup.

Thirdly, load times and asset storage were becoming a big problem for the same reason: JIRE requires a lot of high-res images to provide users with the best possible experience.

However, we were constantly running out of disk space on Linode and we didn't have a separate asset server so the assets were being served via the same reverse proxy (nginx) that proxied the web app requests.

To address this, we moved all asset storage to AWS S3, which gave us unlimited space and served the assets through AWS' CDN Cloudfront which allowed for excellent caching and distributed request fulfillment across the globe.

Finally, we wanted to automate and future-proof the infrastructure so we would not have to migrate again in the future.

To achieve these goals, we made Elastic Beanstalk the lynchpin of the new architecture.

By doing so, we checked off all of the boxes, including auto-healing and auto-Scalability.

We used an Agile Scrum approach to this project.

The important thing about migrations is that they're repeatable and recoverable because it's a trial and error process to get them to work 100% from start to finish.

To accomplish this, we coded DevOps tools that leaned heavily on the AWS SDKs and APIs.

This mean that our first few sprints were focused on developing these tools and then our remaining sprints were spent doing dry runs to a staging environment until the tools worked perfectly 100% of the time.

From the lack of documentation from the old infrastructure, we re-learned (or were re-enforced) the importance of standards, process and documentation.

The AWS Well-Architected Framework provides architectural best practices across the five pillars for designing and operating reliable, Secure, efficient, and cost-effective systems in the cloud. The framework provides a set of questions that allows you to review an existing or proposed architecture. It also provides a set of AWS best practices for each pillar.

While this is specific to AWS, every framework or infrastructure should abide by these principles.

JIRE has had zero downtime since the transition and, in the years since, their bill has not increased by a single cent.

Gunner Technology is an AWS Preferred Partner and has done hundreds of migrations.

JIRE was an existing client, so it just made sense.