What is a Container Orchestrator, Anyway?

Container orchestration has become a hot topic following Docker’s ascent. There are lots of orchestrators out there, and people tend to have strong opinions about which one is best. But in this post, I’d like to step back a bit and ask the question, “What is an orchestrator, anyway?” The term is much less clear than you might think.

This is a question worth asking because the word “orchestrator,” when used in reference to containers, has become quite ambiguous. You hear it most often to refer to Docker Swarm, Kubernetes, Marathon or other platforms. But it is sometimes used in other senses.

So let’s take a look at the different meanings of the word “orchestrator.”

Meaning 1: Any Infrastructure Management Tool

The concept and terminology of orchestration predates the arrival of Docker containers. Before Docker came along, orchestration referred to the process of managing any kind of infrastructure, usually with the assistance of automation.

For example, VMware was developing products to help users orchestrate clusters of virtual machines back before anyone was thinking that containers might eventually replace those virtual machines. Orchestration for cloud servers was also a big focus prior to Docker, with tools such as Juju designed for this purpose. You tend not to hear the term “cloud orchestration” frequently today, but that is essentially what tools like AWS CloudFormation do.

If you take a broad approach to defining orchestrators as any type of infrastructure management tool, you could also include provisioning and infrastructure-as-code solutions, such as Chef and Puppet, in the category as well.

Meaning 2: Container Management Tool

When Docker containers became popular, people realized they needed an automated way to manage the hundreds or thousands of containers inside a Docker cluster. With Docker, automated orchestration ceased to be an option.

You might have been able to manage a VMware cluster of a few dozen servers manually. But there is no way you can handle a production-scale container environment without the assistance of automation.

That’s why tools such as Docker Swarm and Kubernetes were developed. Their main job is to automate the provisioning of containerized infrastructure and provide load balancing for the services that containers are used to create.

Meaning 3: All-Around Container Deployment Platform

Orchestration is occasionally used in a broader sense to refer to platforms designed to manage all aspects of setting up and deploying a containerized application. Rancher, Kontena and Amazon ECS are examples.

When people use the word in this context, they are usually thinking of the idea that these platforms have container management built into them, even though the platforms do more than just manage containers.

This use of the term is a little misleading. Offerings such as Rancher and ECS are best labeled containers-as-a-service platforms because they do much more than orchestration. But the terminology can get confusing because in some cases (like Rancher’s) the application management platforms use external orchestrators, whereas in others (like Kontena’s and the ECS case) the orchestrator is unique and built into the core platform.

Conclusion

Nobody knew container orchestration could be so complicated.Well, OK, maybe you did know. The technical dimensions of managing containers at scale are pretty complex.But even the mere terminology and concepts behind container orchestration are more complicated than you may have realized. The next time you use the word “orchestrator” or “orchestration,” stop and think about what you really mean.

Christopher Tozzi

Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

Christopher Tozzi has 254 posts and counting. See all posts by Christopher Tozzi

One thought on “What is a Container Orchestrator, Anyway?

  • Thanks for the categorization.

    One thing that came to mind though is that, when considering “built in” orchestrator vs. external orchestrator, in the case of Rancher, a) cattle is a Rancher product built into their orchestrator and b) even in the case of e.g. kubernetes (and likely with Swarm and Mesos as well), a particular version of kubernetes is provided with rancher, to account for container networking issues etc. That is, Rancher doesn’t have fully external orchestrators which it would simply provide an abstraction for, rather it does reuse of those frameworks while still “encapsulating” them. On the other hand, when starting to compare container platform features and use cases (e.g. Rancher vs. ECS), differences do show about on other areas.

Comments are closed.