Don’t Get Too Caught Up With Containers and Microservices
Most people get it now: the cloud — and more the public cloud than the private cloud — is something we should be using. This is true when it comes to much software that we use regularly (e.g., Google Apps, Office 365), and it is also true when it comes to software that we run for others. But far too many users and commentators view the cloud as the end, the ultimate destination for the software we are writing. There is almost no commentary about the next significant strategic improvement in building and deploying software; instead, we have endless focus on how we can make tactical improvements to building on the cloud, like containers and microservices. People writing and thinking about technology spend too much time thinking about pure technological innovation, and almost no time on the strategic benefit that the technology delivers. In this column, I will outline my framework for understanding what will happen next.
The real benefit of the cloud is business agility. Specifically, the cloud helps take software as a service (SaaS) to market faster, and decreases the amount of time it takes to release updates. In the beginning, SaaS required a data center, which was a massive capital investment, and required tons of support staff. Then arose colocation and managed hosting, which decreased both the capital investment and the number of employees necessary. But in all cases, before the cloud, it required a human being to allocate machines for development, testing, QA and production. Public infrastructure as a service (IaaS) changed the requirement from a human to a credit card, which the business gladly handed over.
The business agility benefits of the cloud were discovered by engineers who were aligned with the business goals — IT was making them slow, and they were looking for a way to go faster. But it’s not clear to me that the alignment between engineers and the business is quite as close for the next big improvement in business agility.
Here’s why: technology people just want more technology. They wallow in technology. It’s not about ease of technology. They are just making more technology: containers, container management, monitoring, etc. It’s a pain in the ass to maintain any cloud, even a public one. The state-of-the-art, best-practices way of administering a cloud are seemingly never-ending; we got rid of the rote SysAdmins and network engineers, but now we need really-hard-to-find DevOps engineers. This isn’t the business agility we were really hoping for.
If you believe me — that what matters is optimizing business agility — then it’s fairly simple to see what the end state is: product managers being able to build software directly from a product vision. While it’s extremely difficult to see this happening without any designers or developers, it’s a useful construct to understand what we should be optimizing. And what we should be optimizing is the ability of an organization to release new products, and updates to products, as quickly and with as little execution risk as possible. This is a focus that is not so much secondary as it is completely absent in the many articles trumpeting new technologies that I read today.
The current best-practices public cloud is not an end state; it’s just another step along the way. It’s just too messy and ugly to be somewhere we sit for a long while. The discussions happening in the traditional tech quarters (containers, microservices, monitoring) are more reflective of changes that will pass and transform over time.
I look, instead, to technologies that have enabled substantial business agility with those businesses doing as little as possible to put their product requirements into action. I view Snapchat’s building on Google App Engine and Yo’s building on Parse, and the fact that you can generally build massively-scalable social network apps in hours and then do very little work to maintain the backends. This is not to say that the technology here is perfect (but think of public IaaS in 2009!), but it’s delivering the next level of business agility.
Too many technology start-ups come out of “engineers from [web-scale companies] building a version of the internal tool for external use.” Don’t get me wrong — we’ve gotten a lot of great tools this way — but we’re much more likely to see evolutionary changes through products that still assume large engineering staffs, instead of seeing revolutionary changes that empower the business to be more agile.
