The rise of containers (notably, Docker and Rocket) and microservices is creating widespread excitement in the DevOps world about simple, lightweight solutions for enterprise applications. But amidst all the thrill, let’s not forget that it’s early days yet—not just for the technologies, but also for the processes and practices around microservices and containers. Pretty much everything in this space is either still waiting to be invented or needs a lot of fine-tuning.
As a developer, I totally appreciate the desire to have “simple” and “lightweight” solutions for everything. I get that “ugh” feeling when working with clunky, slow, antiquated tools and processes, just as everyone else does. But working day in, day out with teams introducing enterprise tools for continuous delivery and DevOps, I’ve come to accept that some of the “weight” of enterprise tools is essential.
I think it is fair to say that trying to build your own runtime environments by stringing together a combination of brand-new technologies is just not a good idea. You would need to have people in your organization who understand the complexities of building and maintaining these systems, a lot of cycles on your hands, and the time to work through numerous painful interactions until the technologies mature. For example, if you’re going for Docker, you’ll need to figure out how to handle the related security challenges, and that won’t be easy—even the very smart team at Docker has yet to get it right.
To be clear, this is not about bashing containers. I simply want to put their importance into context. Over the years, I have learned this painful truth about developing applications: Those “enterprise requirements”—the ones that cause much of that heavyweight feeling, and the ones we all want to banish—they’re real. They’re not going away.
Delivering a business service at a certain scale (not just running the underlying tech, which is hard enough in itself) comes with intrinsic complexity that doesn’t simply evaporate if only you use the right tools—much as we would like to believe that.
A colleague who is a highly experienced architect and consultant put it this way: “I understand the path that Docker is taking. Just having a Docker container is almost as exciting as having a Java EAR file. The major difference is that most operations departments know what to do with an EAR file, sort of. To run Docker-based applications 24/7 in production requires not just new tools; it also requires new skills.”
Sure, if you’re experimenting in a lab environment, or if you’re a startup with a handful of people and a couple of virtual machines in the cloud, the “simple,” “lightweight,” and “latest and greatest” tech will work for you. But once you try to move out of the lab and into production, or once your startup grows from five to fifty and then five hundred people, all those boring enterprise problems—scalability, auditing, reporting, managing multiple versions across many release pipelines, ease of use, and so on—will be right there, just when you have absolutely no time to come to grips with them.
Of course, there’s always the option of staying in the lab and throwing your app over the wall, or of leaving for a new startup once you hit fifty or five hundred people—but that’s just shifting the problem to someone else. Let’s call a spade a spade: The “simple, lightweight enterprise platform” for delivering and running applications at a certain scale doesn’t exist.
Don’t get me wrong; I’m tremendously excited by the potential of microservices as an application paradigm and containers as an implementation technology for them. I firmly believe we need new ideas and, yes, new tooling to make proper use of the potential of microservices and containers, and to address the new challenges, such as runtime dependency management, that they introduce.
In the meantime, we should avoid and eliminate unnecessary complexity and weight wherever possible. We should also not rush madly to incorporate into our operations a bunch of “we-called-it-1.0-because-0.2-sounds-scary” tooling, however. Let’s stop pretending that we can grow our projects and companies to any kind of meaningful size with a bag of tools that are “simple” and “lightweight”—often because they lack essential features down the road.
Instead, let’s try to ensure that security, scalability, reporting, and usability are in place before we’re scrambling to hook up hundreds of new servers a day or getting hammered with audit requirements and need to divert precious time to get our shiny, simple, lightweight tooling to cope.
Innovation is great, and containers and microservices are wonderful tools for experimentation in the lab. But don’t get carried away by these new technologies and the marketing hype. Enterprise features may be dull and overweight, but for your next round of DevOps, continuous delivery, microservices, and container tooling, look for those features from day one. You will need them.
