How to Migrate a Spring App to the Cloud: Part II containers!
Picking a Cloud Infrastructure — ECS & FARGATE
Our last post discussed our migration options using EC2 (Beanstalk & Lift&Shift) and Lambda solutions (JVM, Micronaut, GraalVM) for our Spring application. Now, it’s time to look at some options using containers.
🎺🎺Enter ECS and Fargate! 🎺🎺
Disclaimer
I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.
ECS
Choosing ECS is a step towards the world of containerization, alas an easier one since it’s a “managed service” (where some of the configuration or administration is done for you). There is an option with ECS Fargate where you won’t need to manage nodes nor the control plane, which allows for a smaller learning curve and easier adoption than workloads with native containers on EC2 instances.
With ECS, you’ll have two options: ECS with EC2 backing, or ECS Fargate, which is serverless. The question in choosing among these becomes really how low-level do you want to go?
ECS w/EC2 backing
This service allows you to think at the EC2 instance level. You can choose the instance types and pay for however many of those instances were running.
But with this greater flexibility you’ll find yourself configuring cluster & service scaling, networking, patching, and security for those instances, all of which require a learning curve to master. Also to take into account: since you’re paying for instances, you’ll pay for an entire instance even if you’re only using it partially, which is why it’s especially important to master the subject of container scaling, and how capacity providers can simplify this process.
For the cost, we will follow this cost comparison example and assume an m5.8xlarge which is comparable to 4 m5.2xlarge.
- This gives us: $1.792 * 24hr * 30day = $1290/month
ECS w/Fargate
With Fargate, the server level is abstracted from you, which allows you to focus on the actual tasks or services. You won’t need to configure cluster scaling, optimize cluster packing, security nor do any patching of any EC2 instances, since the ECS service will manage that.
When you set up Fargate, you have some limitations on customizing the environment but most importantly, you will select how much CPU and memory a task will need, and the cost of the service will be tied to this selection.
Once again, we will refer to the cost comparison example mentioned earlier, so we will size our Fargate tasks as if we were dividing the m5.8xlarge instance into 8 tasks, with each task enjoying 16GB of memory and 4 vCPUs, for comparison purposes.
- In the Paris region, this gives us:
4 * $0.0486 vCPU/hr + 16 * $0.0053 GB/hr = 0.2792/hr per task
0.2792/hr * 24hr * 30days = $201/month per task
The question now is, how many tasks will be needed on average per month? We will need at least one (or two or more for HA, responsiveness, etc), since scaling up the tasks might take a few minutes before they are ready to process requests.
In any case, once we run the cluster in production for a while we’ll have to come back and revisit this point, but for now this solution seems less wasteful than the EC2-backed option (where we’d pay for an entire instance even when a small portion is used), since the cost is more tightly tied to the time resources are being used.
Note however, there is a threshold for when an EC2-backed ECS cluster will be more cost effective than a Fargate one, the relation being that the more fully utilized the EC2s are in the cluster, the cheaper they are. For more details on this, please see the cost comparison example. On the other hand, with Fargate you’re circumventing the costs of maintaining and managing the compute infrastructure which the EC2-backing would require.
App2Container
During our research into ECS, we ran into details about an App2Container tool, which apparently generates a lot of the configuration needed to migrate a Spring app onto the ECS platform. We followed the App2Container Workshop, and were able to get our app running in a couple of hours! 😮
Basically you install the App2Container tool, run it on your Tomcat instance with the app deployed, and it inspects and generates the configuration needed through a series of steps. The final step deploys the whole setup onto the ECS Fargate platform.
We were pleasantly surprised at how easy this was.. granted not as easy as Elastic Beanstalk, but having the app configured, containerized and running in a serverless environment seems like a much better alternative than running on EC2 instances, especially when it is quick and easy to do so. Being able to leverage this tool definitely tipped the scale in favor of Fargate.
AppRunner
This is a new service that launched this year, I see it as the Elastic Beanstalk of containers, though it does manage to abstract the server level. It manages container orchestration and load balancing, even pipelines for you.
However, the containers cannot access resources in private VPCs, such as the RDS database in production. There is a GitHub issue right now to build in this feature, but for now it won’t suit our purposes.
The Winner!
We looked at several options which run with EC2 infrastructure (Elastic Beanstalk, Lift & Shift, ECS), as well as a few serverless options (ECS Fargate, Lambda). Besides being cost-effective, the major factors we’re looking for are ease of migration and choosing a solution that allows us to leverage the benefits of the cloud.
The cheapest option seems to be leveraging AWS Lambda, but it requires coding changes or delving into unknown territory. For now, we want to make a quick jump, and so all of these factors point to ECS Fargate, which is serverless and therefore reaps maximum cloud benefits, is easily set up and also capable of leveraging “Fargate Spot” for added savings.
Since Fargate is a managed service, there’s less infrastructure for us to configure and manage, and therefore requires a smaller learning curve.
Although difficult to predict exactly, it seems a cost-effective option and we will make note to check the real pricing once we’ve run our workload in production for a couple of months.
Conclusion & Next Steps
Since we implement IaC, we will use CDK to stand up the accompanying database, and then import the CloudFormation templates generated by the App2Container tool into the CDK.
Since we’re still a newish cloud shop, we will leverage the CloudFormation templates initially generated by App2Container, and adapt any changes needed to them directly rather than reverse engineering the templates into native CDK code.
The App2Container also generates an ECR image for us with the Spring application. Since we will be updating the Spring application regularly, we will migrate the step of generating the image into our build/deployment process within the CDK.
The final infrastructure will be as follows:
The requests will come in and be routed by the Application Load Balancer to the ECS container. The container will grab the Docker image with the Spring application from ECR in order to serve the request. The Spring application will establish a connection to the RDS MySql database within a private VPC.
Seems simple enough?
We will detail the journey for setting this up through the CDK, adding pipelines, monitoring, etc in the next posts.
Stay tuned!
