Innovation/Emerging

How Containers Are Making Way for the 5G and Edge-centric World – Part 3

Javier Guillermo By Javier Guillermo Sr. Staff Consultant at VMware January 6, 2020

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%.

Figure 1 – Container market share. Source Sysdig.com and Marketwatch.

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.

Figure 2 – Docker and Kubernetes Deployment, Source Medium – Deploy Any ML App – A Data Engineering Tutorial.

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.

Figure 3 – Kubernetes Cluster. Source: Sumo Logic and Google.

Architecturally, we can break down Kubernetes into these 3 components:

  1. The Control Plane (a.k.a. master node) which governs how Kubernetes communicates with your cluster (the actual orchestration).
  2. The nodes (where you can schedule the docker pods of containers – in other words, the physical infrastructure where you run the pods).
  3. The pods (a container of more than one docker containers).

Docker’s Competition

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.

Summary

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!

Blogs in this Series

How Containers Are Making Way for the 5G and an Edge-centric World – Part 2: Docker Architecture

How Containers Are Making Way for the 5G and Edge-centric World – Part 1

Javier Guillermo

About Javier Guillermo


Sr. Staff Consultant at VMware

Javier is a veteran technologist, holding a MSc in Computer engineering, an MBA, more than 20 professional Technical certifications, and 20-plus years of experience in the IT/Telecom industry with a focus on SDN/NFV, OSS/BSS, system integration, automation, cloud and orchestration.

Prior to his role at VMware (part of the Dell Technologies family of companies), Javier worked at Dell Technologies as a Principal Architect where he led SDN and NFV professional services efforts in Dell EMC Cloud Services with a Telco and VMware focus worldwide, including service ideation/creation, architecture, pre-sales and implementation. Previously, Javier worked at Fujitsu as Principal Planner, where he was responsible for planning cutting-edge SDN multi-layer and NFV application services, as well as building strategical partnerships with third-party vendors. In addition, he worked at Juniper Networks Professional Services, Nokia, and Schlumberger, where he assumed different roles such as Staff Architect, Solution Sales Manager, R&D Engineer and Group Manager at the U.S. Technical Assistance Center.

Javier loves health and fitness and is a certified personal fitness trainer. He enjoys movies and is an avid supporter of his hometown’s soccer team Real Madrid.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *