Container and Microservices Myths: The Red Hat Perspective

Misconception #1: Containers are New

Container packaging as we use it today is new (highlighted by the Docker/OCI image format), as is the concept of using container orchestration like Kubernetes to scale workloads across clusters of hosts. But the idea of sharing an operating system instance in isolating different parts of an application is not. From Unix Chroot to FreeBSD jail to Sun Microsystems’ Solaris Zones, solutions have been available for splitting up and dedicating system resources for some time now.

It’s also important to note that many of the technologies inherent to Linux containers (namespaces, cgroups, etc.) have been the foundation of many first generation PaaS offerings. What’s new is the ability to leverage the container capabilities of Linux to run and manage a very broad set of applications, ranging from cloud-native microservices to existing, traditional applications.

Misconception #2: Containers are Completely Self-Contained Entities

Despite their name, containers are not completely self-contained. Each container "guest" system leverages the same host OS and its services. This reduces overhead and improves performance, but may introduce potential security or interoperability issues.

Misconception #3: Containers can Replace Virtual Machines

Containers won’t replace virtual machines wholesale because they don’t work exactly like virtual machines. Each has its place in the enterprise, and companies must figure out which makes sense for what workloads. In short, virtualization provides flexibility by abstraction from hardware, while containers provide speed and agility through lightweight application packaging and isolation.

So, instead of thinking of containers as replacing virtual machines, companies should be thinking about containers as a complement to virtual machines — with the workload and infrastructure needs determining what to use when.

Misconception #4: Containers are Universally Portable

Containers depend on the host OS kernel and services to function, with "depend" being the operative word. Containers also must cross physical hardware, hypervisors, private clouds, public clouds, and more. Indeed, for containers to be truly portable, developers must have in place an integrated application delivery platform built on open standards.

As with so many things, standards are key — across the entire ecosystem.

Misconception #5: Containers are Secure by Default

There are many benefits to running containers in the enterprise, but those benefits must be weighed against the risk that can arise with the technology. Think about two physical machines — you can isolate them on the network. If one goes down and/or is infected with a virus, the other machine can be pretty easily defended. In a containerized environment, on the other hand, the OS kernel on the host system is being used by all of the containers. This kind of sharing brings with it inherent risk.

The level of isolation provided by the Linux kernel is combining process isolation with namespaces which works very well, but by design doesn’t close out all potential paths malicious code could take to break out and gain access to the host or other containers. That’s why technologies such as SELinux provide a needed additional layer of policy and access control.

What is most important, though, is what’s running inside the container. Industry best practices such as relying on trusted components obtained from trusted sources, complemented with scanning capabilities to "trust but verify" enterprise applications, apply to containers as well. The immutable nature of containers creates an opportunity to manage changes at the image itself, not the running instance. So the container distribution architecture, often implemented as federated registries, becomes a critical element in managing the security and patching of containers.