Orchestration tools fully exploit Linux container technology

Companies that need to deliver applications quickly and efficiently—and today, what company doesn’t need to do this?— are turning to Linux containers. What they are also finding is that once they get past the “let’s see how these container things work” stage, they are going to end up with a lot of containers running in a lot of different places.

Linux container technology is not new, but it has increased in popularity due to factors including the innovative packaging format (now Open Container Initiative (OCI) format) originally invented by Docker, as well as the competitive requirement for continual development and deployment of new applications. In a May 2016 Forrester study commissioned by Red Hat, 48 percent of respondents said they were already using containers in development, a figure projected to rise to 53 percent this year. Only one-fifth of respondents said that they wouldn’t leverage containers in development processes in 2017.

Like Lego blocks, container images enable easy reuse of code and services. Each container image is like a separate Lego block, designed to do one part of the job really well. This could be a database, a data store, or even a booking service, or analytics service. By packaging each part separately, they can be used in different applications. But, without some sort of application definition (the instruction booklet), it’s difficult to create copies of the full application in different environments. That’s where container orchestration comes in.

Scott McCarty

Container orchestration provides an infrastructure like the Lego system – the developer can provide simple instructions for how to build the application. The orchestration engine will know how to run it. This makes it easy to create multiple copies of the same application, spanning developer laptops, CI/CD system, and even production data centers and cloud provider environments.

Linux container images allow companies to package and isolate the building blocks of applications with their entire runtime environment (operating system pieces). Building on this, container orchestration makes it easy to define and run all of the blocks together as a full applications. Once the work has been invested to define the full application, they can be moved between different environments (dev, test, production, and so on) without breaking them, and without changing how they behave.

Kicking the tires on containers

It’s clear that containers make sense, and more and more companies are figuratively kicking the  tires on containers. In the beginning, it might be one developer working with a single container, or a team of developers working with multiple containers. In the latter scenario, the developers are likely writing home-grown code to deal with the complexities that quickly arise once a container deployment grows beyond a single instance.

This is all well and good: They’re developers, after all – they’ve got this. But it’s going to get messy, even in the developer world, and the home-grown code model is just not going to fly once containers move to QA and [dun, dun, duuuuunnnnn] production.

Orchestration tools do essentially two things. First, they help developers define what their application looks like – the set of services it takes to build up an instance of their application – the databases, data stores, web servers, etc., for each application instance. Orchestrators help standardize what all the parts of an application look like, running together and communicating to each other, what I would call a standardized application definition. Second, they manage the process of starting, stopping, upgrading and running these multiple containers in a cluster of compute resources, which is especially useful when running multiple copies of any given application, for things like continuous integration (CI) and continuous delivery (CD).

Think about it like an apartment building. Everyone who lives there has the same street address, but each person has a number or letter or combination of both that specifically identifies him or her. This is necessary, for example, for the delivery of the right mail and packages to the right tenants.

Likewise with containers, as soon as you have two containers or two hosts that you want to run those containers on, you have to keep track of things like where developers go to test a database connect or where users go to connect to a service running in a container. Container orchestration tools essentially help manage the logistics of containers across multiple hosts. They extend life cycle management capabilities to full applications, made of multiple containers, deployed on a cluster of machines, allowing users to treat the entire cluster as a single deployment target.

It’s really that simple—and that complicated. Orchestration tools provide a number of capabilities, ranging from provisioning containers, to identifying and rescheduling failed containers, to exposing containers to systems and services outside the cluster, to adding and removing containers on demand.

While container technology has been around for a while, container orchestration tools have been available only for a few years. Orchestrators were developed from lessons learned with high-performance computing (HPC) and application management internally at Google. In essence, to deal with the monstrosity that is, running a bunch of stuff (batch jobs, services, etc.) on a bunch of servers. Since then, orchestrators have evolved to enable companies to strategically leverage containers.

Once your company determines that it needs container orchestration, the next step is figuring out which platform makes the most sense for the business. When evaluating container orchestrators, look closely at (among other things):

• Application definition language
• Existing capability set
• Rate at which new capabilities are being added
• Whether it is open source or proprietary
• Community health (how active/productive members are, the quality/quantity of member submissions, diversity of contributors – individuals and companies)
• Hardening efforts
• Reference architectures
• Certifications
• Process for productization

There are three major container orchestration platforms, which seem to be ahead of the others, each with its own history.

1. Docker Swarm: Swarm is an add-on to Docker – arguably, the container poster child. Swarm allows users to establish and manage a cluster of Docker nodes as a single virtual system. The challenge with Swarm is it seems on track to become a single-vendor project.
2. Mesos: Mesos grew up from Apache and high-performance computing, and thus serves as an excellent scheduler. Mesos is also very technically advanced, although it doesn’t seem to have the velocity or investment compared to others.
3. Kubernetes: Developed by Google, with lessons from an internal orchestrator named Borg, Kubernetes is widely used and has a robust community around it. In fact, it’s the No. 1 project on GitHub. Mesos may currently have a slight technical advantage over Kubernetes, but Kubernetes is a fast-moving project, which is also making architectural investments for long-term technical gains. It should catch up and surpass Mesos in terms of technical capabilities in the very near future.

The future of orchestration

Looking ahead, companies can expect to see orchestration tools moving in an application- and service-focused direction. Because, in reality, rapid application development today is really about quickly leveraging a mix of services, code, and data. Whether those services are open source and deployed by your internal team or consumed from a cloud provider, the future looks like a mix of both. Since today’s orchestrators are also tackling the application definition challenge, expect to see them tackle the integration of external services more and more.

For the here and now, companies that want to take full advantage of containers must take advantage of container orchestration.