The Case for a Shared Middle Tier
AWS has done something remarkable: it has made server infrastructure a commodity. Most organizations using it will never rack a server, swap a failing disk, or troubleshoot a faulty router. That alone has saved an entire technical discipline from needing to exist inside most companies.
But AWS stops at infrastructure. The APIs, SDKs, and web console are powerful and feature-rich, yet they don't account for the workflows engineers actually follow day to day. The layer is so low level that every company using it ends up building custom tooling to fill the gap—for fleet visibility, deployments, configuration management, and other routine tasks. Some of this is built on foundational tools like Puppet and the AWS SDKs, but the glue is still very much bespoke.
This phenomenon has a name: the Galápagos syndrome, originally used to describe the isolated evolutionary branch of Japan's mobile phone industry. Each organization's internal tooling is its own evolutionary offshoot—and, like Japan's feature phones before the smartphone wave, likely a dead end.
Why Internal Tooling Is So Often Bad
The problem with internally built tooling is that it invariably sucks. It tends to appear in the fast-moving early days of a company, never receiving the same scrutiny as open-source software. It is often self-inconsistent, undocumented, logically unsound, slow, and devoid of tests. That doesn't mean it isn't useful—especially compared to the purely utilitarian base layer AWS provides—but it represents a substantial cost in development and maintenance for software that is mediocre at best.
What a Shared Middle Layer Would Need
Resource-conscious organizations should pool these discrete expenditures toward building a rich middle tier everyone can use. For that layer to work, it would need to meet three criteria:
- Flexible enough to accommodate organizations across a wide spectrum of sizes and use cases.
- Simple enough that smaller shops with limited resources can deploy a few basic apps quickly—ideally as easy as
git push heroku master. - General enough not to lock into AWS-specific features, so it can run across multiple cloud providers.
The upside is significant: a substantially better operator experience, the elimination of vast swaths of internal-only bugs, and a major streamlining of operations by cutting out unnecessary software development and maintenance. The downside is having to learn someone else's system—but that's no worse than the learning curve AWS itself already imposes.
Kubernetes, with its strong engineering team and Google's backing in both finances and visibility, is the most promising candidate so far. But it's still too early to tell whether it will be a clear winner.
