Containers are tired of being typecast

Thanksgiving and … turkey. Christmas and … trees. Containers and …. microservices.

If the first word you thought of for each of those matches my expectations, then you’ve fallen prey to over-association in the technology market today. There’s a tendency to immediately mention microservices along with containers in just about any discussion focused on one or the other. That’s partially because microservices, an architectural approach to decomposing applications into focused, agile services, fits well with the agile nature of container-based deployment models. But let’s not forget that containers are a technology in and of themselves. They existed long before microservices was an architectural twinkle in someone’s eye and they’re not constrained to being beneficial to microservices-based app deployments.

Consider this tidbit from Enterprise Development Trends 2016, a survey of 2100 JVM developers from which Lightbend (the self-described proud provider of the world’s leading Reactive application development platform) drew a number of cloud, container and microservices insights. Interestingly enough, while the majority (59%) are looking to containerize brand new applications, 41% are targeting “existing applications” for containerization.

This is not an anomaly at all. A quick jump over to an August 2016 survey by Mesosphere of 500 Mesos users found that 51% are running Monolithic and legacy applications on Mesos. 85% are running, perhaps as expected, microservices architectures.

Containers are clearly not just for new apps, but are being leveraged as a means to enable legacy and monolithic applications to enjoy many of the benefits of containers like portability, rapid scale, and a better fit with DevOps-driven operations. After all, we were promised frictionless portability but what we got was lengthy reimaging times as each public cloud provider standardized on a different imaging format. Maintaining multiple gold images (one per environment per minor branch per major branch per .. well, you get the idea) became an operational nightmare. Containers, like honey badger, don’t care. They’ll slide from OS to OS, from virtual machine to virtual machine, from cloud to cloud. They’re one of the best ways thus far proffered as enabling the nirvana of cost-based seamless cloud migration in the blink of an eye (that’s about 400ms for those of you keeping track).

Still, let’s not typecast containers as a “cloud” technology. While it certainly enables many of the long-touted but rarely realized portability between cloud providers, it’s not restricted to cloud or even cloud-like environments. Containers are certainly being used “in the cloud”, as noted by Sumo Logic’s recent report in which it found Docker use in production at 15% of the apps it examined. But that doesn’t mean containers aren’t being used elsewhere, like on-premise. In fact, the aforementioned Mesosphere report noted nearly half (45%) of its users are “on-premise only” with the majority split between “hybrid” and “cloud-only.” Interesting, it also found that “larger companies (those with 500 or more employees) were more likely to run on premise.”

See, containers are an interesting deployment option that, when supported by container orchestration solutions (like Docker, Docker swarm, Mesos and Marathon, Kubernetes, etc… ) provide a very agile environment in which to deploy and scale applications up and down automagically. It’s a micro-cloud, or at least cloud-like, environment that can be deployed in a public cloud, a private cloud, or without any “cloud” involved at all. Containers can be used to deploy and scale  monolithic apps, modern apps, microservices-based apps, and APIs. They are highly flexible because their focus is to normalize the operating system layer such that apps aren’t tightly coupled to the environment.

Containers are, to be concise, an abstraction layer that enables apps to be honey badgers and “not care” about lower-level specifics. When monitored and managed by container orchestration solutions, that abstraction enables automagic scale up and down, in and out, in ways that provide for greater resource efficiencies across the application infrastructure.

While containers and microservices and cloud may be BFFs, they are each individual entities that can stand tall on their own. Each offer benefits that are complementary and sometimes, dare I say it, synergistic with the others. But let’s not typecast containers into the very narrow mold of “only” for microservices and “only” for cloud.

Containers are tired of being typecast. Let them try on a variety of roles in your architectures and you might find they’re more than capable of playing a leading role in each of them.