Running one or two container instances on your local system is easy. For CI/CD use cases, teams often run multiple in parallel. This does require some additional development effort on top of the interfaces exposed by respective tools (for example, GitLab CI/CD pipeline templates), but it is still manageable. The real challenge, however, comes up when you want to run hundreds and thousands of containers for a production workload. How do you figure out which compute node to place the container on? How do you monitor whether they are still running? How can they securely consume other services such as databases and in-memory caches from the underlying cloud provider? These are the areas that justify the need for a full-fledged container management platform so that you can offload these tasks. These platforms are engineered to solve such problems at scale so that you can focus on writing application code.
There are some key responsibilities and characteristics of such platforms, as we’ll discuss next.
Key responsibilities of container platforms
A container platform should allow the developers to build, deploy, and manage container services at scale. In addition to providing capabilities around the life cycle management of these containers, there are several other areas these platforms typically support.
Orchestrating the placement of containers
Scheduling containers over multiple compute nodes is not an easy feat. This requires the platform to interact at both the infrastructure and application levels. The container platform consumes key metrics based on the current consumption of the underlying servers and matches them to the resource needs of the application. Some platforms allow the end user to implement advanced placement logic that matches their application needs.
Integrations with other services
In addition to running applications, these platforms offer a host of integration capabilities. As you can imagine, running containers on AWS will, at some point, require collaborating with underlying networking (VPC, subnet addressing, and so on), persistent storage (EBS or EFS), and monitoring and logging services. These integrations remove a lot of plumbing efforts that the developers would otherwise have to invest time in.
Monitoring containerized workloads
Running multiple containers in parallel requires a holistic view of how your applications are performing. Creating a dependency graph, monitoring key utilization metrics, deriving insights from the logs, or offering ready-to-use integrations with third-party solutions are some of the differentiating capabilities these platforms offer. In Chapter 8, Enabling the Observability of Your Workloads, we will dive deeper into some of the AWS offerings in this segment.
Enforcing security guardrails for containerized applications
Being an operating-system-level virtualization technology, there could be scenarios where you would run multiple applications on the same host. Container platforms should offer strong security boundaries that do not allow compromised applications to gain unprivileged access to the host kernel. We will cover some of the security best practices later in this chapter in the Ensuring a good security posture with ECS section.
Lastly, when deciding on a container platform, it’s important to always keep the complexities of managing the control plane itself in mind. Be it the requirements around automatically rolling out security patches or dynamically scaling the underlying components used by Kubernetes, you will always benefit from offloading these un-differentiated tasks to the platform.