Imagine being a newly-hired developer. You have been assigned to create a new application.
You've got a number of things that you need to figure out. What language are you going to use? Where is all the code stored?
The code that you need to write or change? And the code that that depends on? What sort of resources do you use? Do I use a SQL database or noSQL, or something else?
Where is all the information about this?
In the Git repository?
Or in a SharePoint site?
Is it in Confluence or another repository?
And how much do I have to read before I can start becoming productive?
As a manager of a technical team, or a technical organization, you have a number of concerns. You're always being challenged to accelerate delivery.
How do we get better code faster?
How do we promote consistency and quality across the organization?
I've written up these standards and patterns, why is nobody following them?
Why do I have to keep reminding people to follow them?
And how do I encourage people to reuse the assets that have already been created?
And a topic that keeps coming up: How do we reduce technical debt?
And then the people who keep all the systems running. Different organisations have different names for them, but they include site reliability engineers, cloud engineers, system administrators, platform engineers.
These people are required to keep everything running and make sure that it performs. You also have the same challenge as management: how do you encourage developers to write good code that you can support, that you can deploy in an environment that is secure and safe?
How can you do that efficiently by linking it into the CI CD tool chain you spent so long preparing? And how can you make sure that it hooks into the tools you use to observe the application and its performance? There are a lot of these tools. And there's a lot that organizations are connecting together in order to deploy and run applications.
Often the developers aren't aware of that. Many of them don't even care. They just expect the infrastructure people to deal with it.
Platform engineers need to provide feedback to the developers, educating them about what would help keep your applications running, if you did things a certain way.
Gartner predicts that by 2026, 75% of organisations with platform engineering teams will provide Internal Developer Portals to improve developer experience and accelerate product innovation.
Internal Developer Portals are built by the platform engineering team, so that developers have the tools, resources and the information they need in order to produce quality code quickly.
An Internal Developer Portal brings together information and tools to make it easy for developers to do the right thing, but hard to do the wrong thing. Key features include:
- A Software Catalog that lists all your organisation's applications, APIs and databases.
- Documentation on the organisation’s standards, policies and patterns.
- Templates for new applications that bake in the organisation’s standards, style guides and links to testing and monitoring tools
- Visibility of the application’s progress through the CI/CD pipeline and its performance in production.
The Software Catalog is the foundation, and the focus of our course: Build Your Software Catalog with Backstage.
The course shows you how to map your Organisation’s Tech Stack to Backstage's data model, install Backstage on AWS, and create a Software Catalog that lists all your organisation's applications, APIs and databases.
Join the course: Build your Software Catalog with Backstage
Get your Internal Developer Portal started with Backstage on AWS