Although containers aren’t new (been built into Linux for 10+ years and been available in FreeBSD, AIX and Solaris), containers seem to be all the rage, and for good reason. The agility containers can bring to an IT team alone make them appealing, but add in the security benefits that the self-contained nature of containers brings, they seem like a no brainer. But even with numerous benefits, there is also a lot of confusion about what they really are and what is the best-fit scenario. So, we thought we’d break it down…
First and foremost, are containers and VMs the same thing?
Quite simply, no. It is a very common misconception that containers and virtual machines (VMs) are interchangeable, or at least similar, but they are not. So, let’s start by defining each…
- As server processing power and capacity has increased, applications could not take advantage of this, so virtualization technology was created to allow for multiple “virtual computers” to be run on a single piece of bare metal hardware.
- A “hypervisor” (or a VM) manager creates and runs VMs and sits between the hardware and the VM.
- A single server can host multiple VMs. A Windows Server VM and a Linux VM can run side by side on the same physical machine.
- Each VM has its own operating system, libraries and applications.
- VMs can be gigabytes in size.
- VMs can consolidate multiple applications onto a single system with heterogeneous operating systems.
- VMs primary goal is to increase the utilization of the underlying physical machine.
- Containers are pieces of software that sit on top of the physical server AND its host OS (Linux or Windows). The OS kernel is shared across containers. Containers may also share common frameworks and libraries (e.g. .NET, JVM). In other words, the container has the entire runtime environment, minus the host OS.
- Containers are light, usually megabytes in size, where VMs are often gigabytes in size.
- Containers are good for taking a monolithic application that would require purchase of new hardware or configuration of a new VM and allowing it to scale on existing deployed VMs.
- Containers allow software to run reliably with minimal changes when moved from one computing environment to another, such as moving a container from an on-premises environment into a public cloud.
- In this figure, App1, App2, App3 could be monolithic applications, 3-tier applications or microservices. Notice a single OS which is then shared across the containers. Containers primary goal is consistency of the software environment regardless of where it is physically residing.
What are the benefits of containers?
There are very clear benefits that come with the adoption of containers:
- Containers are only tens of megabytes in size verses a VM that would be gigabytes in size.
- VMs take minutes to boot up the operating system and then start an application, while containerized applications start almost instantly. At scale, this allows for “just-in-time” creation of multiple instances of an application.
- Containers are more modular. Applications can be split into modules and deployed as microservices (e.g. front end, business layer and data layer would each be their own modules)
- Containers allow enterprises to deploy and scale existing monolithic applications without the need to procure new hardware and/or new VMs. In many organizations, it takes weeks/months to purchase new hardware or deploy a new VM into their environment, where containers allow for a much shorter deployment/update cycle.
- Containers and Container Orchestrators allow for a smoother and more efficient DevOps Practice by helping to enforce consistent environments.
- Containers allow for less effort to break apart monolithic applications and convert them to a microservices architecture.
- Overall, containers enable a much more agile software development lifecycle.
So, what are my options in containers and orchestrators?
Container Orchestrators (aka container management) provide tools to allow for deployment, scaling, availability and management of containers, both on-premises and in public/private clouds. They’re essentially a manager of your containers across multiple physical environments. The current most popular ones are:
- Docker – Open Source, most popular
- Apache Mesos – Open Source, includes orchestration
- Kubernetes – Open Source, most popular container orchestrator
- Red Hat Open Shift – On-premises private platform as a service for RHEL
All support the Open Container Initiative (OCI) under the Linux Foundation. This is important because all major providers are members of OCI/Linux Foundation.
In addition, Microsoft Azure has some excellent container service offerings:
- Azure Container Instances – Create a container instance by pointing to your Docker Image in Docker Container Registry. Essentially, containers on-demand.
- Azure Web App for Containers – Like Azure App Services, but instead of publishing your code directly into Azure you point the App Service to your Container in the Docker Container Registry
- Azure Kubernetes Service (AKS) – Fully managed service for deploying and managing container applications. Provides a “serverless” experience, integrated CI/CD and enterprise grade security.
- Azure Service Fabric – Native Azure Microservices using container images for both Windows and Linux
- Azure Batch – High Performance/High Scale computing with containers including job scheduling
- Azure Container Registry – Store and manage container images across all types of Azure deployments
So, why don’t we move everything into containers?
Containers can run all sorts of applications, but because they are so different from VMs, a lot of the older software that many enterprises are still running won’t translate to this model. However, VMs can be used to move older applications into a cloud service. So even though containers have their benefits, VMs still do too. It really boils down to… it depends…
Want to learn more? Download this informative eBook from our partner, HPE, and learn why container technology is a critical piece of IT modernization solutions that will drive digital transformation, hybrid environment adoption and hyper-convergence.