7 ms·
Spotify getting into enterprise IT tools
- threecheese 2y agoPlease don’t use “IDP”, we really already have that (for chrissakes we have like four of them in our “enterprise IT”). They can have SAML also, “Spotify: Acronym’s Mine, Losers”.
- parpfish 2y agoI’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 agoThe 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 agoGlad 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 agoThis is in reference to the software catalogue feature.
- _cenw 2y agoBackstage 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 agoBut doesn’t that mean you have a long migration period with two systems to maintain and reconcile?
- eszed 2y agoYes. 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 agoIn 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 agoCompanies 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 agoWe 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 agoThe 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 agoYes, 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.
- jessetemp 2y ago[flagged]
- toyg 2y agoWhat do you mean by "sensible"? Spotify has playlists, but most listeners simply don't bother. Plus, it's obviously convenient for the platform to actually control what you're going to listen to next, so obviously they'd rather emphasize the "magic" auto-queueing (which, tbh, kinda works well-enough).
- jessetemp 2y agoWell to me, sensible would be where I can play an album, and then select a couple more albums to start playing in sequence after the first album. Spotify's queue doesn't do that, at least on windows. Instead, playing the first album adds it to a queue but not the queue. Selecting more albums inserts them after the current track, not after the album. If I decide I want to remove the remaining tracks of the first album from the ghost queue and only listen to the queue I have to remove them one by one. And the most bonkers part, is when removing the last remaining track from the first album's ghost queue, Spotify replaces it with a different track from the first album! There's no way to remove the ghost queue. The workaround is to simply not use the play button and only add albums to the queue by clicking into the ellipsis menu, but it's a bit of a kludge and not what I'd call sensible. Plus for some reason I always go for the green play button first, then decide later that I want to add a few more albums to the queue
- deleted 2y ago[deleted]
- jakozaur 2y agoIt is tough to keep two widely different businesses under one roof. One is a mature, public B2C, and the other is a dev tooling startup. Spotify should spin off Backstage as a separate company, providing the initial IP and funding and being the first client. Many companies, like Uber, created a lot of useful infra, though they failed to monetize it. They could take a cut in the Chronosphere (M3) and Temporal (Cadence). Much better than laying off people, though origin companies would need to be smart, without being too greedy. Though the model is unproven.
- anonzzzies 2y ago> One is a mature, public B2C, and the other is a dev tooling startup. Amazon/AWS?
- jakozaur 2y agoAmazon is an outlier, where each business runs its profit/loss, and higher-ups act as VCs. Wish more companies were like that, but you need to take a lot of bets to make that work. AWS worked, but the Fire phone turned out to be a write-off.
- gghffguhvc 2y agoFire Phone was largely outsourced I’ve been told. Was big regrets all the way to the top about that decision. Lesson learned.
- theturtletalks 2y agoIf anything, AWS looks like the outlier compared to their other projects. It only survived because of the sheer size of Amazon.com and was built to accommodate that traffic and deployment. If they set out to create AWS without the need for it, don’t think it would’ve made it this far. Even after all these years, AWS is the breadwinner, while the website it was made for can barely turn a profit and resorts to increase the price of prime every year to show revenue growth.
- 2y ago
- claytonjy 2y agoHas 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.
- badgersnake 2y agoWe use it, and apparently it’s great. It didn’t help with the silos though because I don’t have access.
- dilyevsky 2y agoIve watched a couple of botched attempts at implementing it and just like with other spotify fads you need to be all in or not at all. Also im highly sceptical it is actually going to “break your silos” or whatever they are promising because silos usually come from the management and the culture not the type of idp management happened to cargo cult on you
- ravivyas 2y agoIt depends how you define successful. I work in a large org, and it work well for governance, and as a console, but it has its limitation. Pushing too many plugins on it makes management of the console hard
- whirlwin 2y agoWe're 30-40 developers, and we have just stopped using backstage. We started using it for APIM behind Okta SSO, but all the custom frontend and functionality tweaking needed to make it look nice was daunting. If we start looking at it again, I'd try a simpler use-case, but definitely interested in trying it again.
- stackskipton 2y agoWe 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 advice I would give. See if Kustomize would get the job done and be honest. I've found Devs can handle Kustomize a ton easier since kubectl kustomize > testoutput.yaml is alot easier for them to parse. Helm is great if you have a bunch of different things to launch with a ton of different options but most companies don't do that. They need HPA/Deployment/Service/Ingress which is easily handled by Kustomize.
- lloydatkinson 2y agoI’ve always thought Backstage seemed like an interesting solution to existing god awful “solutions” many enterprise type companies subject their devs to. For example, PostHog, Swagger.
- esafak 2y agoI think you have the wrong product; PostHog is for startups, not enterprises.
- lloydatkinson 2y agotry tell that to the people insisting we need it
- namanyayg 2y agoWhat's bad about PostHog? I haven't tried but I thought it looks good
- dilyevsky 2y agoWhat’s wrong with PostHog? Do you mean Postman?
- soygem 2y ago[flagged]
- deleted 2y ago[deleted]
- gibbitz 2y agoMy employer is considering using backstage for our data infrastructure tooling. This makes me nervous because Spotify seems unable to program a reliable shuffle feature on their player. Maybe it's because they put all the good devs on backstage?
- btown 2y agoSpotify's shuffle algorithm can't be changed easily because too many people rely on its existing quirks. Which means that Spotify's ability to keep it at a reliably stable level of unreliability for so long, through so many other platform changes, makes it a prime example of why Spotify is a perfect choice for enterprise! ;)
- saghm 2y agoIt's true; they make UI changes that no one wants (like pushing the queue off to a sidebar that can't be expanded to the way it used to be), constantly try to push features I don't want (some weird "DJ" feature that has an actual programmed voice between songs, "collaborative" playlists when I pretty much exclusively listen alone with headphones), and refuse to implement extraordinarily simple features that would be universally popular (like being able to mark certain songs/artists as "don't ever play this for me please"), and yet the few other players in the space all have similarly mediocre products that give me no real choice. This is peak enterprise UX.
- deleted 2y ago[deleted]
- tuyguntn 2y agopeople who are using DataDog, how does it compare to DataDog service catalogs? If I want to use Backstage what kind of value add it provides over observability tools with cataloging tools?
- frompdx 2y agoThe scaffolder is the part Datadog won't get you, and in my experience it is the most useful feature.
- siliconc0w 2y agoThe 'single pane of glass' is pretty seductive and there are a lot of tools that try to sell that vision. Backstage looks a pretty good swing with their modular/flexible approach, though I haven't used it. The problem you end up having is that (for example) Google docs is really good for writing and commenting on docs, and a general purpose tool is never going to be as good as Google docs for docs. You could write a "Google Docs" plugin and just link out to a project's google doc but then you're just a link aggregator which offers limited usefulness.
- ravivyas 2y agoI think one of the largest problems they will face is their consumer not having the same culture as them, and what worked wonderfully for them failing in other orgs.
- rglullis 2y agoThe "Featured Article" at the top means it's a sponsored post, right?
- deagle50 2y agoand the account that submitted here has zero comments.
- rglullis 2y agoSomewhat 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.
- immibis 2y agoMaking them buy immunity.
- morkalork 2y agoBut how do we know you aren't just one of replyguy's bots being used to promote his service right now, eh?
- MichaelZuo 2y agoTo 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.
- deleted 2y ago[deleted]
- frompdx 2y agoBackstage 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/configure-app-with-plugins/ https://backstage.io/docs/getting-started/configure-app-with... Additionally, check out what it takes to stand up a standalone backstage server. You used to have to clone their repo if I remember right, but now they give you a starter template via npx and leave it up to you to put all of the pieces together. They don't even ship a docker image to get you started. https://backstage.io/docs/getting-started/ https://backstage.io/docs/getting-started/ Frankly, the architecture of Backstage is ill-conceived and a hassle to operate. If you have the budget their are vendors that will deal with all of this for you. I think the concept of Backstage is fine, but the execution leaves a lot to be desired.
- MyFedora 2y agoI 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.
- frompdx 2y agoThe trouble with the way Backstage is designed is that it makes keeping everything up to date difficult. It is also harder for them to ship updates for their core and plugins due to the labor involved in incorporating any updates. A plugin architecture like Wordpress or Grafana is much more manageable for an operator. In fact, a set of plugins for Wordpress could probably get you an equivalent solution, but it's PHP, so you know, ew. I'd love to see an alternative to backstage that gets it right.
- muhehe 2y agoI saw link to backstage some time ago, but I could not figure out what it's supposed to provide. Can someone explain what it does / what do you use it for?
- azemetre 2y agoIn a past job of a fairly decent sized org (around 80 engineers, maybe 10 different active projects, a few dozen microservices, component library, template generators, and some custom CLTs) it was very useful as a way of documentation for your engineers. I'm sure you used stuff like confluence but it was always a terrible way to search across code bases and projects to understand how they worked. Backstage was interactive documentation. I can see what projects we have, I can click on one, see who is maintaining it, what their communication is, what their various perf/benchmark scores were. It was nice. Apparently it's even grown beyond documentation needs from what I can tell and it provides platform tooling now.
- arnvald 2y agoBy default it offers you a few tools to better understand and manage your software landscape: - you have all your micro services catalogues in one place, with a fairly decent data model (services are grouped into systems, they are owned by teams, they have declared dependencies on each other) - you have documentation for each service that you can easily find - you have a template catalogue that allows you to easily create new services. You need a full-stack app? Here, recommend option is Java + React, use this template. You need a new ML system? Here’s what you should use, click “create” and we’ll bootstrap it for you - plus a few more, like customizable home page If you are looking for a way to start cataloguing and standardizing services across your org, the developer portal (whether Backstage or other solution) is a good thing to have
- shanemhansen 2y agoTo me it looks like a SharePoint for engineering teams. With plugins focused around projects/deployments/metrics. Which sounds actually interesting.
- probably_jesus 2y ago[dead]
- betimsl 2y agoYes. The world needs another one of these...
- DueDilligence 2y ago[dead]