For platform engineering teams, the big question is: build or buy?
Helping developers do more in less time has become a priority for organizations. As the ambit of SaaS sprawls ever wider and DevOps grows more popular, companies are discovering that they need to alleviate the cognitive load on developers, who often have to be aware of all the microservices available to them.
While this problem was initially addressed with service catalogs, the category has morphed into something more ambitious: a one-stop-shop that lets devs access all the microservices and tools in their ecosystem.
Called internal developer portals, this category is quickly gaining traction at software-heavy companies as they seek to improve their developer experience, and thus, efficiency. According to Forrester, 87% of DevOps leaders agreed that increasing developer productivity is a priority for the next 12 months.
Per Gartner, “these portals enable software engineering leaders to create a versatile ‘app store’ that increases software reuse, improves the developer onboarding experience, streamlines software delivery and facilitates knowledge sharing.”
But these developer portals didn’t come by on their own. Their emergence is closely tied to another trend: The advent of platform engineering.
In a nutshell, platform engineering teams are “groups within typically larger organizations that are given the role of improving the developer experience for other developers in the organization,” Shomik Ghosh, partner at Boldstart Ventures, told Pointypress+.
Platform engineering teams have become increasingly common in large organizations, as have internal developer portals. Gartner expects that by 2026, 80% of software engineering organizations will have a platform team, and by 2025, 75% of organizations with platform teams will provide self-service developer portals to their engineers.
To better understand why and how internal developer portals came about, let’s go back in time a little.
Going beyond catalogs
Internal developer portals are a key tool for platform engineering teams, but they actually emerged before both concepts had been fully conceived. In fact, they came about in the wake of DevOps: Engineers suddenly found themselves increasingly tasked with deploying and operating the code they write. But in reality — and in production — it was often unclear who owned a given microservice.
