Containers in the Cloud
The concept of containerization, when to use containers, and one of the most popular container services
TL;DR: Docker containers wrap up software and its dependencies into a standardized unit for software development that includes everything it needs to run.
Container orchestration using a cloud platform enables the running and the maintenance of enterprise-level containerized applications.
This week, I was going on a trip and my mother wanted to take a few of her medicines and took out a container, placing only the pills needed for the vacation.
Portable and easy, yes? As a technophile, I was quickly able to string in the connection between this and an interesting piece of maturing technology of the same name, containers.
This blog is to give a brief of the concept of containerization, when to use containers, and one of the most popular container services in the market right now for solo developers and enterprises.
Imagine these software containers to be similar to their real-world counterpart, they are portable and used to transport or move about material as a single unit.
Container, Summarized
I am pretty sure that, as software developers of the old, you have faced problems like needing to install a virtual machine for certain types of programs and dependencies to run.
You need different types of versions of transitive dependencies to be installed before running your application on other machines, moving applications through the software development lifecycle (SDCL) pipe into production, and the age-old problem of it worked on my computer, though.
Containerization is an old concept in the computing world which gained the spotlight in the recent past, when Docker introduced simplified tooling to create and manage containers. (Also, to note is that there are several new players in the market but this blog mainly relates to Docker).
The core idea of containerization evolved from virtualization and acts like a companion. It dictates the idea of packaging or encapsulating software code with all of its dependencies so that it is able to run smoothly, consistently, and independently on any infrastructure.
This has evolved over the past half a decade and has proven its place.
Some notable advantages of containerization could be summed up as:
- Removing the dependency of the host system from the application code.
- Building easily scalable programs.
- Simplified dependency management and versioning.
- Being lightweight and flexible.
- Isolated execution.
- Predictability.
But, as an individual developer or as someone who builds small scale applications, you would not be able to see or experience the vast array of benefits brought in by Docker and containers.
That’s where container orchestration comes into play. Container orchestration is all about managing the lifecycle of containers, mainly in large and dynamic environments — an enterprise system.
Let’s take a turn and imagine that we are in fact working on an enterprise application which will be used by thousands of people.
Amazon Web Services offers its own implementation of a container orchestration service, which we shall be looking into next.
AWS Elastic Container Service
For enterprise-grade applications or systems, it is de facto to go for Cloud-based deployment where you pay-as-you-go.
AWS, being the industry-leading XaaS provider, understood the impact containers make in building software and provides their own service, called the AWS Elastic Container Service (ECS).
AWS ECS is designed to be a highly-scalable, high-performant container orchestration service that supports Docker containers. This service enables us to easily run and scale containerized applications in the Cloud.
Imagine a scenario where your application is a Java micro-service, expected to run on a Linux server, having its own micro-database, and you decide to build this on AWS.
In this case, deploying your micro-service using ECS and using Relational Database Service (RDS) by default provides you with the added benefit of fault-tolerance as well, which means we don’t have to worry about that when designing.
Also, the specific host a container runs on and its maintenance are all managed by the platform itself.
AWS provides new terms for its services and modules. Let’s learn them along the way. For this, let’s take a small scenario similar to the above.
Imagine we need to run an application server (app_1) which also requires a small cache service (app_2) to run alongside it.
Task definition
As the name sounds, it’s the blueprint for a task. Think of a Java Class. It dictates which containers are to be run.
In the above example, it would declare both the applications to run in two containers in a single task. It also defines the details, such as environmental variables, to be used, CPU and memory allocations, exposed ports, and how each of the containers would interact.
The number of tasks to be run is also declared in this.
Task
A task is an instance of the above blueprint. Think of an Object of a Java Class. Tasks are run as configured via its task definition, allowing multiple tasks to be run from a single definition.
In our example, one task would run both the app_1 container and the app_2 container.
Service
Service allows you to run and maintain the specified number of instances in a task definition, simultaneously in a cluster.
This sustains the minimum and maximum tasks at a given time and manages more things, including load balancing and auto-scaling of the containers.
For example, in our case, due to high load at a specific time, if the CPU starts to throttle, the service checks for the maximum number of allowed tasks to run and increases the number of tasks one-by-one until a given average threshold is achieved.
Container instance
These tasks (and containers) need to be run somewhere to be accessed — enter container instances. Container instances are EC2 instances that run Docker and a special piece of software called the ECS Agent and registered into the Cluster of instances.
Each of these instances has the ability to run one or more tasks (i.e. one or more containers), given that it has physical resources available. Also, to note is that a container instance can run tasks from one or more Services.
The Agent acts as the bridge between these instances and ECS by providing the statuses of the running containers and managing spawning new containers in an instance.
Cluster
A Cluster is a group of ECS container instances. The ECS facades all the complications of maintaining, scheduling, and scaling these instances.
Also, based on the placement strategy, it places new container spawns in optimal instances and abstracts the pain away.
When you have multiple software modules that run independently as parts of your product, you can place several of them in one cluster, which enables optimal usage of resources and actually minimizes the setup time.
Conclusion
We have seen how immensely containerization helps the software development process, by addressing multiple pain-points and manual labor of a software developer.
Similarly, how the AWS Cloud platform addresses multiple challenges of a DevOps engineer.
We have a basic understanding of the container orchestration service AWS provides to ease the process of managing an enterprise-level containerized application in the Cloud.
I’ll try some practical applications on this and catch up with more on working with enterprise-level containerized applications and memory management in upcoming blogs.
