Overview
Modern development can be fraught with disparate development systems and distributed teams, and organizations with multiple development teams often struggle with competing priorities, diverse tools and technologies, and establishing best practices. A unified platform that can consolidate these elements of the development process and foster internal collaboration helps development teams focus on what really matters—writing high-quality code and accelerating application delivery.
Red Hat Developer Hub is an enterprise-grade, supported version of Backstage, an open source framework created by Spotify for building developer portals. Engineering teams can use Red Hat Developer Hub to reduce friction and frustration and boost their productivity, giving their organization a competitive advantage.
This developer’s guide to developer portals offers insights in terms of Backstage and Red Hat Developer Hub, which together represent the pioneering implementation of developer portal concepts.
- Learn what an internal developer portal (IDP) is and the problems it addresses.
- Get an in-depth view of Red Hat Developer Hub (RHDH), built around the open source Backstage core to implement an enterprise distribution of a platform for creating developer portals.
- Dive into the tools found in an RHDH instance and learn how to work with those tools to build an application.
- Understand the basics of Backstage Software Templates and the architecture of the example application.
Excerpt
Hello, [cruel] World
Writing “Hello, World” hasn’t gotten any harder. But running it has. Hello, World today means a running container, built by an automated pipeline (triggered by a source code commit) into a container image, stored in some registry, with an attendant manifest declaring how it should be brought to life by a container orchestrator.
There is a lot of stuff that is not your application.
So much YAML
Build configuration, CI/CD, container, repository, Deployment, StatefulSet, Ingress, Route…
You want this stuff—or you should. And your company definitely wants it. It has a lot of benefits, even though we’re focusing on some of the drawbacks right now. But complexity in doing simple things will threaten to impose diminishing returns. In computing, the answer to complexity is always abstraction.
You’re supposed to be an expert in Java, Go, Python, or whatever your language and framework–not an expert on the details of your new team’s AWS and OpenShift environments, configurations, and prerequisites.
Trade it all for just a little more
Internal developer portals (IDPs) aim to provide abstraction of development processes, offering a surface for capturing a team’s tools, libraries, source boilerplate, and configuration and centralizing access to them. Ironically, in the IDP ecosystem examined here, simplifying all that YAML involves… a little more YAML.
Internal developer platforms
An internal developer portal is a set of tools, services, and practices intended to improve the productivity and collaboration of software development teams by abstracting and automating the surrounding complexity of the development and deployment process. An IDP provides developers with a unified environment for managing application components, services, and the development life cycle, including code, infrastructure, and deployment. IDPs address several key challenges in the software development process, including:
- Complexity: Modern software development involves many tools, services, and processes. IDPs centralize access to these resources.
- Collaboration: IDPs promote collaboration by offering shared resources, standardized workflows, and a consistent experience in a development team.
- Visibility: Developers can’t always see what other teams are working on. IDPs make large deployment environments more transparent.
- Productivity: By automating repetitive tasks and providing self-service capabilities, IDPs allow developers to focus on writing code and delivering value.
