#26: Developer portals =/= developer platforms
Hey there,
This week, Humanitec CEO Kaspar Von Grünberg weighs in on the developer portal vs. developer platform debate. And while we have you here, be sure to register for PlatformCon 2022!
Let’s get bakin’
Developer portals =/= developer platforms
Kaspar von Grünberg, CEO at Humanitec
Contrary to popular belief, platform engineering is not about building a fancy UI. Many organizations conflate developer portals or service catalogs with Internal Developer Platforms (IDPs), when in fact they are very different things.?
According to Gartner, “internal developer portals serve as the interface through which developers can discover and access internal developer platform capabilities.” Take for example Netflix, who built a developer portal on top of its platform tooling.?
An IDP on the other hand, is the sum of all tech, tools and processes that a platform engineering team binds into a golden path for developers. Golden paths reduce cognitive load and drive standardization by design. So an IDP doesn’t need a developer portal to deliver value to developers.?
When I chatted with ~300 platform engineering teams last year, I learned that many start their platform engineering journey by building a developer portal. They do it because it feels obvious, the product is something you can show off to managers, and conversations around interfaces are relatively active.?
However, less than 20% of these teams were able to get developers to adopt and use the portal. Developers resent having “yet another interface” to learn and use. Additionally, many organizations overestimate the tangible benefits of having a portal and underestimate the amount of time and resources needed to keep the portal up-to-date.
In most cases, I’ve found that two changes yield the biggest results. Making sure you really have basic CI/CD flows set up reduces toil and increases efficiency. While restructuring your configuration management from “static” to Dynamic Configuration Management (DCM) enables standardization by design, separation of concerns, and continuous self-service with low cognitive load.
Another key consideration is that instead of building a UI developers didn’t ask for, organizations should treat their platform as a product. Taking this approach enables you to understand your developers needs based on user research, prioritize their concerns, and build a platform people actually want to use.?
TLDR: Platform teams that prioritize building a portal before the rest of the platform will likely waste valuable resources and see a low adoption rate.?
领英推荐
?? Want to make a great platform team? Don’t forget your soft skills.
?? Check out this ?? platform engineering guide, compiled by the clever folks over at InfoQ It features articles written by platform engineering community members Paula Kennedy, Nigel Kersten, Aaron Erickson, and yours truly. ??
?? Let Adrian Cockcroft introduce you to the four principles of platform engineering teams done right.
Last but not least, have you joined the Platform Engineering Slack channel? If not, you're missing out. Here are some job opportunities recently shared by the community:?
And that’s a wrap for this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it our way.
Stay crunchy ??
Luca