This blog comprises of 4 parts:

1. Part 1 (This blog) – Choosing the cloud provider
2. Part 2 – Challenges
3. Part 3 – Roadmap to migration
4. Part 4 – Learnings

We hope you find this blog useful as you plan migrations to cloud from in-premise and vice-versa. Do reach out to us at [email protected] to help with your migration needs.

The business scenario

A customer’s business relies on a custom-built enterprise product that serves as the nerve-center of their operations across the USA. The product was deployed on one of the largest cloud providers. As the business was growing, there was a need for infrastructure which would scale as needed and be cost-efficient with effective self-service options.

The Need

The existing cloud infrastructure had frequent outages and the cost of operations was quite high. The self-service features of the cloud solution were minimal resulting in a support case for each instance of resizing and/or addition of servers.

The existing cost model was upfront payment and a yearly subscription, but the customer wanted to move towards a more flexible model governed by the usage and the business need (on-demand).

The most challenging situation was related to database backups. Backups and Restorations were not available as self-service to the customer, as a result, creating new environments and experimentation was severely limited.

Choosing the cloud provider

We chose to move the application to AWS based on the following factors:

1. Costing: For the components we had deployed, we ran a detailed costing sheet using the AWS Pricing calculator. We overprovisioned the current infrastructure by about 50% and projected a yearly increase in traffic, storage and resultant costs. Even after the overprovisioned infrastructure, the costs were significantly lower than the current provider with no upfront costs. This was a significant reason to choose AWS.

2. Support: The customer had experienced AWS support in past projects and the willingness of AWS architects to engage and review our proposals were a huge factor in choosing AWS.

3. Self-Service: On-demand self-service web portal and a rich API to automate all parts of infrastructure.

4. Room to grow: Looking forward a few years, the AWS ecosystem has solutions that the product can leverage to grow. We explored DynamoDB, AWS step functions, Firehose, Kinesis and other solutions that fit into the roadmap as we look ahead and try to solve for growth in traffic and manage the flow of information.

5. Infrastructure as code: AWS provides ways to script the infrastructure as code, with its solution in CloudFormation as well as excellent support for a cloud-agnostic solution such as terraform.

All in all, AWS provided significant cost savings, flexibility and solutions for future use-cases, which resulted in the decision to move ahead with AWS as the cloud of choice to move the customer workload to.

In the next installment, we will explore the challenges and the solutions we implemented to make the move to AWS as smooth as possible.