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 submit your PlatformCon 2023 talk before it’s too late!
Let’s get bakin’
Developer portals =/= developer platforms
Kaspar von Grünberg, CEO @ 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 have basic CI/CD flows set up reduces toil and increases efficiency. 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.
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.
Short on time? ⏳ We got you 🥐😋
🥐 Share your platform stories and insights with the community at PlatformCon 2023! The call for proposals closes on February 28th.
🥐 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 communitymembers 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:
- Alternatives to make my IaC scans faster
- We're planning to build Terraform IaC self service platform, and need help from people who have implemented a similar solution
- Looking for an IDP solution (OSS preferred) that can be self-hosted
- Do you all have test backgrounded people on your platform/DevOps/SRE teams?
And that’s a wrap on 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
load.png)