This message was deleted.

As opposed to building the capabilities yourself? Or are you questioning the concept in general?

Partly of both. I think a lot of the functionality is already covered by quite some other tools. It does depend on context, so therefore curious to the #1 argument.

For us it was the ability to create service templates and automated patches (e.g. if they don’t want the entire service, just interested in adopting the recommended deployment templates)

Backstage is not an Internal Developer Platform. That's really important to clarify. A platform is the sum of all the tech and a platform engineering team designs into a golden path for developers to reduce cognitive load and drive standardization by design. The question you are actually asking:

Do I need a Developer Portal.

What's the different to quote Gartner:

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

@Kaspar exactly! Some terminology differences, but we mean the same thing. We have multiple platform teams, and a lot of the functionality that is posed by various solutions is already covered. I’m really not fully convinced an additional UI is needed, so am wondering what others are using it for. Reducing cognitive load can be done in so many other ways

This is another one, @Jelmer Borst.

@Jelmer Borst - in our case, we have 3 main platform teams - cloud infra, service platform (purely for microservice related tooling), and delivery platform (handling ci/cd). Individually, these teams do a fantastic job of serving the developers. Processes are kind of self-service where they create PRs for their needs and platform engineers approve, merge and apply (terraform). But overall, it feels like the developers need to run from pillar to post to get one task done. So our portal is trying to automate this chain. Also, when I asked the platform engineers how bad would it be if some of these PRs were generated and merged automatically, they said, well if the template is accurate, and there is no scope for human error, then we don’t mind. Right there, we take away a lot of tedious support work from the plate of platform engineers who run the risk of turning into zombies doing the same kind of task over and over.

Similar to @Kashmira Patel, we are using our portal as a window/landing place for our automated tools. We also find the catalog to be really helpful for teams when they are trying to debug an issue and aren't sure who to talk to.

Oh right! What @Tracy Kropp said.

@Jelmer Borst you might find it useful to ask your developers what it's like to be a developer using your platform. They might tell you that it can be difficult to find information that they need about services they need to consume or that it requires a lot of tribal knowledge to be productive. If you ask new hires vs long term employees, they might share different experiences. Interviewing developers is what leads companies to adopt Backstage to create a single glass pane for their IDP because having to access 5 tools to get one task completed is very exhausting.

We are going towards a Dev Portal first before automating our Platform, our Platform is the usual scripts, templates and docs but we see more value first in centralizing everything in a Portal that will create a virtuous cycle when we automate more of our platform as there will be one place for everything Scale is driving us to do this as its not scalable manually maintaining indexes and docs everywhere. We are at 150 in R&D

love this title Why putting a pane of glass on a pile of sh*t doesn’t solve your problem

All very good points in this thread! We’ve been mostly focussing on automation, and making sure things work well out of the box. For example, our CI definition is in 1 place, our Java libraries are in 1 place (with auto upgrades everywhere). We can document all of it, or we can just make it work. We have barely any docs (apart from code docs) with 300 engs. Would love to learn more about your decision there @Andre Marcelo-Tanner.

https://www.linkedin.com/events/makingthecaseforadeveloperporta6968897119487160320 I will share our approach to identifying the need and investing in a developer portal in this talk in October if you are interested 👆

@Jelmer Borst for us it was about what could have the largest impact sooner. We have a lot of information everywhere and different users have more to gain from a Dev Portal than a service platform. We want to follow that quickly with a more automated platform that just works but for us that will take time to build , integrate, adopt. If we were starting early I would be building the platform better similar to @Brandon McNama . We just have so much sprawl and teams building that its a much larger ask at our stage.

Thanks @Andre Marcelo-Tanner. What type of information do you mean? Like, documentation?

What services do we have, who owns them, where to contact that team, whos on call, where are there alerts and monitors, dashbords. Is the service healthy. When was the last deployment. How are services connected together. What are the latest vulns, errors etc. Right now that information is through • tribal knowledge • Documentation systems like Notion • Pagerduty • Jira • Spreadsheets • Sentry • Snyk • DataDog • Kubernetes Dashboards • GitHub Actions for CI and ArgoCD for deployments So centralizing this in a portal like backstage makes everyones workflow simpler. We recently had a reorg and teams have to learn different services now