Whether you want to try a new database program on your workstation, or want duplicates of your application stack across different environments, you can do these and more with the help of container orchestration tools.

Orchestration solutions allow you to execute a single command to create a self-contained and portable sandbox, or build a container image that lets multiple staff members across development, operations, test, and support teams work and experiment in a clone environment.

Orchestration tools also let sysadmins manage the creation, upgrade, and availability of multiple containers in an IT infrastructure.

Finally, the orchestration process lets users control how several containers are connected to create complex applications from a series of microservice containers.

The rich functionality, highly capable APIs, and simple tools of containers and container orchestration makes this technology a favorite among DevOps admins, who use it to bolster their Continue Integration and Delivery workflows.

But what exactly are containers and how are they “orchestrated”?

The process of “loading” the software container involves defining what it needs for the application to function, such as configuration files, libraries, operation systems, and application binaries among other things that form a technology stack.

After defining the container, its image is used to create multiple containers that are compatible with any ecosystem, from a sysadmin’s work laptop to a developer’s test rig, or the onsite product server or cloud data center, without modifying the container’s contents.

This kind of consistency offers several benefits. For starters, it allows software engineers to spin up individual containers to test and isolate issues, all while knowing the container is 100% identical to whatever is already being deployed.

As you can probably see, the ability of containers to run on any machine and environment makes them a very efficient way to build and manage applications. You can even run multiple containers on one machine, allowing you to maximize all available resources.

Sysadmins can use groups and Linux containers (LXC) to prevent containers from “leaking,” ensuring that memory contents, namespaces, libraries, and data files are isolated in each individual container. These systems can also limit the number of system resources (e.g. RAM, storage, network bandwidth, and CPU) each container can use, preventing them from choking out critical applications.

Of course, the analogy between software and shipping containers can only go so far. Shipping containers can’t ‘talk’ to each other, nor can they depend on one another to perform certain processes. Software containers, however, can be programmed to do both, and then some.

Software containers can interact with each other for maximum efficiency—for example, one container can provide a database service, which an application on a separate can access through a programmed port. This kind of modular design to software containerization is an efficient way to create microservice architectures.

You’re probably wondering by now what makes containers different from virtual machines. Both allow users to create and spin up an image, and work on it while it is in an isolated environment.

But perhaps the biggest distinction containers have over VMs is how they lean towards building and launching applications efficiently. You see, every VM you have running must have its own operating system, all libraries, and application binaries — as you can expect, this amount of software can eat up gigabytes of memory and storage. In contrast, an individual container carries its own application and dependencies, but it can run on the same libraries and Linux kernel it shares with other containers on the host.

This translates to significantly lower consumption of storage, memory, and CPU resources, which in turn, allows for multiple containers to run and launch from a single host in mere seconds. Having multiple containers on one host also means that each container can be programmed to focus on running a specific task, with the entire container fleet working together to run complex applications. In these microservice architectures, each container can even use a certain programming language and library that can be modified without affecting the other containers.

And because each container in a microservice architecture is isolated from one another, it is more efficient, not to mention safer, to update any given container, especially when compared to monolithic setups.

This fits right in with the Continuous Delivery approach—a school of thought in software engineering that involves the rapid and frequent implementation of updates—including config changes, bug fixes, new features, and experiments—to a deployed application. In addition, container technologies like Docker come with APIs and tools that are more powerful and dev-focused than those you would normally find on VMs.

These APIs allow sysadmins to integrate their containers into configuration management (CM) systems, like Puppet and Chef, which are used by DevOps teams to manage the software development lifecycle its entirety. This has led to the wide-scale adoption of software containerization among DevOps teams. This isn’t to say that virtual machines are useless, as they still fulfill some very important functions. In fact, you can expect to run containers within VMs.

Here’s a quick look at why containers are all the rage in the world of DevOps today.

• Continuous Delivery for DevOps Teams — When an application is composed of several integrated containers with clear interfaces, the process of updating a container, seeing the results, and rolling back to its previous version or applying the update to other containers is fast, easy, and safe. By having multiple backup containers with the same functionality, DevOps teams can simply update each container without worrying about disrupting the entire app’s performance.

• Build Once, Deploy Anywhere — Perhaps the biggest benefit of using containers is their portability. As mentioned earlier, each container has everything the application needs to run, whether it’s dependencies, libraries, or config files. This allows sysadmins to quickly run applications on practically any environment, whether it’s your local workstation, virtual services, physical services, private and public clouds, as well as testing and production environments. This kind of portability offers DevOps teams tremendous flexibility, not to mention a faster development process, that makes it convenient to switch between cloud environments or providers whenever necessary.

• Replicated Test Environments — Using containers makes it very simple to create multiple copies of your application stacks and configurations, which can then be used by DevOps support teams, new hires, consultants, and partners. And again, any experiments done on a container is isolated, ensuring that the application is protected.

• Safe and Accurate Experimentation — Testing in a QA environment means that whatever changes you make to any container will match whatever will be deployed in the application.

• Resource Efficiency — Because containers don’t need a separate operating system, they are much lighter on your resources (e.g. storage, RAM, CPU). And while a VM can take up gigabytes of storage, containers usually come in at only a few megabytes, thus making it possible to run several containers on a single server. And because each fleet of containers has a higher level of utilization relative to hardware, your organization can reduce its hardware and data center costs.

• Superior Resource Sharing and Isolation — Again, while multiple containers can run on a single server and share its resources, each container is independent. If one crashes, other containers running the same application will chug along just fine. This also means the container system is more secure—if one container is infected by malware or hacked, its effect will be isolated to that one container.

• Smooth Scalability — Container systems are easy to scale horizontally—it’s simply a matter of adding more identical containers to a cluster to scale out throughput and capacity. Smart scaling also lets you run a certain number of containers only when needed, allowing you to maximize cost and efficiency. Conversely, you can remove containers during periods of low demand. Using orchestration tools like Kubernetes or Docker Swarm further simplifies scaling.

• Redundancy — Running multiple identical containers allows you to build a redundant system into your application. If one container fails or is compromised by a breach or malware, the surviving containers, which have the same config files and libraries, can continue running the service. You can also program configuration management (CM) tools to automatically reschedule failed containers on the same host to restore full throughput and redundancy.

If you have already switched to Linux containers, you are probably figuring out the process of running containers in production, which raises new issues not present during development.

What you need is a solution that lets you manage all your containers. You need a container orchestration system. As the name suggests, an orchestrator is a system that lets you manage all the hardware and virtual machines your containers run on, much in the same a musical Conductor controls different groups in a music ensemble or orchestra. Among many other things, an orchestrator lets you control individual containers, launching them on the underlying machines in your infrastructure, ensuring their proper distribution, and monitoring their health.

If you are managing several containers, or plan on launching implement multiple containers in your IT infrastructure, you might be surprised at the sheer variety of container orchestration solutions on the market. You have tools from big names like Microsoft and Amazon, as well as open-source (but just as capable) solutions from smaller players like Docker and Kubernetes.

Of course, not all orchestration tools are created equal. It is not so much that some orchestrators are better than others, but more about the fact that certain orchestration solutions have certain strengths and specific features that may or may not be relevant to your organization. Listed below are a few of the most popular orchestration solutions on the market right now.

Docker Swarm

Docker Swarm is Docker’s proprietary solution designed for orchestration and cluster management, rolled into the main Docker Engine as “swarm mode” in 2016. Swarm essentially lets users take clusters of Docker hosts and lump them together into one virtual system or host Docker calls a “swarm,” which in itself consists of one or more manager and worker Docker nodes.

Docker basic components include:

• Manager nodes — Typically handles orchestration and cluster management
• Worker nodes — Launching of tasks instructed by manager nodes

Docker Swarm allows applications to be replicated, updated, and deployed as services, all while giving sysadmins the ability to increase or decrease container iterations to adapt to changes in computer demands. Users can interface directly with the Docker API, which gives them access to Docker Tools and the Docker command line, which are used for container deployments. According to Docker, Swarm is capable of running up to 30,000 containers at the same time, and clusters with up to 1,000 nodes without breaking a sweat.

What Makes Docker Swarm Special?

One of Swarm’s most notable benefits is just how easy it is to set up and run. If your DevOps teams are already working with Docker containers, it’s as easy as dropping the solution into your Docker environment.

One or more of these principles manifest themselves in Swarm’s Unix-like approach of doing one thing once and getting it right the first around—although this is a feature Docker claims is baked into their all their services (i.e. Docker, Docker, composes, and Docker machine). The Docker Swarm cluster—which consists of Swarm Nodes, Swarm Manager, and Swarm Discover backed–also supports a wide variety of service discovery options, such as Consul, etc, Token, and zookeeper.

Kubernetes

No discussion of container orchestrators is complete without mentioning Kubernetes, widely thought to be Docker Swarm closest competitor and the most popular container orchestration tool out there. Designed by Google, Kubernetes is an open-source platform that orchestrates the deployment, management, and scaling of containerized applications. Kubernetes’ major components include:

• Cluster — Composed of nodes that run the configuration of resources used by the Kubernetes infrastructure to run applications

• Nodes – Container hosts that communicate with cluster services

• Pods – Temporary groups of volumes and containers found on the same host. A group of containers in one pod can communicate with each other through localhost.

• Labels — Tags assigned to containers that identify them as part of a pod

• Replication controller — Schedules pods across the Kubernetes cluster

Together, these components allow sysadmins to turn containers into a wide variety of applications.

What Makes Kubernetes Special?

Although sophisticated, Kubernetes is one of the more user-friendly container orchestration solutions on this list. The tool offers functionalities that lend themselves to availability, portability, scalability, and security. Additionally, Kubernetes is a tried-and-tested platform, backed by more than 15 years of experience gleaned from running Google production workloads.

So, sysadmins can rest easy knowing that failure/s in container orchestration will not affect the performance or availability of the application. Still, on the subject of reliability, Kubernetes is endorsed by the Cloud Native Computing Foundation (CNCF) and boasts of a thriving community, with 1,200 contributors and over 50,000 commits.

And finally, Kubernetes allows users to respond quickly to computer demands by scaling out, or conversely, scaling back, features. It gives you the freedom to choose operating systems, cloud platforms, container runtimes, and process architectures among others, all of which lets you improve performance by distributing workload across available resources.

Amazon ECS

Amazon Elastic Container Services (ECS) prides itself for being a scalable and powerful container orchestration solution that lets users control, manage, and deploy Docker containers and run containerized applications on Amazon Web Services (AWS).

If you’re already on AWS, using ECS means you no longer have to install and run a third-party container orchestrator, manage a group of VMs, and deploy containers on those VMs. Instead, ECS lets you make API calls to do the following:

• Launch Docker-enabled applications (and stop them, of course)

• Query the application state

• Interface with familiar AWS applications and services such as elastic load balancers, AWS IAM, Amazon CloudWatch, VPC, and ECR, as well as AWS CloudFormation, CloudTrail, and CodeStar.

It should be noted that containers orchestrated by Amazon ECS can only be run on Amazon Web Services EC2 as there is no support for third-party infrastructure—not yet, anyway. But if you want to access AWS goodies such as load balance and the logging and monitoring tool CloudTrail, ECS should be right up your alley.

What Makes Amazon ECS Special?

Ultimately, the biggest benefit of using Amazon ECS for your container orchestration is its seamless integration with existing AWS services. As mentioned earlier, if you’re already on AWS, there’s no reason not to use ECS—that’s if your primary concerns are cost-efficiency and simplicity.

Amazon ECS allows users teams to build virtually any kind of containerized application, from microservice architectures and long-running apps to machine learning technologies and batch jobs. You can also use ECS to import legacy Windows and Linux applications from an onsite server to the cloud as containerized applications. ECS also comes with AWS Fargate, an Amazon technology that lets you run containers without having to manage their underlying infrastructure.

This means you no longer have to worry about configuring, provisioning, and scaling clusters or VMs to host containers, which in turn, frees you from having to select server types, figuring out when to scale clusters, or optimizing cluster packing.

Nomad

Nomad is free and open-source cluster management and scheduling tool from software company HashiCorp. Unlike other container orchestrators like Kubernetes, which are specifically designed for Docker-containerized applications, Nomad supports other standalone, virtualized, or containerized applications on all major operating systems, giving sysadmins the flexibility to support virtually any workload in their hands.

And unlike Docker Swarm, which takes a container-centric approach to orchestration, Nomad uses a common workflow with a high-level abstraction that groups and assigns tasks to jobs. Basically, developers use a declarative language to define how and when an application should be deployed, along with what resources (e.g. RAM, storage, CPU) it needs to launch successfully. Nomad’s scheduling algorithm then takes these parameters and runs as many applications on a host to maximize resource usage.

What Makes Nomad Special?

Nomad’s single binary architecture means it is lightweight and simple, requiring no external services for storage or coordination. It’s a schedule and resource manager packed into one neat system. As a resource management tool, Nomad is programmed to gather data on each host’s abilities and available resources.

On the other hand, Nomad’s scheduling feature uses this gathered data to come up with optimized placements whenever jobs are submitted. This feature set opens the door to several possibilities. And if your team already depends on HashiCorp solutions like Consult and Vault, Nomad would fit in naturally into your current infrastructure, as opposed to choosing a tool like Kubernetes.

Azure Container Service

Last but not least is Azure Container Service (ACS), Microsoft’s container orchestration solution designed for Azure, its cloud computing platform and service. Released in 2016, ACS’s architecture is based on Apache Mesos, an open-source cluster manager, and lets users choose from three container orchestrator options:

• Kubernetes

• Docker Swarm

• Data Center Operating System (DC/OS) by Mesosphere Each orchestrator API endpoints are exposed in Azure Container Service, allowing the system to communicate with these endpoints and giving users the option to choose between popular orchestrators.

And because Azure uses open-source components in its orchestration architecture, this leads to a flexible service that offers maximum portability for both application configuration and container management.

What Makes ACS Special?

With ACS, DevOps teams can choose from a suite of tools and services that best matches their requirements for container hosting, orchestration, and scaling. The ACS also comes with very simple configurations of tried and tested open-source orchestration systems optimized for the cloud, resulting in a forgiving learning curve for users.

And because users can choose between popular orchestrators, teams and organizations no longer have to adopt new management new practices when moving container workloads to the cloud.

With the sheer variety of container orchestration solutions to choose from—each one with its own set of strengths and features—it can be hard to figure out which system is best for your team and organization.

Aside from looking at the features of each orchestrator mentioned above, you should also ask yourself and your developers whether you want to bind yourselves to one technology or architecture, or whether you want to maintain some independence and choose a general-purpose solution like Nomad.

It is also a good idea to look at the configuration management tool your team is already using. If you are using Docker, for example, then you may find more satisfaction and better ROI by using Swarm. Working with one vendor also simplifies your processes and makes the orchestrator learning curve (if any) far more forgiving.

But if you want a tool that is more lightweight, or perhaps one that is simpler to run in smaller clusters or QA environments, you may be better off with something like Nomad instead.

Remember, there are no right or wrong answers here. Your choice of container orchestration tool/s ultimately comes down to what works for your specific circumstances.