4 ms·

I’m not sure who the customer is for Backstage. For a small startup, poking around in the gcp/aws console works well enough. Maintaining another console layer

I’m not sure who the customer is for Backstage. For a small startup, poking around in the gcp/aws console works well enough. Maintaining another console layer on top of that feels like one more thing that could break. If you’re a big company with a team that could support developer platform tools, you probably have some sort of portal system hacked together and you’ll never be able to change because somebody has a critical dependency on the old system

acedTrex 2y ago
The big company use case is the ideal backstage use. Backstage is just a framework. you can use it to interface with the old system behind the scenes and provide a nicer layer on top for your application devs.
mrbluecoat 2y ago
Glad I'm not the only one confused. Even the product purpose seems vague... > Libraries, websites, ML models — you name it, Backstage knows all about it
- frompdx 2y ago
  This is in reference to the software catalogue feature.
_cenw 2y ago
Backstage is great at slowly migrating dysfunctional organizations into slightly less dysfunctional organizations. I deal with 30 years of random tech debt in a company with immense shadow IT (domains randomly registered, vendors randomly hired to do X, often nobody knows things are still needed, our zonefiles are a mess, unclear responsibilities with our team of 4 being the default fallback), and Backstage at least puts some semblance of insight into that entire mess and provides a way forward to formalize such processes. Also, putting documentation where developers commit to every day instead of a Wiki where it's out of sight / out of mind is very underrated.
- parpfish 2y ago
  But doesn’t that mean you have a long migration period with two systems to maintain and reconcile?
  - eszed 2y ago
    Yes. I've seen this go well, and I've seen this go terribly. It works (in my experience) when the migration work is pushed down to the directly responsible teams - with, of course, affordance made for the time it will take them. (Sidenote: that has the benefit that they learn / re-learn their dependencies for themselves, and discover efficiencies they never would have otherwise.) An overarching "migration team", or whatever you choose to call it, only adds friction, confusion, and more kludges. Management has to be fully committed, and enforce deadlines all the way down the line. Running two systems can (usually) be done short-term, but not long. (Another thought: "short" and "long" terms are variable for different teams and different types of services. Scheduling should take that into account.) Admittedly, however, I've not been through it at a particularly large organization. I'm sure there is exponentially metastasizing complexity (human perhaps even more than technical) once the process involves more people than can fit in a room.
  - p_l 2y ago
    In such dysfunctional case the truth is that you do not have an old system to reconcile with - there's no real system of record
arnvald 2y ago
Companies grow - today you have 50 engineers and a few microservices, in 2 years you might have 200 engineers and tons of APIs and web applications. I think if old orgs could have bought off the shelf developer portals years ago, they would have. Now companies that grow have this option. It might not be a massive market, but there are a few interesting companies building this kind of tools and they sell it
sbarre 2y ago
We were that big company (50,000 employees, probably about 10,000 or so in technical roles across the enterprise) that had a bunch of custom portals and internal sites for all our dev stuff, and also Stoplight (Spotlight?) for APIs etc.. We were early adopters of Backstage, back in 2020. We've migrated almost all of our portals and "meta-infrastructure" to Backstage, and it's certainly not perfect, and not everyone has moved over, but the majority of our teams are in one service catalogue and people can much more easily find service owners, dependencies and more. It's been a great tool and a pretty big internal success story for us. But this move from Spotify tells me that they are no longer stewards of an open source project, they now use open source as a loss-leader for their paid offerings. Which is totally fine, but it will change how we look at that relationship.
siva7 2y ago
The customers for Backstage aren't startups but mostly big corporations with hundreds of developer teams. Those corporations want to get rid of these hacky internal solutions and many don't even have one.
moltar 2y ago
Yes, and it’s not just poking. You have to actually code lots of stuff from scratch and maintain it. Feels like you almost need a full time person maintaining it.

acedTrex 2y ago

The big company use case is the ideal backstage use. Backstage is just a framework. you can use it to interface with the old system behind the scenes and provide a nicer layer on top for your application devs.

mrbluecoat 2y ago

Glad I'm not the only one confused. Even the product purpose seems vague... > Libraries, websites, ML models — you name it, Backstage knows all about it

frompdx 2y ago
This is in reference to the software catalogue feature.

_cenw 2y ago

Backstage is great at slowly migrating dysfunctional organizations into slightly less dysfunctional organizations. I deal with 30 years of random tech debt in a company with immense shadow IT (domains randomly registered, vendors randomly hired to do X, often nobody knows things are still needed, our zonefiles are a mess, unclear responsibilities with our team of 4 being the default fallback), and Backstage at least puts some semblance of insight into that entire mess and provides a way forward to formalize such processes. Also, putting documentation where developers commit to every day instead of a Wiki where it's out of sight / out of mind is very underrated.

parpfish 2y ago
But doesn’t that mean you have a long migration period with two systems to maintain and reconcile?
- eszed 2y ago
  Yes. I've seen this go well, and I've seen this go terribly. It works (in my experience) when the migration work is pushed down to the directly responsible teams - with, of course, affordance made for the time it will take them. (Sidenote: that has the benefit that they learn / re-learn their dependencies for themselves, and discover efficiencies they never would have otherwise.) An overarching "migration team", or whatever you choose to call it, only adds friction, confusion, and more kludges. Management has to be fully committed, and enforce deadlines all the way down the line. Running two systems can (usually) be done short-term, but not long. (Another thought: "short" and "long" terms are variable for different teams and different types of services. Scheduling should take that into account.) Admittedly, however, I've not been through it at a particularly large organization. I'm sure there is exponentially metastasizing complexity (human perhaps even more than technical) once the process involves more people than can fit in a room.
- p_l 2y ago
  In such dysfunctional case the truth is that you do not have an old system to reconcile with - there's no real system of record

arnvald 2y ago

Companies grow - today you have 50 engineers and a few microservices, in 2 years you might have 200 engineers and tons of APIs and web applications. I think if old orgs could have bought off the shelf developer portals years ago, they would have. Now companies that grow have this option. It might not be a massive market, but there are a few interesting companies building this kind of tools and they sell it

sbarre 2y ago

We were that big company (50,000 employees, probably about 10,000 or so in technical roles across the enterprise) that had a bunch of custom portals and internal sites for all our dev stuff, and also Stoplight (Spotlight?) for APIs etc.. We were early adopters of Backstage, back in 2020. We've migrated almost all of our portals and "meta-infrastructure" to Backstage, and it's certainly not perfect, and not everyone has moved over, but the majority of our teams are in one service catalogue and people can much more easily find service owners, dependencies and more. It's been a great tool and a pretty big internal success story for us. But this move from Spotify tells me that they are no longer stewards of an open source project, they now use open source as a loss-leader for their paid offerings. Which is totally fine, but it will change how we look at that relationship.

siva7 2y ago

The customers for Backstage aren't startups but mostly big corporations with hundreds of developer teams. Those corporations want to get rid of these hacky internal solutions and many don't even have one.

moltar 2y ago

Yes, and it’s not just poking. You have to actually code lots of stuff from scratch and maintain it. Feels like you almost need a full time person maintaining it.