The missing cloud layer
We went from complex to simple to complex again. Before AWS there were lots of pieces of hardware, so lots of “glue” that was hard to manage. Then cloud introduced an abstraction layer. There were few services (EC2, S3, RDS), little “glue” in-between, easy to manage. But then more and more specialised managed services evolved, AWS has over 200 now. So there are lots of moving pieces again, lots of glue, and it’s hard to manage. This is no secret for a while, but the “cloud makes it simple” opinion still has a lot of momentum.
With AWS, anything is possible, but all problems are hard to solve. With Heroku and other PaaS, common problems are easy to solve; but only as long as ALL your problems are common. Rare problems are impossible to solve, so if you have at least one not-so-common problem then you have to use something like AWS for those and the overall setup becomes even more complex than with pure AWS. So “Heroku in your AWS account” is not the answer. More thoughts on this here.
Infrastructure-as-code is not the answer either. It merely makes the complexity problem soluble. Present-day infra-as-code is more like assembly language, in a sense that it can’t be reused without the user being fully aware of the implementation details. A higher-level abstraction is needed to make infrastructure patterns reusable. It needs to cleanly separate interface, implementation and configuration to achieve that.
What’s different about now compared to 5 years ago is that two key technologies reached mainstream adoption: infrastructure-as-code (Terraform) and containers (OCI / Docker) as the de-facto standard for shipping code. Managed services have established equivalents in all major cloud providers. This makes it finally possible to create an orchestration layer for the mass market. CloudFoundry was just too early.
Major cloud providers (AWS, GCP, Azure) are both horizontal and vertical (broad range of services, both high-level and low-level). This is an anomaly, such state of the market can’t be sustained for long. But they are unlikely to agree to narrow scope. That creates vacant horizontal space atop.
Another temporary anomaly is the DevOps job. Let’s skip the debate about the “right" way to understand DevOps culture. As a matter of fact, a separate job title for it exists. And out of all software engineering specialties it is the only one that is a hard dependency for others, in a sense that for others to be productive the DevOps need to do their job first. This creates inefficiencies that slow teams down. This is why large tech teams spend millions to build in-house abstraction layers on top of their cloud providers—they have to decouple their Platform team from others to keep shipping. An infrastructure orchestration layer will not replace DevOps engineers, but it will multiply their productivity and decouple them from other developers.
A loud harbinger of what’s inevitably coming is the counter-intuitive success of “one-off consulting” in the DevOps space (think Gruntwork, Scalefactory, etc). To these companies it makes more sense to charge a fixed fee for a standardised quick piece of work than to bill hours. This is also an anomaly. What is it if not a “proto-product”? The only thing left to make it scalable is to build the missing tooling.
