Is anyone here using <backstage.io> or something s...
# general
w
Is anyone here using backstage.io or something similar?
n
about to consider backstage.io
w
We are using a spreadsheet at the moment. @Nguyễn Luân I’m curious what features are drawing people in and if they look at alternatives?
k
We’re in the process of establishing solutions that backstage.io would be perfect for, but haven’t looked at it or alternatives yet… It does look very cool when you offer golden paths for your developers.
w
@Karl Mathias Moberg golden paths are pretty nice, I don’t know if we create enough new services to invest in it.
i
We are using it at the moment. The service templates are very useful if you can do them well enough that a service is created and has everything you need to start coding. The service catalogue is tricky to get right and we are not finding it that useful at the moment.
w
Good to know on the service templates! @Isaac Perez what challenges are you having with getting the catalogue right?
i
The usual challenges with this type of information repository: • Being accurate • Being up to date • Being useful We also want to expand the information available to be the one place where you find all the information you need about your service, but that need custom development time we don't have at the moment. I'm sure it can work, it just takes a fair amount of effort
t
@Jan Niederhumer this might become interesting to you
w
@Isaac Perez so even if it was up-to-date and accurate you’d still question if was useful?
i
Yeah, it may not have everything the users need most of the time. So if they only need to visit Backstage to know the owners of a service it's good, but not worth the investment in my opinion. You can have the same with a Gsheet. When it becomes useful is when you can see everything you need for a service so it's the single pane of glass, users get used to visit it and they actually do it often to find information. Does that make sense?
r
It's a medium term investment, in my opinion. You start using the catalog (and replace the sheets), and add more value over the time. I like to say here at the company: The anwser for every question should be: Look at Backstage. This remove the "where can I find this information" from the equation We are using the catalog now and the software templates, but some plugins are useful (Github issues, PagerDuty, CircleCI, Rollbar) and we are creating more blocks (or plugins in this case) over this ecosystem. If the only thing you want is a service catalog, maybe there are best options. But for medium/long term I think is a good solution
w
@Rogerio Angeliski what motivated everyone to invest the time? Or was it the investment of effort of a small few?
@Isaac Perez that makes sense finding time to improve it seems like a challenge for many orgs. What do people in your org currently do if they need more than they basic info in backstage? e.g. our teams at 99designs don’t seem to mind digging through GitHub and other tools to find out that extra info.
r
We are looking for a long term value, not just for a catalog First we started with the Service Catalog, building a Single Source of Truth for owners (We have the same problem Isaac told). After that we provide some golden paths for our engineers, so we add value and start to bring they for this tool. The funny thing is, for some cases the community is building what we need (a good example is the K8S Plugin and the Search feature) so we can look for another side of the problems (like how we manage our deploy process). It's not a big team, we are 9 people looking for this (we are working in other problems in the company, not only in backstage). And you can try Backstage Saas with https://roadie.io/, what is really nice if you are alone in the dark 😄
i
@Wayne Allan, they go to the systems where the info is which can be GitHub, Sentry, DataDog, Jira, Notion, etc... Users here don't seem to mind if they know already where the info is, but for new joiners is a very bad experience. I'm also betting that once the info is in one place, easily accessible, and with good quality, people will mind less having to use Backstage than many other systems.
w
@Rogerio Angeliski how did you get people to care about the long term value? That’s something I’m struggling to do.
a
For now we have one portal for common tools through gitlab, logzio, secrets and some extra links. Next may we'll be pushing service mesh with linkerd and ambassador. We're going away from the big mud to separated business areas.
f
Thanks for this link! Installing it now. Been looking for a solution now that my favorite platform CloudCenter is EOL. Hopefully this is the one!
r
@Wayne Allan This is difficult, of course. First we created what we call state of productivity for our engineering team. This is a doc with an analysis about why is difficult (or slow) for our team put high quality software in production. After that, we show how we can be more fast doing that, based in DORA metrics report, and what need to change. Just to be clear, you don't need Backstage for this. But you need something, and for us, Backstage is a good option. This text could help you to see other tools https://medium.com/contino-engineering/creating-your-internal-developer-platform-part-2-65ff217cecd6
h
@Wayne Allan chiming in here a little late. I was going to share what Rogerio Angeliski shared. The article provides a decent summary of Backstage alternatives. I think it’s important to determine what the primary problems you’re looking to solve are. Most IDP solutions are going to give service catalogs out of the box – but a good question to ask yourself if how are you going to leverage the info in that catalog? We believe the value of the info stored in a service catalog is its ability to track the production readiness of a service (i.e does the service comply with your orgs standards & best practices). This is also a good way to communicate long term value because it allows you to essentially say “this service was at this level of compliance before introducing this tool, now it’s a noticeably high level” I’ll also echo what @Isaac Perez pointed out. Keeping a service catalog up to date is almost impossible if you’re doing it manually. We use a combination of git integrations, a k8s syncer, and deploy tracking tools to ensure the catalog is correct.