Live data from Hacker News

Spotify getting into enterprise IT tools

techcrunch.com

51–60 of 72 posts

Re: Spotify getting into enterprise IT tools

#51
post #7

Earlier quoted context omitted.

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…

But doesn’t that mean you have a long migration period with two systems to maintain and reconcile?

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

Re: Spotify getting into enterprise IT tools

#52

The "Featured Article" at the top means it's a sponsored post, right?

and the account that submitted here has zero comments.

Somewhat related: the dev behind replyguy said he is working to add AI astroturfers to HN comments as well. I'm curious to know what type of mechanisms (if any) will be adopted to detect and neutralize them.

Re: Spotify getting into enterprise IT tools

#53

Earlier quoted context omitted.

and the account that submitted here has zero comments.

Somewhat related: the dev behind replyguy said he is working to add AI astroturfers to HN comments as well. I'm curious to know what type of mechanisms (if any) will be adopted to detect and neutralize them.

Making them buy immunity.

Re: Spotify getting into enterprise IT tools

#54
post #3

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 cr…

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.

Re: Spotify getting into enterprise IT tools

#55

Earlier quoted context omitted.

and the account that submitted here has zero comments.

Somewhat related: the dev behind replyguy said he is working to add AI astroturfers to HN comments as well. I'm curious to know what type of mechanisms (if any) will be adopted to detect and neutralize them.

But how do we know you aren't just one of replyguy's bots being used to promote his service right now, eh?

Re: Spotify getting into enterprise IT tools

#56
post #40

Backstage is built on a modular, plug-in based architecture that allows engineers to layer-up their developer portal to meet their own needs. Frankly, this is just incorrect. Just read the configuration guide for "installing" a plugin to see what I mean. You have to modify the source code of your own deployment in several places. That's not a plugin based architecture. https://backstage.io/docs/getting-started/config…

I did not expect that. So Backstage asks you to manually insert plugin components into the app source code? Yeah... that really doesn't feel like a plugin architecture to me. More like patch the source code so it does what you need it to do. Nothing wrong with that, but not a plugin architecture.

Re: Spotify getting into enterprise IT tools

#58
post #3

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 cr…

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.

Re: Spotify getting into enterprise IT tools

#59

Earlier quoted context omitted.

Somewhat related: the dev behind replyguy said he is working to add AI astroturfers to HN comments as well. I'm curious to know what type of mechanisms (if any) will be adopted to detect and neutralize them.

But how do we know you aren't just one of replyguy's bots being used to promote his service right now, eh?

To take this seriously, probably by account age, there just aren't that many 2007 accounts so eventually astroturfers will have to resort to newer and newer accounts.

Re: Spotify getting into enterprise IT tools

#60

Has anyone successfully implemented Backstage at their company? How'd it go? We're looking at it for an internal platform serving ~50 engineers today, spanning mobile, backend, enterprise integrations, and ML teams. The hope is it'll make it easier to spin up new things "the right way" without e.g. ML PhDs having to learn Helm and K8s, plus other goodies like nice docs.

We piloted two jobs ago and aborted. Wouldn't recommend at your size because it seemed to do effectively, you need a "Backstage Team" which is not Ops Team who occasionally does Backstage work. Probably why Spotify is considering it because sweet consulting money. While I don't know your exact situation, I'm currently at company of your size engineers and stop torturing your Developers with Helm is off the shelf advi…

I'm somewhat new to helm, after a year I feel like I'm pretty good at it, but struggle to teach other ML folks what I've learned the hard way over the last year. Some of that is helm, plenty of it is Kubernetes. Most of our charts are ingress, service, deployment, service account, scaled object (keda), but there's plenty of small variation even across ML applications, plus the different needs of other teams.

Any good resources you can point me to on how Kustomize might be easier for us?

Post reply on HN