http://thevarguy.com/open-source-application-software-companies/container-and-microservices-myths-red-hat-perspective
Red Hat executive
Lars Herrmann discusses container and microservices trends, including
container portability, security and standards.
thinkstock.com
What are
containers and microservices? What are they not? These are questions
that Lars Herrmann, general manager of Integrated Solutions Business
Unit at Red Hat, answered recently for The VAR Guy in comments about
popular container misconceptions and myths.
It's no secret that containers have fast become one of the hottest new trends in computing. But like cloud computing or traditional virtualization before them, containers do not live up to the hype in all respects. In order to leverage container technology effectively, organizations need to understand the history behind containers, their limitations and where they fit in to the data center landscape alongside virtual machines.
The discussion of container misconceptions below is a condensed version of commentary delivered by Herrmann to The VAR Guy.
It's no secret that containers have fast become one of the hottest new trends in computing. But like cloud computing or traditional virtualization before them, containers do not live up to the hype in all respects. In order to leverage container technology effectively, organizations need to understand the history behind containers, their limitations and where they fit in to the data center landscape alongside virtual machines.
The discussion of container misconceptions below is a condensed version of commentary delivered by Herrmann to The VAR Guy.
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.
No comments:
Post a Comment