Platform teams are everywhere, it seems – so undoubtedly not dead, but are they a good idea for most companies?
Twitter thread based on demand and cause I can't be bothered to spend 6 months writing a blog post: platform teams are dead.
Platform teams as in teams that build an internal platform that "abstracts the cloud" and "makes things easier for developers" and "our k8s platform" ⚰️
— Vlad Ionescu (he/him) (@iamvlaaaaaaad) June 8, 2022
TLDR; of the thread (paraphrasing mine).
- "Cloud providers are successful in building high-order abstractions other than pure IaaS."
- "Companies build Platform teams for organizational reasons: Easy to propose, easy to sell, easy to recruit for, and easy to integrate into a wider tech strategy without raising eyebrows."
- "Most abstractions hide necessary implementations from developers."
- "Platform development is undifferentiated work."
- "Internal platforms can't keep up with the velocity of hyperscalers (or open-source)."
- "Platform teams introduce unnecessary friction between developers and underlying cloud providers – making it difficult to take advantage of new features or services and adding bureaucracy."
I've used internal platforms and built them for others. I think some of these points make a lot of sense.
I don't believe that hyperscalers will only be IaaS providers (AWS is Not a Dumb Pipe). However, hyperscalers have already been successful at building higher-order services.
AWS missed the $90B Snowflake opportunity but won many others. Kinesis vs. Kafka, DocumentDB vs. MongoDB, MemoryDB vs. Redis, OpenSearch vs. ElasticSearch. And it's not just fast-follow, but essential new services like AWS Lambda have changed the way we develop software. Google App Engine was a decade before its time.
Internal platforms can't compete long term with cloud or open-source. The diseconomies of platform scale at Google are just this: see MapReduce/Hadoop or Heroku/AWS.
The previous year, Google had released a paper on its proprietary Google File System, which worked hand-in-hand with MapReduce. No other company was operating at Google scale.
But the industry always catches up, eventually. In 2006, two engineers would use those papers as a blueprint to create an open-source version of both technologies, Apache Hadoop and HDFS. They quickly became the industry standard - spawning huge companies like Cloudera, Hortonworks, and Databricks.
I've seen many teams try to fail to abstract Kubernetes away from developers. They start with removing all unnecessary dials and knobs. Then, slowly, platform teams add each feature back, and abstractions are broken – not without bureaucracy and friction. So I wrote in Kubernetes Maximalism:
Today, platform teams try and abstract Kubernetes away from developers, but I predict that Kubernetes will become the developer platform in the future. I call this Kubernetes Maximalism.
Can a Heroku-like company be successful in the cloud environment? Many companies build internal platforms like this but rarely buy them. Why? How big of a market is PaaS today? Why did Heroku Fail?
As someone who worked on Kubernetes for many years, a PaaS was always the elusive next step. So many imagined someone would build a successful PaaS with the primitives provided by Kubernetes (and many tried – Knative, Kubeflow, OpenShift, etc.).
If platform teams are no longer the right team to build out, what replaces them? While the maturation of the cloud solved many problems that platform teams were working towards, there are still some unsolved questions.
- What happens when there are generic gaps in hyperscaler offerings (e.g., CI/CD)?
- How do you build guardrails into cloud platforms that make them usable by different kinds of developers (ranging from DevOps to frontend)?
I predict platform teams will move up the stack and become more niche. There will be FinOps platforms, MarOps platforms, and DataOps platforms that are built out for non-developer teams. These abstractions won't be generic but specific to job requirements and often industry. The platform teams there will be differentiated and be able to compete with outside solutions that aren't moving as fast.