Container adoption is making dramatic jumps from year to year. In 2018, fewer than 20 percent of IT organizations had begun to investigate containers, but that figure has jumped to over 35 percent in just 12 months. In a short space of time, containerized applications have gone from prototype to production – but are containers right for your application?
Why Wouldn’t You Choose Containers?
Right now, containers require a certain amount of manpower, a certain pre-existing technological base, and a certain amount of time/budgetary commitment.
For example, the deal with a traditional VM is that it mimics the entirety of a computer or server and it contains everything that your applications need to run. There’s no need to tweak your application before deploying it to a VM, in other words.
Containers, on the other hand, are ideal for what’s known as a service-based architecture, in which the services that comprise an application are separated into disparate parts. To get the most from containerization, you’re going to have to do the work to refactor your application. If you have a small team, a lot of projects, or a relatively complex application, there’s no reason to use containers.
What if you do have a large team, a decent budget, plus experience working with containers in the past? Separate from manpower constraints, is there a technical reason why your application might perform better on a VM or on bare metal?
Some Technical Reasons Not to Run Containers
Containers are a relatively new technology, which means that many tech evangelists treat it as a panacea. Unfortunately, containers aren’t a cure for the common application. Here are some of its technical limitations.
- The Speed Advantage Isn’t What You Think
Containers are small and resource-light, so the conventional wisdom is that they’re faster than VMs. While this is true, the speed improvement really depends upon their ability to effectively manage resources from the host. You won’t be able to wring that much performance improvement from containers if your hosts are under-resourced. Finally, when we say that containers are faster than VMs, it’s important to note that VMs are only two percent slower than bare metal on average – the apparent speed boost isn’t a game-changer. - It’s Tricky to Manage Persistent Applications
Let’s say that your application needs to store some data inside of itself – but it’s also comprised of many small containers. Each container has its own storage requirements, which are automatically scheduled every time the container gets spun up. Some containers have different requirements. At this point, the requirements of containers make it difficult to support a complex and persistent database. It’s not that it can’t be done – it’s that a simpler approach might be easier and more effective. - Security Second?
Container platforms like Docker have gotten more secure over time, but they’re not ironclad. Since they borrow code libraries from the host, they’re fundamentally not as secure as VMs. Vulnerabilities in Docker can therefore allow malicious software to break out of a container and infect the host environment.
By no means are we saying that Docker is a bad platform, or that you shouldn’t experiment with it or put it into production. What we’re saying is that when you understand Docker’s limitations before you start working with it, you’ll have a much better experience and end up creating better and more stable applications, faster.
Device42 Helps Manage Docker
If you want to do more with Docker, watch this space. Device42 offers detailed application dependency mapping for datacenter and cloud environments. In short, we can help you do an entire hardware and software audit of your datacenter – finding applications not just on bare metal, but on VMs and containers as well. If you want to extent the security, stability, and usability of your Docker platform, contact Device42 today!
