There is a tremendous buzz in the industry at present with regards to containers, however because it is relatively new it is moving at an equally tremendous pace with all the big players looking to become dominant in this space. This series of articles attempts to bring some clarity to the jargon, and let you know what’s baking out there, likely consumption models and benefits.
Firstly, what is a container?
A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerised software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure. A container is an instantiation of the container image. The primary basic benefits derived from the utilisation of containers is that your result is an immutable image of your application which can be run on any system, without change, which supports the open container specification helping to avoid becoming locked in and with start-up times significantly improved from traditional hosting.
What is a container runtime?
Containers provide operating system level virtualisation by running processes in isolated environments, usually also managing resource allocations like CPU shares and RAM. A container runtime enables users to make effective use of these mechanisms by providing APIs and tooling that abstract the low level technical details.
In the early days, several projects sprung up looking to become the default container runtime. Because there was such a variety of products, an emerging standard for the container runtime, containerd, appeared. Contributed to the CNCF (Cloud Native Computing Foundation) by Docker inc.
Containerd is an industry-standard core container runtime specification with an emphasis on simplicity, robustness and portability. It can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments.
Containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users.
Containerd includes a daemon exposing gRPC API over a local UNIX socket. The API is a low-level one designed for higher layers to wrap and extend. It also includes a barebone CLI (ctr) designed specifically for development and debugging purpose. It uses runC to run containers according to the OCI specification.
What is a container orchestrator?
As containers became popular, people realised they needed an automated way to manage the hundreds or thousands of containers inside a cluster. Within the container runtime, automated orchestration ceased to be an option.
You might have been able to manage a virtualised 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.
So tools such as Docker Swarm, Marathon and Kubernetes were developed. Their main job is to automate the provisioning of containerised infrastructure, provide load balancing and discovery for the services that run inside the containers plus enable auto-recovery and scaling of the containers.
At this stage the runaway leader in container orchestration, based on project contribution and ecosystem, is Kubernetes, it was originally conceived by Google and based on their own internal orchestrator Borg. Google have subsequently contributed Kubernetes to the CNCF.
The Newstack team produced a great introductory piece to learn more
It is with the advent of container orchestration that the reality of using containers in production, at scale, became within reach of the ordinary enterprise. Allowing enterprises to be able to adopt container based platforms and begin to benefit from improved application packing, speed to start, immutability and automation of runtime needs.
In the next in this series of articles we will look at container adoption.