In today's rapidly changing digital landscape, cloud migration is a key business strategy. Especially for companies that rely on traditional on-premises or private cloud infrastructures, there are often challenges in terms of scalability, operational complexity and speed of innovation. For these companies, moving to the cloud is not just a technical transition, but also a transformative opportunity to overcome these hurdles and unlock new opportunities.
One of our customers from the automotive industry provides an fitting example of this. As part of a customer project, we designed and continuously developed a central system based on Kubernetes in the customer's private cloud from scratch. This system now faced the challenge of being migrated to the AWS cloud.
On-premises system landscape
The system to be migrated is a globally available and highly specialized software that is responsible for a large number of different customer communications and therefore maps important business processes. It was operated in a Kubernetes-based container-as-a-service solution (CaaS) and essentially comprises the following components
- 22 Spring-based microservices
- Database (on-premises MongoDB service)
- Message broker (ActiveMQ)
- Logging and monitoring tools such as Prometheus, Grafana, Logstash and Opensearch
The success of the system depends heavily on its reliability and efficiency. However, the limitations of the on-premises platform gradually became more and more apparent. Problems with scalability, maintenance and technological limitations led to the desire to migrate to the cloud.
Cloud-Migration - a Challenge
However, cloud migration is time-consuming and ties up resources. In day-to-day project business, productivity and revenue generation usually take precedence over maintaining and updating the system landscape. Ongoing development - and thus the creation of new added value for customers and end users - ensures the success of the project and can therefore at best be reduced, but not paused. A “let's do all the migration now” was wishful thinking for us, but this could not be implemented in practice. The challenge of a migration during ongoing operation and continuous further development was therefore a given.
In order to estimate the cost of the migration, the necessary changes to the infrastructure and technologies had to be examined. The costs for operation in the new environment also played a major role. To this end, we analyzed possible runtime environments in the cloud and prepared estimates of the operating costs.
Together with the customer, we discussed the benefits of migration and the associated effort and costs. For example, we were able to offer the customer the prospect of cost savings through the efficient use of cloud resources and productivity gains through the elimination of many maintenance tasks. However, this only applies if the target system is dealt with intensively and the levers provided by AWS are used in the best possible way. Otherwise, the costs of operating in the cloud can sometimes even be higher.
After a cost-benefit analysis and the decision to migrate, the question for us was: when do we take the leap to the cloud?
The time has come!
As is so often the case, the timing was determined by others. There were critical factors that made the decision for us:
First, the lifecycle of the existing on-premises platform and its MongoDB component was coming to an end. By 2025, the on-premises infrastructure would no longer be supported. The MongoDB service was also due to expire by the end of 2024. These impending sundowns made the move to the cloud not just a strategic choice, but a necessity.
Secondly, the growing need for regionally separated data processing, especially in areas with compliance and latency requirements, showed the limitations of the current platform. By moving to the cloud, the system could overcome these challenges with a regionally separated architecture and infrastructure.
Finally, the move to AWS promised significant opportunities for greater flexibility and growth. AWS' robust ecosystem offers a variety of services that fit our needs well - from database solutions to advanced monitoring capabilities.
Unfortunately, not all that glitters is gold. In addition to the many freedoms and possibilities that the cloud offers, the leap into the cloud also means leaving the customer's private space and thus shifting processing and data storage into the hands of a third party (AWS). This results in significantly higher requirements for processing and data security - especially when working with sensitive customer data.
Verification process
In order to meet this high security standard, we went through a verification process in which our system was put through its paces. Almost every element of our system landscape was examined and evaluated in terms of security and data protection.
For example, we ensured that all endpoints are protected by state-of-the-art authentication and authorization mechanisms. Topics such as access control, logging and backup concepts were also scrutinized. There was also a focus on the integration of tools for Static Application Security Testing (SAST) and Software Composition Analysis (SCA), such as Blackduck and Coverity.
Fortunately, this resulted in only a minor need for adjustments, as we have already designed our system to be largely cloud-ready and implemented the latest security standards.
In addition to this verification process, which took us quite some time, we faced another major challenge:
What to do with the database?
Due to the imminent sundown of the MongoDB service, we had to look for an alternative. The choice of databases and services is diverse, but time and budget are tight. After an intensive analysis of our options and one or two tests in the cloud environment, we decided to migrate to the AWS-native DocumentDB.
We will publish a deep dive with analyses and background information on this technology decision in another blog post.
Target infrastructure
Our previous infrastructure essentially consisted of a collection of Kubernetes resources that we stored in versions and deployed via an automated pipeline to set up and change the infrastructure. As we had no authority outside of the Kubernetes cluster through the on-premises CaaS solution, this was a viable solution.
In the cloud, however, it required a more procedural approach to handle the much larger infrastructure scope. So we decided to use Terraform to set up the infrastructure.
This also made it easy for us to duplicate our infrastructure for the multitude of different runtime environments for all regions and stages.
Due to the tight time horizon, we only switched to the most necessary AWS components for the operation of our system. In addition to components to ensure network communication, we mainly used the Amazon EKS (Elastic Kubernetes Service) with EC2 instances, an ECR (Elastic Container Registry), Cloudwatch, S3 buckets and, of course, DocumentDB. A few components, such as ActiveMQ or Prometheus and Grafana, we continue to operate ourselves for the time being.
We also used the opportunity of the migration and the design freedom we gained to make our infrastructure more efficient and cost-effective. For example, we have bundled our container registry and components that ensure communication in the customer's network in a central AWS account instead of setting them up and maintaining them for each runtime environment. We have also decided to no longer keep one of our test stages constantly available, but to start it up dynamically when required. We have also selected the types of EC2 instances according to their task and load and considered the use of AWS Saving Plans or spot instances, which further reduces costs.
The challenge of peripheral systems
Another challenge was posed by our peripheral systems, from which we receive a large number of events. These must be processed by us on time and in full to ensure correct behavior. As our system has to ensure critical customer communication, time deviations or even the loss of events are technically problematic and therefore unacceptable.
The migration meant that downtime could not be avoided. However, when processing started in the new cloud environment, all new and missed events also had to be received in the new system and processed there. This necessitated a parallel supply and subsequent dispatch of undelivered events by the event providers.
In addition, our customer distributes a smartphone app that also accesses our system. Unfortunately, it is only possible to switch to our new environment by deploying a new app version. However, new app versions are usually rolled out over several days. Some customers even deactivate automatic app updates and therefore remain on an old version for longer, which would lose the functionality provided by us after the migration.
To solve this challenge, we decided to point our old domains to the new environment. To avoid downtime due to DNS caches still holding the old address, we also set up forwarding of app calls from the on-prem environment to the cloud. This enabled us to ensure a smooth transition from the old to the new environment.
Creating trust through a proof of concept
All technology decisions had been made. The plan for the target architecture and infrastructure was in place. However, before the full migration was implemented, we carried out a proof of concept to validate the decisions made.
In this phase, we set up the basic AWS infrastructure, checked the required access channels and tested DocumentDB's ability to process production data.
The proof of concept was crucial to identify potential challenges early on. It showed the need to fine-tune the migration process and prepared us for the complexity of new technologies.
Migration Day
Then the time had finally come. The day of the migration had arrived. Although we had already tried out the migration on test stages beforehand, we had never done so together with the migrated production data. It was also unclear whether the migration would work smoothly with all the peripheral systems.
So we started the migration and kept our fingers crossed: the old production system was shut down and the new production infrastructure was started up. The containerized services were deployed and the production data migrated. The peripheral systems also switched over to our new environment as planned. The system went live without a hitch. A complete success!
Many thanks to our colleagues at devlix and teems.it, who actively supported us during the project and the migration work.
