Nov 28
Platform Engineering, Part 2: WHAT Are The Goals of a Platform Engineering Team?
“DevOps is dead, long live Platform Engineering!”
“Platform Engineering is rapidly becoming the new DevOps or SRE”
These tweets created a lot of debate when they were published a few months ago. And the debate is still going on: Everyone is trying to articulate the difference between Platform Engineering, DevOps, and SRE.
Should we reduce Platform Engineering to infrastructure, DevOps, and SRE? (No we shouldn’t…)
Now we’ve read part 1: WHY — The evolution of developer cognitive load, let’s try to define WHAT Platform Engineering is, and list the goals of a Platform Engineering team.
The precursors: Uber and Netflix
In the spring of 2014, Uber split their Engineering team into Platform and Product teams (called “Program” teams, as described in The Platform and Program Split at Uber: A Milestone Special by Gergely Orosz) making them one of the first companies to put the Platform Engineering teams concept into practice.
In the mid-2010s, @NetflixOSS also started to share how they’d created an internal developer platform and supporting toolchain. At QCon 2017, they presented The Paved PaaS to Microservices at Netflix, on how to provide a “paved path”; a developer-focused, low friction, and ops-supported platform. They also introduced the concept of Full Lifecycle Developers in Full Cycle Developers at Netflix — Operate What You Build.
“We arrived at a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support.” — Netflix Technology Blog
All the ideas described in the above articles are what we call Platform Engineering nowadays.
There’s nothing new here. Every product and service runs on a Platform, corresponding to the company tech stack and infrastructure, mostly based on cloud providers and SaaS services (such as AWS, Github, or NewRelic), or internally-built tools. The Platform was usually previously owned by the Ops and/or the IT teams even if, with the DevOps culture, the boundaries of ownership were not always clear.
Platform Engineering Definition
There are many definitions of Platform Engineering, here are two simple ones:
“The purpose of a developer productivity platform is to allow teams who build end-user products to concentrate on their core mission.” — Martin Fowler
“Platforms are built to improve the developer experience, or DevEx, by reducing the cognitive load while maintaining an appropriate degree of freedom for developers.” — Aeris Stewart, Humanitec
Platform Engineering focuses on developer productivity by improving the developer experience.
At Agorapulse, most of our current Platform Engineering team members were in a team previously called the “DevEx” team 😜.
Team topologies: Product vs Platform Engineering
In modern product organizations, the teams who build end-user products are called empowered Product teams, as defined by Marty Cagan in his must-read book “Empowered”.
Another must-read book to inspire modern engineering organizations is Team Topologies by Manuel Pais and Matthew Skelton.
In this book, empowered Product teams are described as Stream-Aligned teams, and they are “empowered” by the support of Enabling teams and Platform teams!
At Agorapulse, after the move to empowered Product teams in 2019, this year we split our Engineering department into two categories:
- Cross-functional Product Engineering squads, organized by the business domain (aka the Stream-aligned teams / Empowered product teams)
- A single Platform Engineering team
In our current stage (we have around 70 people in Product & Engineering), the Platform Engineering team combines all the stream-aligned support functions described in Team Topologies:
- Enabling team: “grow capabilities of stream-aligned teams”, through transversal guilds
- Complicated-subsystem team: “reduce the cognitive load of stream-aligned teams”
- Platform team: “make stream-aligned teams autonomous”
Platform team’s mission and goals
The Platform Engineering team’s mission is completely linked to the Product Engineering team’s mission:
Product Engineering teams mission
Deliver business values to the end users with high velocity and high quality, by owning the full lifecycle development (BUILD, SHIP, and RUN).
Platform Engineering team mission
Create a best-in-class technical environment where the product squads are empowered and autonomous enough to fulfill their mission.
To fulfill its mission, our Platform team is composed of specialized senior/staff engineers, who are experts in their own field, that cover the different layers of our tech stack:
- Frontend: experts in the Angular ecosystem
- Backend: experts in the Java and Micronaut ecosystem
- Infrastructure: experts in CloudOps and AWS ecosystem (with Terraform for IaC)
Each expert is in charge of animating a tech guild, composed of product squad champions.
The high-profile platform experts provide a high level of abstraction to keep the cognitive load low for everyone else. They are also guardians of architectural reference and innovation, and owners of our tech-stack.
Platform Engineering team goals
The Platform team (aka the “Lego Masters” 😜) has four main goals:
- Provide an internal developer platform (IDP) that abstracts away the unnecessary complexity of our tech stack to increase developer experience (See part 3 for more details).
- Give expert support to unlock technical issues encountered by the product squads.
- Increase and share knowledge and best practices through transversal guilds weekly meetings / workshops / documentation.
- Create external visibility (Twitter, Blogs, Talks) to attract new talent.
Platform Engineering principles
Platform as product
The platform should be managed like a product, with proper customer discovery to understand internal customer’s needs (aka the developers), roadmaps, a planned release cadence, and proper internal documentation.
Self-service and support, for autonomy
Since Product teams must be able to fulfill their mission autonomously, the internal developer platform should be fully available as self-service: Push-button dev portals, internal CLI, or well-documented versioned libraries / APIs.
Golden paths and automation, for productivity
During their internal customer discovery, the platform team should identify manual, repetitive, automatable, and tactical works, or tasks, to eliminate them and standardize best practices across the company. Finding these “golden paths” increases developer productivity while reducing cognitive load, double win!
“The idea behind having golden paths is not to limit or stifle engineers, or set standards for the sake of it. With golden paths in place, teams don’t have to reinvent the wheel, have fewer decisions to make, and can use their productivity and creativity for higher objectives. They can get back to moving fast” — Gary Niem, Spotify R&D
Platform != Infrastructure
As we saw with the controversial “DevOps is dead” tweets in the introduction of part 2, many Platform Engineering articles are infrastructure-centric and tend to reduce the role of a Platform team to DevOps/Ops/SRE, Kubernetes management, and developer control planes.
To reduce the cognitive load of developers, the Platform team should cover the entire tech stack: Infrastructure/DevOps/SRE, but also frontend, backend, and security topics.
At Agorapulse:
- Frontend experts provide cross-cutting concerns relating to reusable libraries (including the Design System) used by the product squads. They’re also in charge of frontend-related SaaS Services (NpmJS, BrowserStack, etc).
- Backend experts provide core shared technical services (such as authentication or notification systems) and cross-cutting concerns relating to reusable libraries used by the product squad. They’re also in charge of backend-related SaaS Services (Gradle, Artifactory, Contrast, etc).
- Infrastructure experts provide Terraform modules for each AWS service to standardize our IaC and abstract AWS usage complexity, as well as custom Github actions and reusable workflows to ease CI/CD pipeline usage. They’re also in charge of infrastructure-related SaaS Services (AWS, NewRelic, Lacework, etc).
Our Platform Engineering Team also provides a self-service security and observability/monitoring platform that’s connected to incident management. Developers can start triaging and debugging themselves when they run into issues.
So no, “DevOps is not dead” 😜In fact, it’s more alive than ever with the true “you build it, you run it” mantra.
DevOps is not a role, it’s a culture and the enablement of this culture in all Product teams is the responsibility of the Platform team.
Moving towards a Product and Platform Engineering split looks like the next logical evolution for modern engineering organizations.
The question is, when should a startup create a Platform team? And when they do, should they build everything from scratch or buy off-the-shelf solutions?
Let’s explore WHEN & HOW to build an internal developer platform, with the “Buy vs Build” eternal dilemma in part 3!
