There’s a reason why IBM’s YouTube explainer video on “containers vs. virtual machines (VMs)” has 243,000 views and counting. There are still plenty of developers who work with VMs and have just a surface-level understanding of container technology. That said, this surface-level understanding may paint a picture of containers as the end-all-be-all of development. In reality, containers do offer many advantages over virtual machines including strong isolation, lower operational burden on IT and simple replication. But they also have their limitations.
Instead of running over to YouTube to see what those are, continue reading to hear from three Chicago engineering leaders about the key advantages of using containers over VMs along with the best uses of this tech and limitations — and how to overcome them.
If you follow e-sports or consider yourself a gamer, then you’ve probably heard of SteelSeries. The company makes gaming hardware, including mice, controllers and headsets, along with software for managing peripheral settings and capturing and editing in-game video clips.
What are the key advantages of using container clusters over virtual machines or other types of architecture?
Container clusters have several benefits over virtual machines, and the ones that we have been able to leverage most are the portability and consistency. Updating or migrating services sometimes requires us to change the underlying hardware or operating system. Because containers are able to easily adapt to whatever changes we throw at them, we have the ability to quickly iterate. Additionally, our e-commerce traffic is increasing rapidly, with additional exponential spikes in traffic for holidays, sales and other promotions. We need to be able to deploy and scale to meet that demand, all while ensuring that the behavior will remain consistent.
We are a small team, and containers allow us to be a force multiplier.”
In your experience, what is the best use case for container technology?
In my experience, the consistency in deployment in an autoscaling group has to be the best use case. We can build locally in an environment that mimics production, deploy configuration for stakeholder testing to staging and then upon approval deploy the final code to production. This gives us a high level of confidence that the code we write locally will not have any adverse effects in production — something that has happened in virtual machines or mixed development environments, like Windows or OS X locally versus Linux in production. Then, when a container or image is updated, everyone can grab the newest version and be up and running in minutes while we deploy that same new image to other environments.
What are the limitations of container architecture, and how do you work around or mitigate them?
The containerization ecosystem can be hard to parse, and some container systems do not work well with others. Containers also add another system for engineers to learn in order to keep up to date. To mitigate this, we focus on choosing one container ecosystem and sticking with it, which helps us share knowledge on the system more readily. Our entire approach from the beginning of the container journey is continued focus on consistency, from developer experience to deployment.
Vail Systems’ telephony is designed to enable companies to have better conversations with customers. It does this in a variety of ways, from increasing call clarity and automating caller authentication to speech analytics technology that analyzes non-verbal cues and alerts agents when callers may be getting aggravated.
What are the key advantages of using container clusters over virtual machines or other types of architecture?
The key advantage of container virtualization is its “lightweight” attribute. Containers have proven to be the perfect middle ground between the legacy “all applications installed on the same servers” way and the resource-heavy separation that comes with virtual machines. While virtual machines remain the strongest isolation tool to separate environments, it is cost-prohibitive to run a separate virtual machine per application in a context where tens or hundreds of applications run in a cluster. Not to mention potentially duplicating the setup several times to achieve development, test, staging and UAT environments.
Containers provide strong isolation, easy portability and simple replication while keeping the resource overhead required to a minimum. They allow a system to run tens or even hundreds of containers performing different tasks and requiring varying dependencies on a single server with minimal impact.
To fully achieve its potential, container technology must be coupled with changes in the way applications are built and how they interact.”
In your experience, what is the best use case for container technology?
At Vail, we have found that one of the best use cases for containers is reproducing behavior in different environments with minimal effort. Containers provide the building blocks to package all dependencies, configurables and binaries of a given application into a single artifact that can be launched in the same way on any container-enabled platform. This gives a great answer to the age-old question, “If it works on my machine, will it work on the production server?”
Thanks to their ability to easily recreate the same environment when loading the same artifact, containers provide a great tool for developers to receive fast feedback on potential production issues of their applications directly in their local development environment or in a test environment. Containers make this happen without the need for developers to wait until the end of a development cycle to find out if their changes will negatively impact the staging and production environments.
What are the limitations of container architecture, and how do you work around or mitigate them?
To fully achieve its potential, container technology must be coupled with changes in the way applications are built and how they interact. Containers are inherently more complicated to manage than bare-metal applications. For example, they require special networking configurations to achieve isolation. Furthermore, non-stateless apps need to persist data outside the container, which must be readily available and accessible irrespective of where that container is running. Managing containers can be an incredibly complex, manual process when hundreds of apps need to live and interact in a cluster.
We have taken several steps at Vail to mitigate these issues. First, we utilize Kubernetes, a container orchestration system to drastically simplify container management, networking and data access. Secondly, we have advertised the requirements for containerized applications through the company via a series of academies for developers to ensure everyone can benefit at the earlier stages of development. This has also ensured that applications are designed with containers in mind so that they take full advantage of the capabilities offered by this platform.
Stride Consulting is a software consultancy whose clients include Spotify, Casper and Codeacademy. In addition to building custom software, Stride also offers technical assessments and an “interim CTO” service.
What are the key advantages of using container clusters over virtual machines or other types of architecture?
Container clusters offer three main benefits over virtual machines: more efficient use of compute infrastructure, greater ease of scalability and lower operational burden on IT and software teams. As their name suggests, virtual machines must virtualize the hardware they run on top of. This makes virtual machines more resource intensive to run in terms of CPU, memory and storage than containers. Conversely, containers run on top of their host machine’s operating system, making them more lightweight. In general, running a particular workload in a container will be less costly than running it in a virtual machine.
Container clusters are more easily scalable than virtual machines because each container has a shorter startup time than a new virtual machine, and the lower resource footprint of containers allows for more containerized workloads to be run than equivalent virtual machine workloads given the same infrastructure. Finally, containers are generally easier to maintain and operate than virtual machines. Containers run on top of a host operating system, so operating system updates and software dependencies are decoupled from application workloads. Container orchestration software, like Kubernetes, helps manage the lifecycle of containers with sophisticated scheduling rules that are challenging to achieve with virtual machines.
For high-performance use cases, containers have inherent limitations that cannot be overcome.”
In your experience, what is the best use case for container technology?
The most commonly successful use case for containers we have seen is for developing a microservices architecture. When software systems get large enough, development throughput can slow down due to the large number of developers making conflicting changes to the same parts of a codebase. A solution to this problem is to break large systems into microservices: a collection of loosely-coupled services that can be deployed independently of one another and owned by a small team.
Containers can help enable microservices because they are less resource-intensive and are easier to deploy and scale than virtual machines. This enables independent software product teams to operate the software that they write rather than relying on a separate operations team. In this way containers support the DevOps movement.
What are the limitations of container architecture, and how do you work around or mitigate them?
Limitations of containers include difficulty supporting workloads with complex dependencies and ARM-based architectures, the ongoing need to patch and maintain dependencies, and performance limitations compared to bare-metal deployments. Workloads with complex dependencies can be difficult to containerize. Examples include machine learning systems that may require GPU access or edge/IoT applications that use ARM-based architectures to operate in the field with low power consumption.
Multi-staged builds can help simplify complex dependencies. Customized base container images are built and then composed as building blocks for more complicated use cases. Consistent use of tagging can help designate containers for use with specific hardware sets, like GPU requirements or ARM-based architectures. Security scanning can be run to identify containers with software packages that have security vulnerabilities that must be patched.
Finally, for high-performance use cases, containers have inherent limitations that cannot be overcome: overlay networking and interfacing between containers and host systems are two unavoidable performance hits of using containers versus bare metal. In those use cases, the only choice is to deploy to a bare metal system.
