Containers, Composers, and Orchestrators

Containerization a difficult concept to wrap one's head around, simply because of the commonality of the different terms involved. To remedy this problem, I recently decided to solidify some of this terminology with an analogy.

Containers, Composers, and Orchestrators

Containers are a pretty popular topic right now in software development and the sub-area of software development we often call DevOps. As a software developer, I've heard of the benefits of virtualization/containerization and actually experienced it first-hand at some of the companies I've worked for. That said, I've found containerization a difficult concept to wrap my head around, simply because of the commonality of the different terms involved.

To remedy this problem (arguably only one in my own mind), I recently decided to solidify some of this terminology, and discovered a pretty interested analogy on [this StackOverflow answer]( that I thought I would share.

Essentially, the analogy is the following:

Containers are lightweight, isolated, self-contained packages of software that provides a service, and all dependencies. You can think of these as containers on a cargo ship - they are isolated from all other containers on the ship, and provide a set of something that is completely self-contained (the products being shipped). They may or may not have any relation to any other container(s) on the ship.

Composers or clusters (I use this term as a general noun, but really, we're talking about docker-compose here) are tools for defining and running applications using multiple containers. In the analogy above, a composer is similar to the ship on which containers are loaded. The captain of the ship (i.e. the docker-compose.yml file) is responsible for placing containers in a specific area of the ship, starting/stopping them, and managing access to them. Typically, clusters will have numerous containers running on the same machine.

Orchestrators, or Orchestration Frameworks, such as Kubernetes or Docker Swarm, are used to manage multiple clusters. You can think of these as the harbor master, or port authority, in the above analogy. It is the responsibility of this authority to manage multiple ships, each interacting with each other, as well as schedule arrivals and departures. The orchestration framework typically manages multiple clusters across several physical hosts.

One thing to keep in mind, while in the analogy, it's necessary to have a separation between orchestrators and composers, the composer level really isn't necessary. Kubernetes is actually the Greek word for "helmsman", indicating the captain of a ship. While Kubernetes can be used as a composer, it's not really possible for docker-compose to perform all of the same tasks as Kubernetes.

This is a simplified example, and of course, has its limitations, but I felt that it helped me understand this complex interaction of systems a little better. Of course, I'm still learning, so it's possible some of the things in this blog post aren't correct (i.e. take my opinion and knowledge with a grain of salt).