Many minority community-focused financial institutions are late enthusiast to the value of the cloud. In the past few years these companies have realized they need to transform their tech infrastructure and move their legacy core infrastructure to
the cloud. Financial firms need to do this to meet modern consumer expectations and fend off new nontraditional Fintech competitors in the market.
One concern holding up such cloud migrations was concern about data and application portability - i.e., avoiding vendor lock. A Simple Technology Solutions (STS) client in the financial space had completed an initial migration into a cloud hosting environment. Now they wanted to migrate almost all cloud-based services out of that environment and into one that was better suited their use cases.
The client decided to migrate most of its applications and resources out of Amazon Web Services (AWS) and into the Google Cloud Platform (GCP). The client wanted this done as quickly as possible with no operational downtime.
STS began with a static Python code analysis. This process resulted in an architectural dependency graph which identified all the source code that needed to be converted. This allowed STS to make data-driven decisions regarding the migration process. This is the cloud architecture equivalent to personalized medicine, in which an individual’s genetic profile guides decisions made regarding the prevention, diagnosis, and treatment of disease.
Need improvements in cloud structure were identified. For example, the client was doing all its development in a single Amazon virtual private cloud (VPC). This was slowing development and introduced more risk. There was a need for new
environments that could be created with scripts. Automated deployment pipelines and infrastructure-as-code playbooks would enable “push button deployment” for the client so their development teams could go faster. The multiple environments would also increase security by adding firewalls between the systems.
STS Cloud Engineers created a continuous integration roadmap for the application teams. The team developed scripts using Terraform, Ansible, and Jenkins to transform the infrastructure into a Cloud Architecture and Cloud hosting compliant
state. Because STS handled identity access management (IAM) and authorization in an agnostic way, apps and services could run on either or both cloud providers.
Using the dependency graph STS was able to iteratively change, test, insert and move down the migration path. The first focus was on isolated, independent services and modules that could be re-written/converted in an isolated manner, leveraging automated end-to-end tests. Because of a link back to AWS via a multi-cloud VPN, STS was able to change very small sections of the code and test as we go. This also allowed for a parallel running strategy, which allowed testers to compare legacy results with migrated results.
After the first few iterations, STS tackled the source code with lots of dependents – for example utility functions used by multiple modules and services. STS refers to this approach as vertical slicing, and it allows for such end-to-end testing
and parallel run testing. By migrating over large amounts of services before addressing utility functions reduces the risk surface of large cloud migrations.
STS then switched to a horizontal slicing approach – for example, find and replace all instances of S3 and use GCS instead, find all instances of Redshift and use BigQuery instead, etc. Finally, when all services designated for the move were migrated over, STS severed the back-link and validated that all applications were still working.
Running the Google’s Kubernetes Engine, the client can now easily scale applications up and down on demand. Processes can now be automated to scale up late afternoon after market close, then scale down afterwards. This saves IT resources and money.
The client’s core IT was transformed from an incomplete, piece by piece cloud migration to a fully optimized and automated data engine. Some of the benefits realized:
Cost Savings - Reduced costs, increased automation and an optimized cloud modernization lifecycle. Client is spending less for
multiple Production, Staging and Development environments than
they previously had been paying for the single VPC environment.
Improved Security - Security policies can now be built into the
code deployed, for example restricted access to public IP addresses. Security was also improved due to the separate, firewall protected environments created.
Accelerated Development - IT teams can now automate deployments into lower environments, reducing the time from software development to delivery into production. The client now has the computational agility to win in the marketplace.
Successful Multi-Cloud Environment Management - client can now pick and choose which services from AWS or GCP they wish to use, enjoying a “buffet style” approach to various cloud providers.
Faster Problem Solving - IT teams now able to identify and address IT pain points more effectively
Robust Documentation - STS supplied the client with extremely detailed documentation for managing the new environment.
Like what you're reading? Start a conversation by booking a meeting with us today.
If you're looking for best practices and case studies for quickly and securely executing large scale application migration projects, our free eBook, Proven Strategies for Legacy Application Migration, is the resource for you.