January 9, 2020
Go Faster with Microservices: From Monolithic to Cloud-Native
Thanks to AWS’ incredibly broad and powerful set of services, architecting and building microservices is easier than ever. There are hundreds of services with thousands of features, and many of them can be used for composing microservices.
You can build microservices using more traditional approaches, such as EC2 with auto-scaling, or by leveraging such options as containerization and AWS Lambda.
From a containerization perspective, building a microservices architecture is now easier than ever because of container Orchestration-as-a-Service offerings like ECS and EKS. And if you're using AWS Fargate, it can reduce your management burden to near zero, because it's a serverless container orchestration system. You just upload your containers to the container registry, and off you go.
With serverless offerings like AWS Lambda, you can build out significant applications and leverage the Amazon API gateway, which helps publish, maintain, and even secure monitor and scale your microservices API. You can process requests that come in, scale them massively, and have the actual processing of requests from the API gateway delegated out to AWS Lambda. And you pay only for the compute that you use.
When it comes to building microservices on AWS, there is no one right way to do things. Many microservices leverage a mixture of containers, Lambda, and even EC2, and they integrate things together with the API gateway.
In many ways, AWS is actually a marketplace of microservices with hundreds of services and thousands of features. Modern applications can be composed of homegrown microservices and from a menu of dozens of “serverless” services from AWS such as:
You can treat all of these as externally produced microservices that you can compose together to build out your application. Essentially, AWS is giving you a huge head start on building out your application and a model that you can follow. You only need to build out microservices that haven't already been created, or that you already have access to. This is an incredible opportunity for anyone who wants to build out microservices applications.
Your Call Football is a mobile gaming platform that incorporates real football game play with fantasy-style fans sourced play-calling. Essentially, the coach on the field selects a play package that gets sent to a mobile application where users then vote.
When Your Call Football reached out to Mission, their developers had already built a large majority of the app's functionality, but they needed help scaling it while meeting the identified response time requirements. They also needed ongoing monitoring and management of the platform to maintain that performance and reliability baseline.
Mission configured high availability and/or failover for all services, and even migrated to AWS Managed Services, where possible. We created the networking clusters, databases, and other AWS services using Terraform so that we could quickly make changes to scale the environment up or down for the game while providing some uniformity across environments.
We used Aurora RDS for storing user stats and other game data, but the majority of the session and scoring information was stored in Redis and in the queues. In order to isolate the loads, we built multiple clusters and then tuned in on the ideal pod density for each in order to squeeze out some additional performance gain. During the first season, the clusters were built using pods as EKS hadn't been released yet, but for the most recent season, we migrated to a single ECS control plane cluster with worker node groups.
Your Call Football is a really compelling use case for microservices because they had struggled with their existing workloads; they had built things out in a monolithic way. But we were able to decompose it for them and improve their efficiency.
Many organizations that already have a monolithic application have the misconception that they will have to start over from square one if they want to build out microservices-based architecture. This is not true. You can absolutely evolve and decompose your application, and along the way, still reap many of the same benefits.