This message was deleted.

That was a interesting debate, im kind of curious to see what https://github.com/krateoplatformops/krateo will do with crossplane and backstage, also what both those communities will do in general 🙂 , since talos.dev/ has cluster api support and terraform modules in the works im sure together with crossplane it will soon cover the onprem baremetal side of things 🙂 ( on prem is still a bit hard if you want to stick with opensource )

@Chase Roberts mentioned https://www.opslevel.com in a prior thread

There is also https://humanitec.com/ 🙂

ha just noticed it was originally a link back to that thread, apologies. i'm still comparing options and forming opinions. i have some ideas, but mostly preferences based on past experiences (e.g. prefer flexible framework/composability vs overly opinionated monolith). starting with a new team soon that is 5 SREs sharing platform responsibilities with ~300 devs and expected to grow to ~500 by end of year. need to get inside and peek behind the curtain, but looking to add something like this to help improve developer experience especially for new hires.

ya krateo is the closest i could find, unless you want to put something together, depending on the use case seems like quite a few teams are using crossplane + backstage as the core

yes big k8s (EKS) shop, and when interviewing it was revealed they've just started adopting argo. backstage + crossplane + argo is probably the right combo since it's working well for others (nice to have community). part of me wants to build from scratch (like dev work), but i also know that's a rabit hole and have other SRE responsibilities as well 🙂

ya im on the same boat just me having to support 30 devs 🙂 that was what the future platform combo I have sort of arrived at for the same reasons lol

thanks for sharing your preferences and context 🙏

hello, we’re using backstage in our tech department atm mostly for service/tech docs discoverability. However we find that very few people in the org see or understand its value proposition, or find it super useful. Would like to hear about thoughts from backstage adopters if there’s any here.

would love to hear from backstage adopters as well 🙂

that's what i worry about. taking time to adopt something that doesn't actually excite users. i don't understand the option enough yet to know how much of this is a product/tech vs configuration/customization issue. i do have a "lean product" mindset in general, so rolling something out to discover users aren't excited is concerning...i would prefer to start with "customer" conversation, understand what would excite them (or alleviate biggest pain points), then use that as a requirement for tech identification.

At my last job, we were onboarding on to backstage and no one understood the value it added

interesting trend, backstage has gotten a lot of press...but this is good perspective from early adopters! it might explain the slight jab (i think?) in talking about "idp / portal needs to be more than a bunch of links" with backstage reference 😄

nods

At a previous company we (SRE team of 8 ) started running backstage and had significant barriers to entry, specifically around getting buy-in from other leaders/orgs in the company finding value in it when we already had other tools which could be pieced together to create a similar catalog of services. Our initial goal was to just get all services into backstage so we could simply understand as a fledgling SRE org what types/kinds of

thingz

we had. We felt once we had this that we could then better help our customers (developers) and thereby actual paying customers. 🙂 So we had a heck of a time getting all of the moving pieces setup for backstage (it wasn’t your typical CNCF project to spin up in kubernetes and get a dashboard/login). Deploys were harder to manage, as well as having to learn typescript . Overall, after a little over a year, we still had downtime when deploying changes to backstage , had a hard time getting teams to add the necessary file(s) to their repos so we could scrape them, etc. Overall, at this point a classic build vs. buy scenario. If you sit down and look at what you want to accomplish, especially if you are a smaller team wanting to implement impactful changes on the org in a timely fashion, there are tools out there that can do that which alleviate the overhead of having to extend, update, and maintain all of the components needed to run an opensource tool like backstage . Also, some of the paid tools get you pretty cool features which are still just

Issues

on the backstage G . Just some of my personal experience with this problem space. 🤷‍♂️

Cool, good to know 🙂

throwing one more into the mix 🙂 https://shipa.io/development/development-environments-on-kubernetes/