Who is our client and what do they do?

A leading fintech company based in the US, our client’s platform connects retailers with lenders to help consumers get the best financing. Our cooperation with them is one of the longest-running at STX Next to date—ongoing for more than seven years and counting.

Over the years, our team has provided a number of services for the client, including frontend and backend development, automated testing and quality assurance, and last but certainly not least, DevOps services.

Everyone working on the client’s platform at STX Next was at least to some extent involved in this particular project of infrastructure migration to the cloud, cooperating closely with their existing team.

Pre-migration overview of the client’s infrastructure

The solution our client had been working on and actively using for several years was an on-premise model based on VMware. They had two separate DCs (Data Centers) located in different states in the US. The connectivity between those DCs was managed by Cisco ASA Firewalls.

Together with the client, we were able to divide their environments into three separate groups: production, corporate, and development. Production resources were deployed in both DCs as active and standby. All the development and corporate resources were located next to the production ones with segmentation managed by Firewalls.

All of the client’s workloads were deployed to run on dedicated servers as multiple instances for specific purposes: Docker nodes with all the applications (we used Docker Swarm orchestration here), databases, load-balancing solutions, etc.

Did we identify any serious issues with our client’s existing infrastructure?

Based on the solution we had come up with, a lot of limitations and problems were identified:

  • hardware end of life—most of the hardware in both DCs was approaching or had reached the five-year usage point;
  • unreliable hardware—the client had already faced two significant and unexpected failures with a long incident response;
  • capacity limits—limited scalability for the whole platform, which is crucial for day-to-day business operations;
  • limited and untested redundancy—Cisco ASA Firewalls connection and part of the solutions deployed on top of virtual machines;
  • databases running on virtual machines with limited performance, reliability, and redundancy;
  • maintaining physical data centers, including maintaining servers and internet circuits, as well as internal audits, which took a lot of time;
  • lack of some hardening standards with a fairly limited patching process;
  • missing IaC (Infrastructure as Code) mechanism;
  • a lot of other, minor ones.

What did we do to prepare for migrating the client’s infrastructure to the cloud?

After a lot of discussion and taking into account the issues listed above, we made the decision to go with a public cloud solution, choosing Amazon Web Services as the cloud service provider for our client.

Working together, we spent a few months testing the migration of production workloads. Full regression testing was repeated in a few cycles. Based on our findings, we were able to prepare the infrastructure and applications to be deployed onto the AWS environment.

The migration itself was divided into several parts. We moved the production workloads in two separate maintenance windows: the standby one first, followed by the active one. All the development and corporate resources were being deployed in parallel.

The strategy used for the move was more similar to a complete redesign rather than a simple migration, since AWS gave us a lot of possibilities with its rich base of managed services. It was a great opportunity to deploy those services from scratch and replace some legacy ones running on top of VMware instances.

How did we structure our client’s new DevOps infrastructure?

The client’s new cloud environment consists of three separate accounts for production, corporate, and development workloads.

Each of these accounts uses at least a few AWS regions that contain specific workloads based on a predefined architecture, which should ensure full HA (High Availability).

All three environments are based on the Virtual Private Cloud solution, which helps us configure availability zones and logically isolated networks. What’s also important here is that they have a modular and scalable architecture.

Each VPC includes all the necessary, pre-defined resources, like EC2s, load balancers, security groups, etc. Most of the applications run on top of Docker Swarm nodes.

For the entire infrastructure, we’re using IaC based on AWS CloudFormation. All of the stacks, resources, and services are defined in YAML files, located in the Git repository, and adopted with the best practices, ready to provision them at any time.

Which AWS Managed Services and features did we use to set up the cloud infrastructure for the client?

As mentioned earlier, from the moment we decided to settle on Amazon’s public cloud solution, we’ve been actively using AWS resources. It’s been a tremendous operational improvement for our client’s whole organization.

Here are a few notable examples of the specific DevOps services we’re using for the client’s cloud environment configuration:

  • Amazon Aurora—relational database engine that combines high performance with availability and allows our team to use MySQL clusters,
  • Amazon MSK—multiple and fully redundant Kafka clusters for streaming data,
  • Amazon ElastiCache—multiple and fully redundant Redis clusters with enabled encryption,
  • Amazon Elastic Load Balancing—multiple application and network load balancers used for distributing traffic across multiple EC2 instances inside specific clusters,
  • Amazon Auto Scaling Groups—monitoring and automatic scaling of our EC2 clusters with high performance.

One of the main reasons behind our choosing AWS for the migration was to have all the development and test environments as a full mirror of the current production environment. The AWS ecosystem allows us to do that in a rather straightforward way using built-in mechanisms.

7 key benefits of using Amazon Web Services for our client’s DevOps cloud migration

Migrating the client’s infrastructure delivered a number of benefits that both our team and the client have observed in their day-to-day operations. Moving the DevOps infrastructure to AWS completely redefined our client’s business.

1. Optimal business fit

Thanks to its easily scalable and reliable infrastructure, AWS is a perfect fit for most businesses running in the 24/7 model, the way our client does.

2. Significant cost reduction

Our client no longer needs to maintain their own infrastructure and they only pay for the cloud resources they’re using at any given moment, making their expenses much more predictable.

The fact that more and more companies worldwide are actively using cloud services also means that cloud providers continue lowering the prices of their services to the end users.

3. Data security and protection

This is incredibly important for all businesses, and our client is no exception. AWS protects the data stored on the client’s side, with multiple ways of keeping it safe and reliable, based on their needs and the specifics of the stored data.

4. Business and infrastructure scalability

Constant provision and deprovision of resources based on the current environment load and needs is very useful in peak season periods to avoid platform downtime during the most lucrative times.

5. Disaster recovery plan

With the help of AWS Managed Services and their underlying mechanisms, our client is ready for specific failover scenarios through separate active/standby regions.

6. Extra remote work solutions

AWS offers additional, fully managed solutions for working remotely, such as AWS Workspaces, which is a desktop virtualization service.

7. Increased internal development capabilities

Freeing up the resources of internal infrastructure engineers meant less time spent on maintaining the infrastructure and more time for improvements, including future projects like exploring more built-in AWS services.

Aside from the variety of ways in which cloud migration with AWS has already boosted our client’s business, there is still so much improvement potential, such as migrating to ECS (Elastic Container Service) and/or EKS (Elastic Kubernetes Service), automation, or CI/CD processes where AWS is also extremely helpful.

Final thoughts on DevOps infrastructure migration to the cloud with AWS

There are numerous technical and business benefits of migrating your DevOps infrastructure to the cloud using Amazon Web Services.

The team responsible for the migration from an on-premise solution to any public cloud provider needs to be well-trained around cloud solutions, especially in architecture planning, which is the first and most important step before taking any actions related to the migration itself.

Our team of seasoned DevOps professionals at STX Next can fully support your organization with carrying out this entire process. We will plan, test, deploy, and maintain all the resources your project specifically requires.

This particular fintech client isn’t the only company we’ve assisted with their DevOps cloud infrastructure migration. Check out this case study of how our team’s work resulted in a 1,000% performance boost and a 40% cost optimization for a network heating provider based in the UK.

We also have several useful resources on DevOps, ranging from entry-level to highly advanced:

If you’re interested in letting us help you transform your digital product with DevOps cloud migration, all you need to do is reach out to us, and we’ll get right on it!