(c)iStock.com/cyano66

The standard has been set for containerisation. It’s Docker. Need an identical copy of your application stack in multiple environments? Package it once for Docker and away you go. It’s simple, and it’s why we love containers. That was all you needed back in 2015 – but things are changing fast.

Now that containers have proved their viability, it’s on to the next big area for innovation: orchestration. This is where there’s even more competition and the potential for confusion for users.

As your organisation scales and your container requirements go from half a dozen to many hundreds, one DevOps engineer can’t deploy them all. The question becomes: how will you automate, deploy and manage your fleet of containers? The answer for most teams will be through orchestration.

Each orchestration platform has advantages relative to the others and so users should evaluate which are best suited to their needs. There are, of course, a lot of factors to consider. Some that I would recommend you keep in mind include:

• Does your enterprise have an existing DevOps framework that the orchestration must sit within?
• Will the containers be run on bare metal, private virtual machines (VMs) or in the cloud?
• What skills do you have within your organisation?
• Is my database designed to provide always-on availability and scalability in these distributed environments?

Now that you know what you want to do, it’s time to consider your options. There are many different types of orchestration platforms, but for the purposes of this article I wanted to look at the three most popular and where I think they can be of most use:

Docker Compose

Made by the container experts, Docker Compose is a great starting point for orchestration. Docker hasput together a platform that may not have all the bells and whistles you’ll find elsewhere, but it is a simple and effective tool.

Some of the benefits of using Docker Compose include:

• A single host can run multiple, isolated environments
• Data is preserved when containers are shut down and restarted.
• It determines which containers for a project are already running, and which need to be started

It also can incorporate other Docker tools like, Docker Machine, which makes multiple machines look like a single machine, and Docker Swarm, a technology that claims to be able to deal with 1,000 physical services concurrently.

When to use it: If you’re a smaller shop or you have simple requirements, Docker Compose could be right for you. It’s also often used in testing environments, but then put into production with more feature rich platforms like the next two I’m going to describe.

Kubernetes

Kubernetes was created by Google and is one of the most feature-rich and widely used orchestration frameworks. In fact it’s the platform you’ve probably already heard of. Much as Docker become synonymous with containers, Kubernetes seems to be gaining the same status with container orchestration.

According to Wikipedia Kubernetes is Greek for «helmsman». A clever and apt name as Kubernetes is designed to pilot your containers in multiple environments, including bare metal, on-premise, VMs and public clouds.

Its key features include:

• Automated deployment and replication of containers
• Online scale-in or scale-out of container clusters
• Load balancing over groups of containers
• Rolling upgrades of application containers
• Resilience, with automated rescheduling of failed containers

When to use it: Kubernetes is suitable for most use cases involving orchestration and has already proved itself within Google’s demanding infrastructure. It’s designed for virtual machines, so will be particularly effective on those.

Mesos

Apache Mesos is designed to scale to tens of thousands of physical machines and it’s already being relied on by the likes of Twitter, Airbnb, and Apple.

It’s true that Mesos is fantastic at scale but it doesn’t have the features nor ease of us that Kubernetes does. There is likely to be extra work designing services and some coding required too but, depending on the use case, this may lead to even better performance.

There is actually a project currently in the works to run Kubernetes as a Mesos framework. Mesos provides the management of thousands of hosts while Kubernetes adds higher level functions such as high availability and rolling upgrades. Kubernetes adds the higher level functions such as: load balancing; high availability through failover (rescheduling); and elastic scaling.

When to use it: it was designed for physical machines, so that’s the area where I’d specifically recommend Mesos over Kubernetes. It’s also worth looking at if you have good knowledge on your team and the ability to do some research and experimentation to see how it can be fine-tuned for your use case.

Conclusion

That is, of course, not an exhaustive list but those are the three orchestration platforms I would investigate first. The two other points I would also like to make are around maturity and migration.

These are not technologies that were designed with a grand plan. Most of them came out of internal projects so were designed for a unique set of use cases. They are also still relatively young so functionality in some instances may be frustratingly limited, although these days kids grow up fast and open source technologies tend to mature quickly.

The other point is that it is possible to migrate from one orchestration platform to another. Though it’s much better to migrate the app while it is still in the testing phase. Moving an orchestration platform once a product is in production could get sticky quickly.  

Going from solo performer with a few containers to conducting a whole “orchestra” is a big step but as containers become more widely adopted it will become standard. My advice: play around now so you can get familiar with the different options and know which one will help you solve your business problems. Let me know how you get on (@matkeep) and good luck conducting!