Introduction: The Era Of Platform

Hello, platform engineering. 

The world has changed.

The traditional DevOps approach is changing, giving way to platform engineering: an end user-focused approach to promoting developer autonomy, standardization, golden paths, and excellence in the engineering org.

Platform engineering is exploding in popularity. According to research from Puppet Labs, 51% of organizations have adopted platform engineering or plan to do so in the next year.

In the world of platform engineering, developers are the “customers.” And the goal is to empower them with tooling and resources to promote productivity and a culture of quality.

What’s behind the shift? 

The explosion and widespread adoption of microservices, APIs, and open source technologies in recent years has created greater opportunities than ever for innovation and collaboration. At the same time, devs are facing new challenges:

• The complexity of Kubernetes, which has imposed a staggering cognitive load to developers who aren’t K8 experts 
• The migration of developers from on-prem to SaaS development, requiring new toolkits and technologies
• Increasing fragmentation of the developer experience across a growing number of tools and frameworks

Many organizations realize that the benefits of developer autonomy and innovation need to be paired with guardrails and “golden paths”: the notion that there’s a single supported approach for a given enterprise to do things like build a backend service or create a data pipeline.

Enter the internal developer portal 

Enter the internal developer portal (“portal”): a new product category with the potential to improve developer autonomy and productivity, set clear and consistent quality standards, and promote visibility into engineering activities and outcomes throughout the organization.

But…what exactly is an internal developer portal? And how should companies think about the role it can play for them – and adapt it to their needs?  

Here’s how the practical guide is structured:

• We’ll start with some basic disambiguation of internal developer platforms and internal developer portals before describing the four pillars of an internal developer portal – and laying out key design considerations (Chapter 1). 
• We’ll then do a deep dive into those pillars with dedicated chapters on blueprints, software catalogs, developer self-service actions, scorecards, and automations (Chapters 2-6). 
• We’ll delve into the importance of reporting and executive views (Chapter 7) and extensibility (Chapter 8) before concluding with recommendations on adoption strategy (Chapter 9).

Throughout the guide, we’ll share examples to help flesh out basic building blocks with specifics. 

We believe that providing the best developer experience is a prerequisite to recruiting and retaining top engineering talent – and that delivering quality software depends on developer productivity. In this environment, internal developer portals are no longer a nice-to-have. They’re a basic necessity.

Let’s get going.