5 Bad Reasons to Use Containers
Containers, Docker and Kubernetes are all great things. But they’re not the right fit for all situations. Here are five bad reasons for migrating workloads to containers.
For the purposes of this discussion, I assume you’re currently deploying an application or a service on bare-metal or in a virtual machine, and are considering switching to Docker containers as your deployment tool of choice.
Following are five reasons why you might not want to do this.
You Want to Use Microservices
Containers are an excellent tool for deploying microservices-based applications.
However, moving your app from a traditional environment to Docker doesn’t magically transform the app into microservices. You would have to refactor or rewrite the app to do that.
If your app is already designed to run as microservices, then by all means, switch to Docker. But don’t attempt to use Docker as the beginning of your microservices journey.
You Think It’s More Secure
You could spend days debating whether Docker containers are more secure or less secure than alternative deployment environments.
The reason you can spend so long debating this issue is that the answer will always be, “It’s complicated, and it depends.”
Containers are more secure than virtual machines or bare-metal servers in some respects. For example, if your app uses a microservices architecture and each microservice runs in a separate container, your chances of having the whole app compromised because of a security vulnerability in one microservice is smaller than it would be with a monolithic app running on a virtual machine.
On the other hand, Docker doesn’t provide the strict isolation between applications that you get from virtual machines.
The bottom line: You should not switch to containers because you think containers will make your app more secure. You should instead take steps to secure your app after you have decided to migrate it to containers.
You Want Bare-Metal Speed
Docker containers run faster than virtual machines because they have less overhead.
Less is the operative word here, however. Containers still have some overhead.
If you want bare-metal speed, you need to run your app on actual bare metal.
Containers are Free
The core technologies that you need to run containers—a runtime, a registry, an orchestrator and so on—are mostly free of cost.
However, this doesn’t mean that containers automatically deliver a lower total cost of ownership than alternative technologies.
They may if you are comparing them to VMware, which costs money to use in production scenarios. But containers aren’t the only cost-free alternative to VMware. There is also KVM, for example.
Plus, with containers, you may end up needing to use a containers-as-a-service (CaaS) platform to make your container deployment easier to manage. Most of those cost money.
Because You Can
Switching to containers just because you can—or because everyone else around you is already running Docker or Kubernetes—is not a good reason on its own to make the jump.
If you can gain real performance, cost, security or other benefits from containers, then by all means, make the switch.
But you don’t want to migrate to Docker or Kubernetes just because you can. Bare metal and virtual machines aren’t going anywhere. If your workloads run just as well on those platforms, why move?
