The transition to migrate Kubernetes to AWS presents organisations with an opportunity to enhance scalability while streamlining maintenance. Operating on-premise Kubernetes infrastructures comes with challenges, particularly in scaling and maintaining individual components. If the system is designed to be tightly coupled, it can hinder independent scaling, often leading to performance bottlenecks and sluggish response times. In some cases, an application hosted on on-premise Kubernetes can lead to having infrastructure that is not used, thereby adding unnecessary costs. However, with the emergence of AWS Serverless and its modern technologies, businesses are breaking free from legacy constraints and embracing a more agile and cost-effective approach.

Insights from the migration process

On-premise Kubernetes to AWS Serverless migration was the subject of a recent podcast hosted by Devoteam. Prabhat Handoo, the host, spoke with Robert Lotter, a lead DevOps and AWS consultant at Devoteam. They discussed helping a large organisation in Germany transition from on-premise Kubernetes to serverless on AWS. During the episode, Robert offers advice on overcoming migration obstacles. He also discusses techniques for achieving success.

Key components for migrating Kubernetes to AWS and their significance

• Core Service:
  • The heart of the system consists of an HTTP service.
  • This service features complex business logic.
  • It must run 24/7 without downtime or failures of essential services.
• Sync Service:
  • Synchronises data from an external data source to a local database.
  • This service is crucial as the database supports all business logic.
• Simulation Services:
  • Used for testing and simulating campaigns.
• Front-End Application:
  • Allows customers to configure settings.
  • Supports log visualisation, testing, and other functions.
• Database:
  • In this case, the system uses a PostgreSQL database.
  • The database is critical; the system cannot function without it.
  • The customer originally used a PostgreSQL server on-premise for this setup.

Discovering and assessing the customer’s infrastructure

The existing infrastructure has been running for a few years using this design. All applications are hosted as Docker containers on the Kubernetes cluster. However, redundancy is an issue. For example, both integration and production environments had two complete clusters for high availability. This costly undertaking shared a Jenkins server with other teams and projects. Furthermore, a Harbor artefact registry stored Docker images shared by other teams. The customer provided it, but the database cluster also ran on dedicated VMs, managed by us. This setup created pain points.

Recognising the need for cloud-native services

If we undertook this ten years ago, the setup would have seemed adequate. However, as cloud technology has emerged, organisations are moving towards cloud-native services. Amazon offers three services: EKS, ECS, and Fargate. During our research, we discovered scaling issues with the customer’s shared resources. The costs for running on-premise were relatively high. The customer spent approximately $10,000 per month on-premise, while on AWS, it is only about $2,000. This represents significant cost savings.

Resolving initial challenges when migrating Kubernetes to AWS: Customer issues and solutions

We faced redundancy and high costs regarding the clusters during our effort to migrate Kubernetes to AWS. Many applications ran on idle nodes due to infrequent use. For instance, simulation services resulted in high costs and unused resources. Lambda effectively solved these pain points. Lambda is a serverless function that runs entirely without dedicated servers.

Regarding the CI/CD process, we dealt with long builds and interruptions due to other teams. This issue disappeared with the dedicated AWS code pipeline. Additionally, the Docker registry caused connection problems, which we resolved with Lambda..

The most significant pain point involved the database, which did not scale automatically during our migration to AWS. We encountered problems, as patching database servers caused downtimes. The setup and maintenance of the database were challenging. Using Amazon RDS resolved all these issues.

AWS setup for migrating Kubernetes to AWS: Unveiling the range of services and architecture

We used numerous AWS services like VPC, security groups, and IAM roles for this project. This high-level architecture overview reveals the entry point for clients, secured by a web application firewall. The light blue path, represented by CloudFront distribution, ALB, and S3, leads to an API Gateway that calls our main service. Additionally, we incorporated event-driven architecture to trigger Lambda functions based on event bridge events. The back-end code is deployed as a Lambda function, so no server runs on our side.

Serverless technologies versus microservices and containers for migration

Organisations pursue a highly available and cost-effective solution. The customer has already seen benefits from running their infrastructure on AWS. The services we discussed are all AWS native, which simplifies the process. Instead of using third-party tools for CI/CD, we opted for code pipeline, which worked perfectly.

Setting up Monitoring and Alerting for the Project

For example, we also set up alarms with Cloudwatch and SNS to send email notifications in case of errors in place of unexpected behaviour, which is also done serverless. So you don’t need to provide servers or listeners; you configure your alarms and are ready to go, which is impressive. The team did the entire infrastructure build and the backend development of the application.

Setting up monitoring and alerting for the project

We also set up alarms with CloudWatch and SNS. These alerts send email notifications in case of errors or unexpected behaviour, all managed serverlessly. This means we do not need to provide servers or listeners; we simply configure our alarms and are ready to go. Our team handled the entire infrastructure build and backend development of the application.

Application code adaptations: Enabling seamless integration with Lambda

We took full responsibility for changing the application code to work with Lambda. Fortunately, the necessary modifications were minimal, making the process straightforward overall.

Customers often express concerns about re-platforming and re-architecting without access to the original developers. This situation makes understanding the existing code challenging. However, discussing innovation and modernising infrastructure requires touching code that is even currently running.

Customer involvement: Who drove the majority of the work?

The customer provided essential support in understanding the business logic. Regarding infrastructure, we approached the project from an architectural standpoint.

What did we achieve?

With this large enterprise from Germany, we achieved numerous significant results. The customer now has a more highly available infrastructure. We reduced costs by approximately 80%. The monthly cost for Lambda is only around $20. Scalability also improved, as Lambda provides thousands of concurrent connection executions. The performance of the database with RDS has increased as well. Since we use more managed services, AWS handles maintenance, freeing us from the burden of patching.

Moreover, we prioritised sustainability. Using AWS proves to be a far more sustainable solution compared to on-premise setups. In 2021, AWS reported that 95% of its energy came from renewable sources.

How can customers get started?

At Devoteam, we offer a Migrate Kubernetes to AWS programme designed to modernise your operations. As AWS’s migration partner of the year, we collaborate with teams across France, Germany, Belgium, Italy, and the UK. Our Migrate to Modernise programme includes workshops with your teams to assess your needs. We provide a detailed report outlining the optimal path for migrating to AWS. The migration plan and cloud strategy are tailored specifically to your requirements.