Platform engineers make sense of external applications and infrastructure and synthesize that into an internal platform. There are significant upsides to optimizing horizontal software and hardware for a company-specific use case.
However, there is a tendency to create a system so customizable that it becomes a thin abstraction over the underlying platform. This is the inner-platform effect.
This may maybe most common with internal deployment platforms. There are so many choices to make. Container or function? What kinds of base images? How to configure environment variables? Ports? Secrets? What is an “application”? What is a “service”? (Applications, services, and workflows overload). Underlying platforms offer their own abstractions — PaaS systems like Heroku, Railway, Render, FaaS, or further down the stack like ECS, EKS/AKS/GKE. There’s no right answer here (that only exacerbates the tendency towards the inner-platform effect). But the most optimal choice is usually to start with the underlying platform’s abstraction and build towards that.
Another place it happens is ORMs. Another hyper-opinionated layer. It’s easy to make simple SQL queries confusing and slow through a few layers of bad indirection.
It’s difficult to keep your api surface small, but it’s essential as a platform team. So why does it happen?
- Ironically, a wide API surface is often a symptom of trying to lock down a layer too much without solving actual problems. Too much friction causes application teams to request more and more escape hatches.
- Sometimes, platform teams are tasked with building abstractions where they shouldn’t exist.
- Not all the requirements are known ahead of time. This leads to platforms slowly (or quickly) degrading into their lower layers.
- It’s easy to build a platform that negates the optimization of the underlying technology. Introducing latency, adding constraints, or generally redesigning horizontal infrastructure that has been battle-tested across many use cases.