In 2019, when deciding how to run your application during development, staging, and production, there was a lot of buzz about containerization. Perhaps you may have heard of Docker or Kubernetes?
But as with any new tech trend, there’s a lot of speculation. In 2019 in particular, Docker and Kubernetes saw a bit of pushback from Corey Quinn, co-founder of the DuckBill group. Quinn’s controversial opinion pinned Docker and Kubernetes as two sides of the same coin.
“I might use Docker, if you’re using Kubernetes, you almost certainly are—but there’s no part of that story where you’re cutting a check to Docker.”
But it’s for this exact reason, that containers and containers and Kubernetes will continue to grow. As of December 6, 2019, Kubernetes has 35,000 individual contributors, over 2,000 companies, and 1.1 million contributions.
With both tech trends steadily increasing, 2020 might be the year for your web application to adopt containers and Kubernetes, if you haven’t already.
Let’s talk containers
When it comes to the majority of applications, if you follow container best practices, the time, money, and effort you put into containerizing your app (or paying someone to do it for you!) will result in infrastructure that is easier to set up, maintain, and upgrade. However, there are a few niche scenarios where you’d want to keep your infrastructure on Virtual Machines (VMs).
This article will cover:
What containers are.
How containers differ from VMs.
The benefits of containers.
When you might want to stay on VMs.
Use cases for containers.
An introduction to Docker.
An introduction to Kubernetes.
Definitions
Containers
Containers are a way to separate your app from its environment. They allow you to package your application along with its configurations and dependencies into a single unit that can be “shipped” to any environment. These environments include private or public clouds, data centers, or even your desktop.
This separation allows developers to focus on code and operations engineers to focus on deployments because they can feel confident that the application will behave the same way across development, staging, and production.
VMs
Virtual Machines (VMs) are a way to simulate a physical computer. VMs include all of the same components as a physical computer, like an operating system, a network interface, and applications, etc. However, instead of using their own hardware, they are sandboxed and run on top of a physical computer.
This means that one physical computer can run multiple VMs, each with its own isolated components. VMs allow for development, staging, and production to use the same image to run application code.
Key differences
Operating systems
The biggest difference between containers and VMs is operating system (OS) autonomy. Containers employ OS virtualization, which allows them to leverage the features and resources of a host OS, whereas each instance of a VM is a full guest OS.
In other words, each VM instance needs to virtualize an entire OS, which includes components that your app doesn’t care about like certain kernel modules. On the other hand, containers isolate only resources that are dedicated to your application. This allows them to be indifferent of which OS you run them on.
As a result, containers have a lot more flexibility when it comes to choice of OS.
Why do I care about operating system flexibility?
One word: portability. OS virtualization allows you to migrate your application to a different system without impacting how your application is built and run. This is ideal for hybrid or multi-cloud solutions and reduces the risk of vendor lock-in. If you decide to switch hosts or a better solution comes along, the transition will be seamless with little to no overhead.
TechAdvisory.org talks about why you should choose virtualization here.
Deployments
Similar to the flexibility of OS choices, containers also offer more flexibility when it comes to deploying your app.
In order to deploy a containerized app, all you have to do is pull the image and deploy it to any compatible platform. This is usually a quick process and doesn’t require a lot of resources on the server.
In order to deploy an app using a VM, you must first build and configure the VM, then install the application based on a target operating system. After the installation, you can then publish the app to the desired platform. This is usually a much longer, more resource-intensive process.
As a result, you can usually run more applications on a single physical server using containers rather than VMs.
Runtime dependencies
Containers include all of the libraries and dependencies that an application needs at runtime. On the other hand, runtime dependencies often need to be installed or updated on a VM after it is built. This is one of the reasons why it can take a long time to set up a new VM.
Occasionally, the host may need to provide the container information such as environment variables, but in terms of functional libraries and dependencies, a container should include all of the necessary components.
Benefits of Containers
Performance
When it comes to administrative overhead, unless your application needs to perform high volumes of reading and writing to the disk, like a database or a data source, containers are typically faster. For instance, in a 2018 study by Zhang and team, the researchers found that bootup efficiency was better for every test instance of a container compared to a KVM virtual machine.
When it comes to performance, containers definitely take home the medal for efficiency. Since containers are an abstraction at the application layer, they are a lot more resource efficient. Compared to VMs, where you must assign memory and disk space before building one, containers are layered at the application level, so multiple containers can share the same resources. This prevents a scenario where memory and disk space is set aside for an application even when its not being used—a common side effect of virtual machines.
As a result, you can typically run many more containers on the same hardware than you can VMs, which is a huge cost-saver for smaller applications.
Compatibility
Containerization makes your app more compatible with state of the art technologies. It’s an understatement to say that containers have become trendy. Although VMs have a collection of tried-and-tested tools from over time, most of the newer innovations that actively help implement industry standards and best practices are built for containers.
Here is a list of some of the most popular tools for containers.
Moreover, a lot of the big players in the world of containerization have open sourced some pre-built container images that you can easily customize for your app. All you have to do is add a layer that works specifically for your app. Although pre-built AMIs exist for VMs too, like over at Bitnami, they’re a little more difficult to set up and customize.
DockerHub
DockerHub is a repository of over 100,000 container images from the community and software vendors that you can customize for your application. Of course, they are images meant for use with Docker, the most popular containerization platform.
Reproducibility and immutability
Containers are reproducible by default. The nature of a container is such that everything is well-defined and reproducible. Although it is possible to implement reproducibility on a VM by using Infrastructure-as-Code tools, it is heavily reliant on how well your team does the implementation and adheres to best practices, which is inevitably more prone to human error.
Containers images are also immutable. The nature of VMs allows you to reconfigure them after they’re built. This means that if a change is made off the books, it’s harder to track. Although it’s not impossible to maintain configuration management and provisioning best practices on VMs, the immutability of container images definitely encourages them more.
Due to their reproducible and immutable nature, it’s easy to update a container by just rebuilding the image. With VMs, updates need to be done over time, which means that what’s live in production may not always reflect the configuration originally used to build a VM. In a worse case scenario, an updated container can also be easily rolled back to a previous image, whereas it’s much more difficult to roll back a VM.
When to use VMs
As previously discussed, there are a few scenarios where VMs are more suited to your application than containers.
Performance-critical or stateful applications
Stateful, performance-critical applications, like databases, are just harder to run on containers. They require fine-grained controls that only a VM used to provide such as network/OS-level performance tuning.
Nowadays, despite the solutions available for these database containerization challenges, we still recommend that you keep these applications on VMs because it’s often just not worth the extra effort. Simpler solutions are almost always better.
Multi-user environments and security
Unlike performance-critical or stateful applications, it is much more viable to deploy applications using virtual machines in a multi-user environment. The default configurations for a container is not as secure as a VM, often not abiding by the principle of least privilege. VMs have many more options for fine-grained security controls, troubleshooting, and isolation in terms of security.
However, many security considerations have enough workarounds and alternative solutions for most apps to safely switch over to containers. For the majority of applications, container security is sufficient for their needs.
According to Forrester research, in 2020, security both for containers and cloud-based applications is expected to continue to be a large industry topic for discussion and continuous improvements.
Use Cases
Below are some of the most common use cases for containers. If you want some more specific examples, see this early 2019 DZone article, where they interviewed 33 IT executives on how they were using containers.
Migration to the cloud
Since container images are bundled with their dependencies, it is easier to migrate a containerized app to a single or hybrid cloud solution. Container runtime will ensure that your container will run on any cloud provider, as long as your app is not reliant on cloud-specific tools.
Containerization also helps avoid the dreaded “lift and shift,” where you take your code base and just plop it on the cloud, resulting in tons of unexpected errors, or even worse, a massive increase in costs! With containers, you can confidently adopt more of a “move and improve” attitude, where you verify that your code base works how you intend it to and port it to a system where your developers can focus on the code and your operations engineers can focus on the environment.
Breakdown of monoliths
Monoliths are single servers that contain all of an application’s services. The biggest problem with monoliths is that if something happens to the server, the entire application is at risk of going down.
Many companies with legacy apps are now moving toward breaking their monoliths into microservices. Microservices isolate single services, allowing independence between services and less risk of a shutdown of an entire app. If a microservice’s server gets affected, the rest of the application can keep running until you can spin up a new instance of the affected server.
Containers make this easier because they allow you to capture each microservice in a separate container, if needed. At the very least, each container can act on a single purpose, even if it contains more than one service.
CI/CD initiative support
Containers make it easier to employ continuous integration and continuous deployment (CI/CD) best practices. For example, containers allow you to deploy the same application across your workflow, making it easy to ensure that you’re developing, testing, and deploying the exact same application. As a result, it is also easier to re-distribute and implement automation, both key factors in CI/CD.
Scaling
Since you do not have to define the memory or storage for a container before setting it up, it’s much easier to add or remove resources as needed. As such, when used in conjunction with a container orchestration platform like Kubernetes, containers are more suited for the best practice of scaling horizontally.
Especially for businesses that follow the e-commerce calendar and have varying degrees of traffic throughout the year, scalability is a huge factor for containerizing an application.
Replication for research
People who perform research need control variables and containers are a great way to ensure that the same software is used to analyze data or replicate tests. This is relevant not only for life sciences, but also machine learning and artificial intelligence.
Docker
Docker is the most well-known, open-source containerization platform. Why? It’s easy to use and easy to ship any application as a container.
All of the aforementioned benefits of containers can be realized with Docker. In particular, most state of the art technologies are made specifically to work with Docker, not just containers.
There are tons of free resources online to learn Docker. Just last month, medium user javinpaul, editor of Javarevisted blog, released a list of 10 free courses for beginners to learn Docker.
What are some Docker alternatives?
At this point, Docker is considered the industry standard for containerizing applications, but the Container Journal did release a list of 5 alternatives to Docker, if you choose to explore outside of this area.
Kubernetes
Kubernetes is one of the most commonly used open-source container orchestration platforms. Kubernetes has helped DevOps culture evolve and continues to bring numerous benefits to an application if you just use it.
Although the learning curve for Kubernetes is a bit above that of Docker, the community keeps detailed documentation and tutorials with the latest solutions available to common problems that you’d come across. In 2019, a post written by Shuveb Hussain went viral, called “A Manager’s Guide to Kubernetes Adoption.”
What are some Kubernetes Alternatives?
Unlike containers, there are more well-known alternatives to Kubernetes, although Kubernetes is one of the more widely used container orchestration platforms.
Conclusion
2019 saw a bit of debate on the future of Docker and Kubernetes, but at the end of the day, it looks like containers are here to stay.
Containers have been used for everything from accommodating peak seasons for the e-commerce calendar to analyzing the impact of climate change.
In 2020, it is not a stretch to believe that containers have the potential to run almost anything.
The resource efficiency, compatibility, and reproducibility are only the start of what containers can do for your infrastructure.
How do you think containers and Kubernetes can help your infrastructure? Send us a message and we’ll be happy to discuss how your operations can benefit from containerization.