It’s a well-known fact that traditional monolithic software architectures hosted on-premises slow down teams who want to deliver business outcomes to their customers by leveraging cloud capabilities. So far in this book, we have discussed quite a lot of technical and organizational impacts such applications can have. To overcome these blockers, software teams prefer breaking down the monoliths into smaller manageable components, also known as microservices. These services commonly communicate with each other over HTTP(S), or asynchronous messaging protocols, while offering a unified interface to the end user, as if everything is being managed as a single application. When the right services are used, they are comparatively easy to scale and operate in the cloud. If you are into designing software applications, I would highly recommend going through Characteristics of Modern Microservices Architecture, by Martin Fowler (https://martinfowler.com/articles/microservices.html).
To simplify the adoption of microservice architectures and building applications that are optimized for cloud computing, software teams also use the twelve-factor design pattern (https://12factor. net/). These are time-tested best practices for building modern Software-as-a-Service (SaaS)applications. The 12 factors mainly drive the idea of the following:
- Using declarative formats to set up automation
- Having a clean contract with the underlying operating system, offering maximum portability across environments
- Building apps that are suited for deployment on cloud platforms
- Scaling up without significant changes to tooling
- Having minimum divergence between environments such as development and production
If I had to call out a single technology that powers all of these areas, it would be containers. Microservices and containers go incredibly well together. They empower users to pass on the benefits of the strong application foundations to the end users in the form of frequent and stable business features. In the modern era, containers are the de facto standard for software deployment in the cloud or on-premises. By offering benefits such as low compute and memory footprint, isolation boundaries, and build-once-deploy-anywhere possibilities, containers have emerged as a strong candidate for any greenfield or brownfield application effort. You used the Docker toolbox image to execute all the hands-on exercises in the previous chapters and presumably agree that the consistent experience these containers offer is unmatched. Irrespective of the underlying system configurations, operating systems, or libraries, the hands-on experience for you will be similar. Isn’t this great? These days, it’s unusual for software applications to not have a container-based deployment model. It simplifies a lot of areas that otherwise would have been a pain to manage.
In this chapter, we will further grow our knowledge of containers in AWS by covering the following topics:
- A quick introduction to the container ecosystem
- AWS services that support running containers in the cloud
- Using AWS ECS to deploy a test application stack
A quick introduction to the container ecosystem If you’ve not been exposed to containers in your software landscape yet, then this is the introduction for you. I will try to keep it short since there are great resources on the internet if you wish to dive deep into the technology.