How Internal Developer Platforms improve the Developer Experience (DevEx)

Most engineering organizations would agree that improving developer experience (DevEx) is something they are striving for. Great DevEx is not only important to make developers happier and decrease employee turnover, but it is a key factor driving developer productivity and engineering velocity.

However, DevEx is a very broad term and can mean a whole lot of different things. It can refer to developer wellbeing and a healthy company culture, to the quality of documentation and processes, to the number of tools you need to handle to do certain tasks, etc. It might also imply a culture that encourages developers to take risk and innovate, while providing them with the time and space to do so, without being burdened by repetitive tasks or other distractions.

DevEx: “Make the right thing to do the intuitive thing to do”

Given there are so many definitions of developer experience, there are at least as many ways to improve it. A crucial thing about DevEx that is often misunderstood is that you can’t enforce a good one. It is not something you can simply plan for and implement across your engineering organization. You need to design workflows and foster a culture that feels intuitively right to developers, giving them tools and providing golden paths and paved roads, not golden cages.

The Gartner® report on “Software Engineering Leader’s Guide to Improving Developer Experience” defines the importance of developer self-service as following:

“Developer self-service has an inherent benefit to bringing consistency and repeatability to otherwise disparate processes and error-prone manual handoffs. The goal of self-service is to ensure developers have an experience that makes ‘the right thing to do, the intuitive thing to do.’ For example, the ability to self-serve prevetted open-source libraries from a trusted component catalog improves governance, as well as developer experience.”

Over the last few years, it has become increasingly (and painfully) clear that cognitive overload on developers is one of the root evils creating a poor developer experience. The explosion of cloud native tooling and infrastructure, combined with the shift left and “you build it, you run it” trend, are overwhelming engineers and decreasing both their productivity and overall quality of experience.

The answer of many engineering organizations to these issues has been to build guardrails on top of their new cloud native setups. Internal tooling in the shape of platforms that could help developers navigate this increasingly complex toolchain. This is a trend that has been trickling down from top performing orgs like Google, Airbnb, Spotify, etc. into the rest of the industry, called platform engineering.

Platform engineering on the Gartner® Hype Cycle™

Platform engineering appears on the well regarded Gartner® Hype Cycle™ for Emerging Technologies, published on 25 of July 2022 as well as on the Gartner® Hype Cycle™ for Software Engineering, published on 1 of August 2022.

According to Bill Blosen (Sr Director Analyst) and Paul Delory (VP Analyst), “Platform engineering is the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.” And further on: 

“Platform engineering also improves the developer experience, thus reducing employee frustration and attrition.”

To us, while it’s great to see such an established industry thought leader like Gartner acknowledging the impact this emerging discipline is having on the DevOps and cloud native world, there is still some confusion on what an Internal Developer Platform, or IDP, actually is.

Developer portals: interfaces to discover platform capabilities

Many organizations claim to have built such an IDP, when in reality they just patched together a bunch of open source and vendor tooling into a static delivery setup that doesn’t follow platform principles like standardization by design or DevEx best practices. Other teams simply adopted fancy developer portals and called it the day, disregarding the underlying issues in their application configurations and infrastructure orchestration. Lee Ditiangkin, who built the platforms at Apple and IBM, (very) clearly explains why putting a pane of glass on a pile of sh*t doensn’t solve your problem.

In our opinion, the latest Gartner report “A Software Engineering Leader’s Guide to Improving Developer Experience”, again brings some light into the darkness here and helps solve some of these issues.

There are three key pillars worth to mention:

1. “Improve developer experience by building internal developer platforms to reduce cognitive load, developer toil and repetitive manual work.”
2. “Platforms don’t enforce a specific toolset or approach – it is about making it easy for developers to build and deliver software while not abstracting away useful and differentiated capabilities of the underlying core services”
3. “Platform engineering teams treat platforms as a product (used by developers) and design the platform to be consumed in a self-service manner.”

Furthermore, the Gartner report distinguishes between two core categories and explains how they interact with one another:

“Internal developer portals serve as the interface through which developers can discover and access internal developer platform capabilities.”

While Internal Developer Platforms remove toil and repetitive work, dedicated developer portals provide a UI with service catalog capabilities that developers can use to access the underlying IDP. This is a subtle but extremely important differentiation. Simply building a developer portal will not solve the underlying configuration and workflow issues that are negatively impacting your developer experience. The combination of IDP and portal is what you really want to strive for.

It’s also important to note the difference between out-of-the-box solutions like PaaS offerings, end-to-end DevOps or CI/CD platforms and Internal Developer Platforms. IDPs don’t restrict engineering organizations in terms of the technologies, tooling, methodology (e.g. GitOps vs ClickOps) or interfaces (CLI vs UI vs API) they want to use. IDPs are built by platform teams following a Platform as a Product approach and don’t come with a set of opinionated choices and workflows. They are built iteratively by the platform team, based on the feedback loop with their developers.

If you want to dive deeper into the relationship between IDPs and developer portals, we can recommend some talks of leading practitioners who spoke at this year's PlatformCon in June. Taras Mankovski, CEO at Frontside and core contributor of the Backstage ecosystem, presented how to use Backstage as the developer portal on top of a dynamic IDP, built with Humanitec Platform Orchestrator. Brian Leathem showed how Netflix uses Backstage as a UI layer on top of platform tooling like GraphQL API.

‍

Sources 

“A Software Engineering Leader’s Guide to Improving Developer Experience” by Manjunath Bhat, Research VP, Software Engineering Practice at Gartner.

Hype Cycle for Emerging Technologies, 2022, published 25 July 2022

Hype Cycle for Software Engineering, 2022, published 1 August 2022

Disclaimer

GARTNER and HYPE CYCLE are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.