Platform Engineering, Part 3: WHEN & HOW to Build an Internal Developer Platform
Creating a platform team and an internal developer platform is a natural evolution for a modern engineering organization. The hype is real! But as Martin Fowler says: “mind the platform execution gap”!
Building an internal developer platform is easier said than done (after all, most of us are not Uber or Netflix), and it raises a lot of questions about the timing, what services to provide, and facing the “build vs buy” dilemma to create it.
We’ve covered part 1: WHY — The evolution of developer cognitive load and part 2: WHAT are the goals of a Platform team?
Now, let’s try to define WHEN you need a platform team and HOW to build an IDP (Internal Developer Platform).
WHEN does an organization need a platform team?
“It depends” could be the classical answer: it should not be too early or too late. But in practice, finding good timing really depends on two factors: Team size and Organizational maturity
Team size
As a startup grows and reaches its flat structure limit, the single Product+Design+Engineering team is split into multiple teams, with formal lines of communication, processes, and hierarchy (aka middle management).
To keep the team size optimal for efficiency, the split usually occurs when the initial single team is around 10 to 15 people (aka the 2-pizza team).
With multiple teams, cross-cutting concerns and communication silos start to appear. A way to mitigate these is to create transversal teams: A Platform team and/or transversal “guilds” promote knowledge sharing and collaboration in specific domains.
Organizational maturity
The initial internal developer platform is usually outsourced: many engineering teams start with a PaaS offering (such as Heroku, Netlify, or the equivalent) to get their engineering team up and running quickly and to benefit from speed execution and proven scalability, at the price of a highly opinionated approach.
With the service growing and the split into multiple Product teams, the developer environment is likely to get more and more complex to run and to deploy, and the product engineering teams might start:
1. Reaching their knowledge limit in their field (infra, pipeline, etc)
2. Facing PaaS/FaaS lack of flexibility to truly scale out
3. Creating generic dev tooling to automate tasks that would benefit the other teams
The best example is when you include Kubernetes or Infrastructure as Code in your tech stack, or when you start building your own Design System, shared across all the engineering teams. This leads to the developer cognitive load and developer comfort zone issues, described in part 1.
At Agorapulse, in 2019, we started a Developer Experience team when we had around 20 people in Product & Engineering and 3 Feature teams. This DevEx team had experts in backend, frontend, security, and infrastructure, and were able to animate their corresponding domain guild.
In 2022, we renamed this DevEx team to the Platform team, to better encompass all their responsibilities (which is more than just DevEx and enablement, see part 2). In the end, we might have renamed it earlier, with the move to Infrastructure as Code.
WHAT to provide in your IDP?
The goal is not to provide another opinionated “Platform as a Service”. “Platform as a Product” is one of the key principles in Platform Engineering: Developers are the internal customers of the Platform team. Like with any product, platform building should start with an initial customer discovery phase to surface the major pain points that are slowing down product delivery.
At Agorapulse, we run an internal developer survey twice a year to measure the evolution of our DevEx eNPS. We also gather feedback during weekly guild meetings and the Head of Platform does regular check-ins with the Engineering Managers every two weeks. We then build quarterly action plans, based on the feedback, and build and improve our internal developer platform.
So the Product teams can achieve full autonomy, the Platform team must provide a technical environment that covers the operational necessities of the entire lifecycle. It’s the sum of all the tech, tools, and processes that developers use to BUILD, SHIP, and RUN software:
- BUILD (discover & create): Frontend and Backend and Infrastructure: Languages, framework, testing, architecture, cloud services, etc
- SHIP (integrate & deploy): CI/CD delivery pipelines, feature flagging, versioning, etc
- RUN (operate & improve): Observability, monitoring, debugging, scaling, support, etc
During each BUILD, SHIP, and RUN phase, the biggest challenge is to find the right level of abstraction: Encapsulate the complexity and best practices into golden paths while giving enough flexibility to the end users.
The Platform team should not become a bottleneck, hence the importance of the developer platform stability and self-serve philosophy: Developers should be self-sufficient and accountable (“feed someone a fish, they eat for a day; teach someone to fish, they eat for a lifetime”).
For an enterprise-level IDP example covering all the phases, check the capabilities of the Adobe IDP, presented at ArgoCon 2022:
HOW to build an IDP?
To shield complexity away from developers, there are either code based CLI-approaches, inspired by GitOps workflows, or more UI-based solutions, with unified dev portals and control planes.
At Agorapulse, the customer dev tooling started with a simple CLI (called `pulse`). It encapsulated and automated most common workflows, or “golden paths”, such as how to start to work on a story/ticket, creating a PR, or checking team microservices deployment statuses.
This year, we’ve started to experiment with a unified developer portal, powered by Backstage.
TSBE Syndrome
The danger with IDP is that a lot of engineers love reinventing the wheel and desperately want to tinker with the latest technology, especially because most of us suffer from TSBE syndrome (aka “This Should Be Easy”).
Let’s be honest. We are all, or at least have been, this type of over-optimistic person 😬.
As a result, some engineering teams (especially those with open source enthusiasts) in smaller organizations, might fall into the trap of building their own custom internal developer platform too early.
Young startups have to focus 100% of their engineering resources on validating their product market fit and finding the best go-to-market strategy. The creation of a Platform team and the “Buy” vs “Build” dilemma should come later, as the dev team grows and the tech stack complexity increases.
“In small organizations, do not reinvent the wheel. Buy instead of build and rely on best-in-class SaaS providers to concentrate on your core business”
Thinnest Viable Platform
Even after the creation of the Platform team, the custom-built platform should remain as thin as possible: a Thinnest Viable Platform (TVP).
This topic was very well detailed in the PlatformCon 2022 Keynote by Gregor Hophe: The Magic of Platforms, where he described the concept of Floating Platform vs Sinking Platform. As the base platform gains the capabilities you built, you can ditch the redundant functionality and devote your resources to iterating beyond what the base platform can offer.
At Agorapulse, we had a “NoOps” approach and a “Buy” mindset from the beginning, with no dedicated infrastructure/ops team until 2021.
We have a floating platform built on top of an AWS base platform (that we have used since 2008). We definitely try to keep our custom platform as thin as possible by relying on AWS PaaS/FaaS services (e.g: Elastic Beanstalk/ECS/Lambda, SQS/SNS, RDS/DynamoDB, etc) and third-party Saas services, as much as we can.
Conclusion: Is Platform Engineering Worth The Hype?
Thanks for reading! The goal of this three-part series was to share our vision of Platform Engineering and show the current state of this exciting topic at Agorapulse, a Product-led SaaS scale-up.
In a product-led and cloud-native world, it makes a lot of sense to split the Engineering department into two simple categories:
- Multiple business-driven Product Engineering teams
- Supported by a tech-driven Platform Engineering team
Modern Product & Engineering organizations are composed of autonomous and empowered product teams, with a true “you build, you run it” mantra. Platform Engineering makes this empowerment possible and lets them focus on their mission: delivering business value to customers.
If you liked this article, please hit the ❤ button to recommend it. This will make it easier for other Medium users to discover this.
