How Containers Are Making Way for the 5G and Edge-centric World – Part 3
In Part 1 (5G and Edge-centric World) and Part 2 (Docker Architecture) of this blog series, we talked about container architecture, focusing on Docker, the definition and origins of this technology, and how companies like AT&T and Dell are leveraging the technology for the 5G rollouts. This time around, we will cover Docker alternatives and how we can automate and orchestrate containers.
Overview of Container Market Share
In Part 2 of this series, we provided the chart below to show the various container competitors and their respective market share, and explained how and why Docker holds over 80% of the market. Competition for Docker, however, is increasing steadily. Same as back in the day when Netscape held nearly 99% of the market share and the eruption of new browsers changed the landscape completely. I personally believe that Docker will still rule for many years to come – holding at somewhere near 50-60% of the market – with third parties vying for the remainder. I won’t cover Linux Containers (LXC) here because Dockers was designed to extend the capabilities of LXC; nor will I talk about Mesos, since global usage is less than 5%.
RKT – Application Container Engine, Cloud Native
So, let’s talk about RKT.
Why is this standards-based container engine growing so fast?
If I had to summarize the reason using a single word, it would be Security. As we explained in Part 2 of this series, Docker architecture dictates that everything runs through a central daemon (the docker server a.k.a. dockerd) and that is, arguably, a design flaw in itself. Furthermore, up to version 1.10, containers had to be run as root, and as anyone who has administered software would tell you, that’s very dangerous granting opportunity for all kind of attacks to capture the super-user privileges.
RKT was designed from the start to be more secure, faster, open (uses an open source container format called appc versus docker which has a proprietary image format) and “composable.” You may be asking, what’s composable? It is an architecture system design principle that deals with the inter-relationships of components. It also means that it contains all the necessary tools for downloading, installing, configuring and running containers in a self-contained (modular) and stateless technique (each request is an independent transaction).
As we can see in some ways, RKT is technology-superior to Docker, with a lot of similarities (both use a full set of RESTful API for integration) but in the end, on anything open source, it is the community of users who will determine its ultimate success, and while CoreOS RKT has an active hub of communities, it is nowhere as popular as Docker community’s portal and forums. On top of that, Dockers keep adding more and more features, plus correcting problems upon every release.
Enter Stage Left, Kubernetes
All right, so how about Kubernetes?
Is it another container platform? Not really. A lot of people think so because it is tied to containers, but Kubernetes (a.k.a. k8s or kube) is not a container platform, but a container orchestration solution that allows you to manage your container-based workloads.
And, what’s an orchestration solution?
It really has nothing to do with an orchestra or music 😊, it is a software platform designed for scheduling and automating the deployment, management, configuration and scaling of containerized applications.
The 3 Components of Kubernetes
Kubernetes was initially developed by Google engineers and a “child” of Borg, and that’s has nothing to do with the aliens of Star Trek the Next Generation. In this case, Google used it internally as a cluster manager. This product evolved and became Kubernetes, and in 2014 became an Open source project.
What specific task can Kubernetes take care of, you ask?
Plenty! From deployment, configuration, rollout (I don’t mean deployment but changes to a previous deployment), HA-Self Healing (if the container fails, Kubernetes takes care of its restoration/replacement), load balancing, storage provisioning, scaling, etc.
Architecturally, we can break down Kubernetes into these 3 components:
- The Control Plane (a.k.a. master node) which governs how Kubernetes communicates with your cluster (the actual orchestration).
- The nodes (where you can schedule the docker pods of containers – in other words, the physical infrastructure where you run the pods).
- The pods (a container of more than one docker containers).
It is important to note that there are other container orchestrator options, some of them very advanced, but none that have come close in popularity of Dockers. One of them is Mesos from the developers at Twitter, which goes beyond container orchestration and offers a platform that can coordinate both containerized and non-containerized components. Probably the most popular “competitor” is Docker Swarm, another product created by Google. Swarm is also a lot less complex but easier to deploy, and in the latest Docker versions, bundled with Docker.
And that concludes my dissertation concerning Docker alternatives and how we can automate and orchestrate containers.
I want to conclude this blog series with the news that I have accepted a role with VMware, also a Dell Technologies company. I look forward to bringing you more from my new role. Stay tuned!