by Jonathan Cham, Staff Systems Engineer 

You have participated in one of the most transformational shifts in the IT industry. 15 years ago, could you imagine being able to move an application from one part of the datacenter to the other, while it’s up and running, with no user impact, in a click of a button? VMware has enabled an entire shift in the industry from hardware to software, from resource silos to pooled capacity and from manual driven processes to automation. Now with containers, an old technology that has been simplified by Docker and CoreOS, we can run multiple applications across a shared kernel instantaneously. Container technology has been quickly adopted by developers as an easy way to run distributed, complex, portable application architectures on their personal desktops. The power behind this portability, flexibility and collaboration has made containers a great choice for new applications. With this great power comes great responsibility, and the burden of that responsibility now lies in management, operations, and visibility into this new paradigm of application development. Let’s take a look at common misconceptions around containers before embarking on your container journey.

1. Containers sound amazing, time to migrate my VMs to containers
While there are certain scenarios where this might make sense, containers have a completely different operating model from VM’s.  This makes the migration from a VM to containers tremendously complex and difficult  Containers act like processes and share the kernel space, meaning that your application essentially shares the OS with the rest of the containers. Because containers are anchored to a specific process, when that process dies or stops, your entire container stops. If your container crashes the kernel, all containers on that host will also crash. You certainly don’t expect these type of behaviors with your VM’s so don’t try and migrate unless you understand all the different implications.

Containers also share hardware with the server as opposed to a VM that has their own hardware stack that can be configured. This hardware layer provides a certain isolation that security organizations have relied on. With containers, this hardware layer isolation does not exist and requires additional security elements like SElinux and AppArmor to provide security. A vulnerability in the linux kernel can compromise all the containers running on it.  Migrations are possible, but don’t mistake a container for a lightweight VM.

2. I’ll tell my developers to re-write our applications with containers
That’s great! Perfect use-case. However, applications built with containers facilitate a different application development paradigm. This is not just re-writing an application, but re-architecting the application. Best practices around developing applications for containers are keeping your application immutable, stateless, highly available, dynamic, shared nothing type of architecture. Imagine for a second if your VM could suddenly appear somewhere on another host, with a different IP and storage backend. How would you handle this situation? In a container world, where microservices are very popular, new datacenter components like service registry and discovery, image repositories, api gateways, container clustering, orchestration and scheduling are required to address the dynamic nature of containers.  Re-writing an application to use containers will require a re-architecting the application as well.

3. Containers will help my application deploy faster
Both operators and developers can benefit greatly from containers because of the abstraction between the 2 layers and can facilitate CI/CD pipelines to deploy applications quickly. It’s a great separation of duties where developers manage the containers and operations manage everything underneath. However, when you look at an application deployment timeline, 95% of that time is people and process. Unless you have your people and process structured to facilitate a devops mentality, you will gain very little benefit from using containers.  To this day, there are still large enterprises that require months of lead time just to get compute/storage/network resources.  Do your change requests take 2 weeks?  Do you have 3 layers of approvals?  Containers won’t accelerate your people/process barriers but can be a fantastic platform to start breaking down the barriers that prevent agility.

4. Other customers run containers in production, I can too.
Think for a second all the IT systems and components that are required to run your datacenter today. Monitoring tools (network, compute, storage, application), change management, compliance, config management, authentication, security, backup, deployment tools, etc. Some large organizations have 100’s-1000’s of tools they use to run their datacenter, both out of the box and custom built. Unfortunately, very little, if any of those tools translate well to being used in a container world. That’s why you see a large, fragmented set of open source tools to address these gaps, one by one, adding a lot of operational layers to deploying containers. Many organizations end up building their own tools to support their container deployments.  Some customers who decide to run in dev/test can get some experience running containers but will have to add an additional operational layer to help migrate the application back into VM’s for production deployment.  Yes, you can run your containers in production — it will just require an entirely new operational paradigm and a toolset that is still in its maturing phase.

Hopefully, these don’t deter you from embarking on an experimentation journey with containers.  At VMware, for customers who want to dive into containers, we’re making some big bets to help them transition to a containerized environment.  We have built an entire stack of container related technology (and open sourced many of them too!) along with container identity and access management to help our customers adopt containers with an enterprise like approach.  Our vSphere Integrated Containers launches a 25MB Photon Kernel (pico version of Photon OS) and runs containers as if they were VMs.  The ultimate benefit of having a VM backed container is being able to leveraging all your enterprise investments around security, management, operations, and compliance.  From a developer point of view, it is as fast and as easy as a container and on the backend, we get the manageability and security of a VM.   IT is happy.  Developer is happy.  

You’ve built a successful business and while you want to experiment with new technologies, you also want to minimize the risk in doing so. We talk to many customers and we’ve committed to our customers to help them drive agility to their business no matter what the technology. We understand the challenges and are in the best position to help you adopt new technologies without sacrificing enterprise grade capabilities. Are you ready for containers? You can be with VMware.