image What the Heck is a Container, and Why Do I Care? image cStor Launches ManageWise for Mimecast to Help Protect Clients From Advanced Email Security Threats

Demystifying Containers: Docker vs. Kubernetes & What You Really Need to Know

Demystifying Containers: Docker vs. Kubernetes & What You Really Need to Know

By Rob Heath, Solutions Architect, cStor


Containers Docker vs Kubernetes

The Nuts & Bolts of Containers

Containers emerged on the software scene when originally built into Linux in the form of LXC and were widely popularized by Docker in 2013. In a nutshell, containers are an ingenious solution to the common challenge of getting the software to run reliably when moved from one computing environment to another.

Whether it’s moving software from development to test environments, or from a physical data center to a virtual machine hosted on a public or private cloud, containers are packages of software (think complete runtime environment with applications and all of its dependencies) that house all of the needed elements to run the software in any environment. That means they share the operating system kernel so the software can act independently of the environment, so to speak.

But like many other tech advancements in recent history, the use cases for containers took off like wildfire. With it, competition emerged, as did an entire ‘containers ecosystem,’ and sure enough… a complete and formidable “hype cycle.” Fast forward to 2021, and the waters have been getting murkier ever since.

Yes, containers deliver on the promise of faster time to market and easier deployment, but there seems to be a lot of confusion about what they are, what they are not, what to run where and how, and more.

So, in this post, I’m going to clear some waters with a few helpful tips for you to navigate a clearer course to success.

1. Docker and Kubernetes are NOT the same things.

Docker is a container system. Kubernetes is a full-scale DevOps framework within which containers are run. Containers can help ‘level the locks’ so that when software is moved and the two environments are not identical, you can quickly identify where changes are needed to accommodate the move. For example, you test on Python 3.4 but production will be on 3.10… and lots of very weird stuff happens. Containers help quickly identify and resolve the conflicts with a telescopic lens rather than necessitate a complete rebuild.

It’s important to note that nearly every facet of the two different environments can cause issues in code and performance, such as network topology, security policies, storage and more, so be sure you take the bigger picture into account.

2. Docker is a type of container, not the only container.

I hear plenty of DevOps folks talking about Docker as if it IS containers; however, it’s just one type of container, not the only one. They just happened to be great at popularizing the technology, so the two words have become synonymous. For some alternatives, check out this helpful article.

3. Kubernetes is an open source DevOps framework originated by Google.

Although not a container, Kubernetes, or K8s, are designed to automate the deployment, scaling and management of containerized applications by grouping containers that make up an application into logical units for easier management and discovery.

4. Containers are not intended to run your mission-critical applications, nor should they… yet.

Containers were really designed to solve the environmental discrepancies in the DevOps world to make moving applications faster and easier, but the technology is not yet fully mature enough in my opinion to use for running your mission-critical operational software systems. In theory, they can run those systems, but it’s not best practice to do so just yet, and most applications have to be rewritten to a degree to use containers. That said, the benefits of doing so typically outweigh the effort.

Containers and virtualization are also two different things.

Virtual machines house an entire OS in addition to the application, and for each machine, a separate OS is running. On the other hand, containers share the OS kernel, and shared parts are read-only with each container having its own mount (a way to access the OS). That means containers are much more lightweight, consume fewer resources and boot almost instantly, whereas virtual machines are heavyweight and take time to boot and run applications.

Containers certainly have their place in speeding the software development cycle, and the open source Kubernetes framework is a proven way to deploy, scale and manage containerized applications. That all said, it’s important to use best practices within your DevOps framework, and understand that there’s almost never a one-size-fits-all solution. If you need a little help to figure out where and how best to leverage containers, drop me a line and we’ll hammer it out.

About Rob Heath
Rob is a Solutions Architect. With 30+ years in technology and IT, Rob is experienced in hardware, software product development and management, solutions architecture and design for enterprise and hyperscale data centers, semiconductor design engineering and microlithography.
window.lintrk('track', { conversion_id: 6786290 });