There is quite a bit being said today about Docker containers and microservice architectures. When talking with users, we routinely spend quite a bit of time talking about the value of containerization and dispelling some preconceived myths. Based on these interactions, I thought a blog entry was warranted.

Debunking a few myths

Here are a few myths I’ve heard recently – Containers are a fad. Isn’t this just SOA repackaged/re-implemented? Containers are only good for new applications. Containers only work for SaaS based applications. X (you pick it) doesn’t work well in a container. Let’s take each one of these and address it.

Containers are a fad. Containers, or some form of process isolation, can be traced back to the 70’s and something called chroot. Our industry has been trying to crack this nut ever since. You can look at VM’s, application servers, and even Java’s JVM as alternate solutions. Docker, and Linux containers in general, are by far the best implementation we have to date. The fact that they are smaller than VMs, support any language, and run across the three primary operating systems, is a pretty good indicator that they will be around for some time.

Microservice architecture is just SOA repackaged. I see SOA as services built and made available across an organization and consumed by many different applications. Microservices, on the other hand, are a technique for breaking down your application into discrete components which operate independently forming a single application. One could build a service for SOA out of microservices, however, the reverse isn’t true.

Containers are only good for new applications. Containers are great for new applications. However, I might rephrase this to say containers aren’t an ideal fit for monolith applications, which don’t inherently have loosely coupled components (e.g. aren’t using message passing or REST interfaces). However, if your application does have loose coupling, introducing containers into your existing application is a great way to start your container journey. Alternatively, Image2Docker-Win is an opensource tool for capturing Windows applications into a Docker image. Image2Docker-linux is the equivalent tool for linux.

Containers only work for SaaS based applicationsSimilar to the myth above, containers are great for SaaS applications. With SaaS applications you can ultimately leverage all the benefits containers provide. However, on-premise applications can benefit as well, they just need additional tooling like Replicated or special packaging. I have seen an innovative approach of packaging a microservice Docker containerized app into a set of VMs for distribution. The end user then dealt with VM’s and didn’t know (or care) that it was Docker within the VMs.

X (you pick it) doesn’t work well in a container. This is really too broad to dispute. However, here are some rules of thumb to follow:

  • You don’t want your containers to be huge. In fact the smaller the better.
  • Each container should ideally perform a single service.
  • Your container should be built using trusted layers and only include what is necessary to run.
  • Pay attention to licensing – not all languages have container friendly licensing.
  • 12 Factor Patterns is quickly becoming the de facto set of patterns for containers.

In conclusion

As new technologies emerge, FUD (fear, uncertainty, and doubt) and myths will follow. Digging in to fully understand where it is coming from and how it impacts your applications is critical. Hopefully I’ve helped clear up a few container myths for you.

On a side note, the Open Container Initiative (OCI) just finalized version 1.0 of the specification for standardizing container runtimes. We won’t see immediate changes in the space. However, if you are using Docker containers you are most likely already generating OCI compliant containers.

Interested in learning more about Sign up for free to see how can help your team streamline their development process.