Migration considerations – Cloud Foundry to Amazon ECS with AWS Fargate

Introduction

Customers often turn to Amazon Web Services (AWS) to scale their applications, reduce latency, and deploy new features quickly with pay as you go approach. Let’s take the case of customers running hundreds of applications using Cloud Foundry Platform as a Service (PaaS). To achieve cost efficiency, customers can migrate to AWS container services, which makes it easier to manage underlying infrastructure so that customers can focus on innovation and business needs. AWS provides two main services to manage containers: Amazon Elastic Container Service (Amazon ECS) is an AWS opinionated fully managed solution for running containers at scale, whereas Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes platform. This post provides recommendation to customers looking to migrate their applications from Cloud Foundry PaaS to Amazon ECS.

Amazon ECS is a fully managed container orchestration service that makes it easy to deploy, manage, and scale containerized applications. In conjunction with a suite of other AWS solutions, customers can use Amazon ECS to reduce operational overhead, improve deployment cycles, and reduce operational costs. Customer development teams that are used to the relative simplicity of the Cloud Foundry platform may find the low-touch approach of Amazon ECS with reduced complexity appealing. Customers should conduct their own evaluation on which service to migrate to.

Challenges with existing PaaS solution

Customers using Cloud Foundry PaaS face two key challenges:

1. Licensing costs and the licensing model when operating a vendor-distributed Cloud Foundry.
2. Dependency on Cloud Foundry releases to enable new AWS functionality.

To address these challenges, customers can consider moving their applications to Amazon ECS on AWS Fargate. AWS Fargate is a technology used with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, there’s no longer a need to provision, configure, or scale clusters of virtual machines (VMs) to run containers. Customers can build a robust scalable platform with industry best practices for Continuous Integration/ Continuous Deployment (CI/CD) and put in place a repeatable approach for future migrations.

Migration considerations

Customers starting down the migration path from Cloud Foundry should take into account these considerations:

1. Organizational mapping: This includes decision points regarding the use of multiple accounts with multiple Amazon Virtual Private Clouds (Amazon VPC) versus a single VPC per account. With multiple teams involved, it is necessary to have account level segregation and access to shared resources.
2. Manage container images: Decide on how to allow easy and secure way to manage container images.
3. Build and deployment pipeline: Streamline build and deployment pipelines across development, test, user acceptance testing (UAT), stage, and production environments.
4. Traffic ingress: Decide on an Elastic Load Balancer (ELB) allocation strategy for the applications .
5. Service discovery: With multiple applications and multiple service inter-dependencies, having a service discovery mechanism will be crucial for the success of this project.
6. Managing Infrastructure: Ensure the Infrastructure as Code (IaC) could be used across any environment, the configuration definitions are parameterized and injected from an external store.
7. Logging, monitoring, security, and integration with any existing third-party observability tools: If customers are using third-party tools for observability, then it’s necessary to have an ease of integration with the new platform.
8. Environment perimeter: Cloud Foundry provides a mechanism to organize and isolate environments via organizations and spaces, and the challenge for customers is to determine how best to provide a similar construct in AWS given the multitude of options. The solution involves distinguishing between domains and allowing these to be mapped to distinct AWS accounts, which were owned by development teams. Each account had a similar VPC configuration deployed (e.g., via IaC) with AWS CloudFormation. For customers using IaC tooling such as Terraform HashiCorp, teams can share Terraform modules for consistency and repeatability.
9. Amazon ECS launch type: Having selected Amazon Elastic Compute Cloud (Amazon ECS) as the AWS container orchestration service, customers need to decide whether to deploy using the Amazon EC2 launch type or the AWS Fargate launch type. AWS Fargate is a good option to simplify the migration and avoid operational overhead of provisioning VMs for the clusters.

Solution overview

Cloud Foundry PaaS architecture

Many customers migrating from Cloud Foundry PaaS, have application stacks that consist primarily of Java Spring Boot and.NET microservices. These customers may have public facing applications fronted by an Application Programming Interface (API) gateway using Spring Cloud Gateway. Spring Cloud Config server is used to externalize microservice configuration. Netflix Eureka is often used for service discovery. Spring Cloud Circuit Breaker is used to provide circuit breaker implementation. Builds are mostly implemented using tools like Bamboo or Concourse. Deployments to Cloud Foundry may consist of Concourse pipelines that deploy to the platform from a shared Nexus artifact repository using cf push command. Third-party tools are used for logging and monitoring purposes. This is depicted in Figure 1.

Figure 1: Cloud Foundry PaaS architecture

Target architecture with Amazon ECS Fargate

The target architecture consists of Amazon ECS services grouped by domains running in individual AWS application accounts that domain owners manage. The following summarizes the changes:

• Config Server and Eureka services are moved to a shared services account connected to the application accounts through an AWS Transit Gateway and are shared across all services in that environment. Spring Cloud Config server is migrated to an Amazon ECS service, with Eureka deployed to Amazon EC2. Config server is fronted with a private ALB.
• Publicly accessible services are exposed through an ALB. Spring Cloud Gateway hosted on Amazon ECS continue to be used behind the load balancer for intelligent service routing, authentication, and authorization.
• AWS Secrets Manager is used for credential management in addition to encrypted options using Config server.
• Docker image builds were triggered from build processes implemented using AWS CodePipeline and AWS CodeBuild with image security scans.
• Continuous deployment is implemented using a standardized AWS CodePipeline that deploys to Amazon ECS using either rolling deployments, or AWS CodeDeploy blue green deployments.
• Observability is handled through Amazon CloudWatch Logs for logs, AWS Distro for OpenTelemetry for tracing, Container Insights, and third-party tools for monitoring.

The overall architecture is depicted in Figure 2.

Figure 2: Target architecture

Based on our experience on working with customers on their migration journey, we provide the following recommendations for migration to Amazon ECS.

Application migration recommendations

• Externalized configuration: Customers often use Spring Cloud Config to manage external configs in Cloud Foundry PaaS. Customers can deploy this service to a standalone Amazon ECS service with autoscaling and internal load balancer. To provide seamless experience during the migration, customers can deploy the config service in both Cloud Foundry and Amazon ECS backed by the same Git repository. This would ensure that applications require minimum code changes while they are getting migrated.
• Service discovery: Some Cloud Foundry customers use Spring Cloud Eureka for service discovery and client side load balancing. Customers may migrate Eureka servers to an Amazon EC2 autoscaling cluster. Having the Eureka server running in an Amazon EC2 cluster and Cloud Foundry and connecting the two Eureka clusters where both clusters behave as a single service can provide seamless service discovery between applications running in both Amazon ECS and Cloud Foundry. AWS customers can choose to migrate to AWS Cloud Map — AWS’s native service discovery — at a later point, which would require application code changes.
• API gateway: Customers often use Spring Cloud Gateway to provide intelligent routing, authentication, and authorization functions for exposed services in Cloud Foundry. This gateway can be migrated to Amazon ECS with autoscaling and a public ALB without code changes. AWS customers can choose to migrate to Amazon API Gateway, which is a managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale during or after migration.
• Observability: When migrating to Amazon ECS, customers can use a mix of AWS services and existing third-party tools that were being used with Cloud Foundry.
  • Logging: Applications logs from Amazon ECS can be pushed to Amazon CloudWatch Logs. These logs then get routed to third-party observability tools if needed to preserved for developer experience.
  • Monitoring: Customers want to ensure that what Cloud Foundry provides for monitoring metrics like Central Processing Unit (CPU), memory, and disk utilization at the platform level are available in AWS. When migrating to Amazon ECS, customers can use Amazon CloudWatch Container Insights that provides basic container monitoring on CPU, memory, disk, and network.
  • Tracing: Customers can integrate applications with AWS X-Ray and AWS Distro for OpenTelemetry to send tracing data, which makes it easier for developers to diagnose issues. This can be done by adding the agents in Dockerfile.

DevOps migration

• Continuous integration (CI) migration: One of fundamental changes of moving from Cloud Foundry to Amazon ECS involves changing the deployment artifact from language dependent executables like .jar (Java apps) or .exe (.NET apps) files to building container images that can run in any container platform. This can be handled by setting up new container image repositories hosted in Amazon Elastic Container Registry (Amazon ECR) and subsequently enhancing existing Continuous integration (CI) pipelines to trigger image builds. AWS recommends that customers plan and estimate the feasibility and amount of work required to change the existing pipelines to introduce container image builds, or plan to migrate to AWS native services like AWS CodePipeline and AWS CodeBuild that support these flows. This is critical to the success of the migration as changing existing CI pipelines causes disruptions to regular release processes. Customers can use blend of modifying existing pipelines and creating new AWS CodePipeline-based CI pipelines that accommodate existing CI workflows, like unit and integration testing, as well as building and pushing container images to Amazon ECR.
• Continuous deployment (CD) migration: In Cloud Foundry, customers primarily deploy their applications using the cf push command, which is hooked to their CD pipelines. The deployment process changes when customers migrate to Amazon ECS and hence must be planned and estimated well ahead of the migration to prevent disruption to regular release processes. AWS CodePipeline along with AWS CodeDeploy can be used setup ECS deployments using rolling or blue-green deployments.

Conclusion

In this post, we showed you how customers can achieve their business outcomes with operational efficiency and realized cost savings by migrating their workloads from a Cloud Foundry PaaS solution to Amazon ECS with AWS Fargate. We outlined the architectural considerations, and lessons learned, in the process establishing a modernization pathway for other teams within the organization. This serves as a playbook for other organizations and teams considering a modernization approach from legacy PaaS solutions to managed container services on AWS.