12 ms·

I spent two years trying to do what Backstage does for free

284 points by danwee 4y ago

x3ro 4y ago
Curious, I just started a project to integrate Backstage at a Fortune 500, with > 10000 repositories. It does seem like a good foundation so far. Their idea of what it’s supposed to accomplish internally is mostly the same as what this blogpost describes.
- citruscomputing 4y ago
  Anything you've learned worth sharing? How has your experience with Backstage been? Why did you choose it over other options? I might be working on a similar project soon.
  - moralestapia 4y ago
    Are there other good options? Edit: Thanks everyone!
    - agmiklas 4y ago
      opslevel.com is worth checking out. (Disclosure — I’m an investor.)
      - kenrose 4y ago
        Thanks Andrew. (Disclosure: I'm a founder/CTO). Backstage is super configurable, but requires that you build your own developer portal. That generally requires a dedicated team of people at your company to think about dev workflows to support, building plugins, plus hosting/maintenance. At OpsLevel, we're focused on a much more turnkey solution. We want to get you up and running in under an hour, not weeks / months.
    - deleted 4y ago
      [deleted]
    - gsdatta 4y ago
      (Shameless plug) – founder of https://www.cortex.io https://www.cortex.io (YC W20) here! We build an off-the-shelf developer portal. Backstage is great if you have lots of time/very niche requirements, but most of our users need a system that "just works" to drive ownership/best practices without adding a ton of overhead
    - tecleandor 4y ago
      We didn't have enough time for testing, but there's also Clutch, coming from the Lyft team. (Checking right now I'm not able to see a "releases" page with versions and that stuff...) https://clutch.sh/ https://clutch.sh/
      - jdwithit 4y ago
        First time seeing this, but reading the docs it looks more like a modern take on Rundeck[0]. A way to give developers one-click access to operational tasks. Rather than a service catalog and developer portal like Backstage. [0] https://www.rundeck.com/ https://www.rundeck.com/
    - thisisbrians 4y ago
      We've just started using Atlassian Compass (https://www.atlassian.com/software/compass https://www.atlassian.com/software/compass) for our software catalog, but it appears to be much less featured than Backstage. We're taking a look at replacing it with Backstage, and curious if anyone else has notes on the comparison.
    - password4321 4y ago
      Might find some near previous mentions: https://hn.algolia.com/?query=backstage.io%2F&sort=byDate&type=comment https://hn.algolia.com/?query=backstage.io%2F&sort=byDate&ty...
    - derkoe 4y ago
      Just saw this video where a similar platform is introduced https://youtu.be/Abdp_BnRIx0 https://youtu.be/Abdp_BnRIx0 This is the website https://kustodian.io/ https://kustodian.io/ It has more features including onboarding, access control, etc
  - x3ro 4y ago
    It’s too early to say, unfortunately (which is why my initial post was not super useful, admittedly). All I can say for now is that, in all likelihood, a _lot_ of customization will be needed. Ask me again in two months :D
tus666 4y ago
You would think a writer would know how to write a less grammatically ambiguous title.
superdug 4y ago
This is great, and I think if it was fully adopted initially in greenfield, this would be a completely feasible solution. My question is though, these problems exist at large organizations and will be seen as "another tool to rule them all" synonymous with things like "sharepoint". Disclaimer: I'm not saying that backstage is anyway comparable to sharepoint except that it presents itself as this grandiose solution to all things on boarding and learning on your own. With that said, what's the low hanging fruit to entice adoption of backstage into an organization that already has a "process" like mentioned in the article of whiteboard meetings with stakeholders. Obviously that's not a great use of time, but it's also no extra learning or work, that SME can talk about their function without any preparation and can interactively answer any questions the learner asks at the time. That doesn't scale in practice, but it also doesn't require any more whole team buy in
- royjacobs 4y ago
  You are right, this is not going to be trivial and you definitely need buy-in on a management level. Backstage is pretty malleable but the only way to get it to work in an organisation if there is only a single source of truth for things like your software catalog. If there is a lot of legacy in your org, or if there is not enough buy-in then it will definitely be "yet another" system. There's a lot of functionality to unlock once you have a bunch of data in Backstage, though, so that could help tip the scale. The cloud costs dashboard that helps to show how much every service costs is a good demo :) One benefit to Backstage's approach is that you don't necessarily need to change your processes and tooling to work with Backstage. It can help, but it's not a strict requirement. Other tooling in the space requires you to buy in to their specific workflows and so on whereas Backstage is a bit more agnostic.
grinnick 4y ago
My company - roadie.io - offers SaaS Backstage. We're the second largest contributor after Spotify and we're co-hosting the first ever BackstageCon at KubeCon NA this year. Get in touch if you ever want to discuss Backstage. Email in bio.
- pforret 4y ago
  No pricing on your page? Are you “contact our sales team” expensive?
  - 0xbadcafebee 4y ago
    https://roadie.io/pricing/ https://roadie.io/pricing/
  - grinnick 4y ago
    ? There is transparent pricing from 50 up to 150 developers: roadie.io/pricing/ It's linked directly in the header. For deals bigger than 150 devs, we have found customers prefer to talk to sales.
    - kitbrennan 4y ago
      FYI: the link to the pricing page doesn't appear in your mobile menu
      - grinnick 4y ago
        Wow you're right. That's a bug. Thank you!
    - deleted 4y ago
      [deleted]
- 0xbadcafebee 4y ago
  FWIW, it would be great if you had a breakdown of the TCO. The price is at a point where many orgs would have some suit decide "we have a DevOps guy, we'll just run Backstage ourselves and save $27K/yr". I think it's worth the money but you need to show the suits where that money is going, what kind of value they're getting from having you run it, and consider the risks (what if it gets compromised, goes down, etc). Also, I don't see SSO mentioned; you really want to mention that, it's pretty important for enterprise.
jakswa 4y ago
It's hard to infer from some quick documentation-reading whether kubernetes is required to enjoy a lot of the described benefits. Feels like a big first step: "Adopt kubernetes." Having been at a medium-sized org leaning into kubernetes, I can see the draw of a system like this, especially for non-IC roles.
- royjacobs 4y ago
  No, that's not needed. There's a K8S plugin for Backstage that can link your deployments to the services in Backstage's service catalog, which is useful. But that's pretty much the only part of Backstage that would "require" Kubernetes.
  - azemetre 4y ago
    Isn't the only thing required for Backstage a GitHub account? It's been a while but I remember GitLab not having the same feature parity and OSS alternatives like Gitea being completely left in the dust. Kinda disappointing if this is still the case, that an OS tool requires corporate owned software to use but I suppose life is full of jokes.
    - royjacobs 4y ago
      No, there's no requirement for any kind of source control at all. If you do have source control in your company (and, if so, welcome to the 1990s!) you can set it up in such a way that all your repos get scanned for metadata that gets ingested into the software catalog. There's implementations for GitHub and Gitlab (I built that one at $PREV_JOB) and others. Also, other kind of metadata, like user and group information, can come from sources like LDAP, Azure AD, etc. To be clear, Backstage is not an alternative to Gitea, Github or anything like that. It's not a source code repository hosting tool.
mdlnr 4y ago
I also really dig the approach of Backstage but found maintaining the installation a real pita. They even give you a tool that tells you which lines have to be manually updated in your installation when updating (https://backstage.github.io/upgrade-helper/ https://backstage.github.io/upgrade-helper/).
- grinnick 4y ago
  This is exactly why we created https://roadie.io https://roadie.io I'm the founder.
- kenrose 4y ago
  Agreed. We've seen this with our customers at OpsLevel who lean away from Backstage. Installing (and updating) Backstage is painful. One of our team members who previously ran a Backstage instance at $OldJob wrote about that pain: https://www.opslevel.com/blog/hands-on-backstage-learnings https://www.opslevel.com/blog/hands-on-backstage-learnings
- prmoustache 4y ago
  The problem isn't really installing backstage but integrating all the stuff around it. It is not a turnkey solution per se and what they call plugins aren't plugins in the traditionnal sense where you would just download a package and put it in a directory. It requires editing the actual react code to set most of them. So maintaining backstage involve maintaining a set of patches and a pipeline to build a docker image.
iancmceachern 4y ago
My parents owned anf ran a jewelry store for 35 years, nearly their entire working life. My Dad was a master jeweler, goldsmith, sculptor. Among many things, they would string and re-string pearls for folks. Usually family heirlooms that they wanted to keep, but also be able to wear and not fear they'd break and fall all.over the floor. After years of doing that, and also buying raw oearls from overseas, stranding them, and then selling them, my Dad asked the supplier, do yoi guys do stranding? Yes, yes they did, for free. He could have been ordering pre-strung pearls for the same price the whole time. Stranding pearls takes time.
- bombcar 4y ago
  One of the questions I like to ask contractors before beginning work is "what changes would make this cheaper/easier for you?" Often simple things like moving a planned wall an inch or switching the location of something can make it vastly easier; or there will be things they can get preassembled or done for free. And sometimes the factory building whatever has a giant machine that can easily do what would take you quite a long time to do by hand.
  - lkois 4y ago
    I used to work in a place that assembled machines based on old designs that rarely got reviewed, since if it ain't broke don't fix it. When working on one particular unit, I found that they would order a bunch of plastic panels, cut to size, and some with precut holes. And others with secondary drawings, instructing us how to drill out a bunch of holes ourselves. Sometimes not even all the holes, just a few, in addition to the precut. When I asked why we didn't just ask the supplier to cut out ALL the holes, I basically got a shrug. So I merged the secondary drawings and sent them to the supplier, and the assembly team never wasted time on that nonsense again.
  - thehappypm 4y ago
    It’s funny. They seem to be two kinds of contractors out there. Type one will push as hard as possible for you to design things in a way that makes it easier for them. To the point where there are all sorts of design compromises like a beam in the middle of your kitchen. The second type is the one who wants to deliver exactly the vision of the client, to the point where they are adding a huge amount of complexity to perfectly meet unreasonable demands.
mcdonje 4y ago
His org used jira but not confluence? Why couldn't they just document these things in confluence? Edit: This is a serious question. What is that value prop of backstage over confluence?
- 1123581321 4y ago
  Structure of the data and more pleasant/immediate workflow increases adoption so it doesn’t go stale, like Confluence so often does. Some teams need those nudges more than others due to personality, turnover, speed of growth and complexity of service architecture.
- skrtskrt 4y ago
  backstage has plugins that can help with autodiscovery of a lot of this stuff. The stuff that's not autodiscovered can live right next to your code, in any repository, so devs can just update some YAML keys when they're making other changes. You can lint the backstage changes as part of PRs Also I've never ever seen developers consistently keep stuff up to date in Confluence. There's just so much friction in that interface.
  - mcdonje 4y ago
    Auto-discovery does sound appealing. Thank you.
- rdonovan 4y ago
  Author here. We did use Confluence, but as other folks had said, it went very stale. Not everyone could edit everything and there was no structure. Confluence is a mess in my experience.
  - WesleyJohnson 4y ago
    Have to agree. Without a clear set of standards on how to structure things, it ends up being chaos very quickly. We had a PM for a while, who gravitated more towards QA, and when they got ahold of Confluence they went crazy (in a mostly good way). We had so many great "How To" articles on how to perform various tasks in our system form an internal user perspective, all authored by the same SME. Unfortunately, given their affinity for testing things, the How To docs starting taking on that QA perspective and everything ended up in a QA "space". Sure, it's easy to move them around, but there wasn't a clear cut way on how to separate the "How To" from the "QA" - and then they left. Since then, people add things when managers say "make sure that's in Confluence" and it ends up getting placed in the areas they're most familiar with, not necessarily where it should be. Add in the aforementioned lack of standards and no two documents look the same. Then we started using Confluence for devs to write Test Plans and QA to execute them - and now it just makes my brain hurt whenever I have to go in there. Some of it is a cultural problem: we're email and Teams heavy and so much of our "documentation" is buried in those tools. So then we adopt something like Confluence to move our knowledge base to that, but finding stuff in Teams is a nightmare (posted in another thread on that). So now rather than having one tool to rule them all, we just have another half-baked attempt. We're monolithic for the most part, so I'm not sure Backstage would help us, but the article mentioned Stack Overflow for Teams, so maybe that would? (insert relevant XKCD here on competing standards)
bdwalter 4y ago
(Shameless plug) Cofounder of OpenContext.com here. We're a bit different than a developer portal or services catalog, we're a complete context graph of all the assets in your product pipeline. Everything from products, documents, microservices, codepaths, vulnerabilities, people, teams, etc and the relationships between them. The complete context for DevSecOps. Check us out.
- ralphael 4y ago
  No need to apologise, a polite "I ran X which solves Y" related to the post is encouraged. Helps the rest of us learn about other solutions out there :-) Will checkout OpenContext, thanks for the link
qbasic_forever 4y ago
The real gem highlighted by backstage is the MkDocs Material theme: https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/ It's seriously awesome and has a lot of nice customization options. Out of the box it makes very clean and professional technical docs from a pile of markdown files. Even if you don't need to go the whole backstage route, seriously consider using mkdocs and the material theme.
- deleted 4y ago
  [deleted]
powersurge360 4y ago
I am becoming increasingly skeptical that good internal documentation is even possible. I've been working in software development for around 12 years and have _never_ seen it done well and asking around the best I've heard offered up is the equivalent of an internal stack overflow. For a while, I thought that maybe an exception would be having a technical writer on staff but after reading this post I'm significantly disheartened on that front too. I'd be interested to hear if anyone on hacker news has experienced good internal documentation and even more interested if any of you folks have experienced anything truly _great_. For my contribution, I've found that documentation fails for a couple of reasons. The first is the burden of correctness. The people who most would like documentation are also the people who most need the documentation and they usually are also the people most likely to be reluctant to contribute to the documentation because they don't feel they can accurately represent the information. Imagine someone ramping into a feature and spending a few days reverse engineering how it works, collecting info, etc. Sometimes they'll put it up somewhere but a lot of the time contributing partial information feels 'wrong'. And the second bit I find to be a big reason why documentation efforts fail is just the sheer friction of putting it into the documentation store to begin with. In confluence, for example, if you have a bit of information it can be tough to work out how to categorize it, where in the hierarchy it should go, etc, etc. Or if it's a GitHub wiki you want to put it somewhere that it is discoverable but also be careful that it's 'correct' because you don't want to break backlinks if it gets recategorized. I've mostly given up on it at this point. Instead, I take detailed personal notes and make them publicly available. It doesn't have to be correct because being advertised as personal notes means that it's my opinion on the truth rather than objective fact. It isn't far away from my codebase, I can just tap a short keybinding in my editor to type my notes or search them and I can link directly from the notes to lines of code in files to jump back and forth. The particular system I use means that if I write a short snippet of code to solve a one off issue (like calling a path helper to derive a URL that I can't find in the interface) I can even drop it in a code block and execute it right from my note-taking tool. It isn't ideal for sure but I've gotten way farther in having a shareable knowledge base this way than I have in literal years of trying to get a shared, useful documentation store spun up.
- austinwade 4y ago
kenrose 4y ago
> So when I had questions, I needed to track down who owned the service, where their code lived, where their Jira ticket project was, which Slack channel they lived in, and where in the wiki their internal documentation was. Keeping track of this for 100+ services was a pain, so I ended up creating a spreadsheet. It turns out that everyone else in the org needed this information, so this spreadsheet that I created for myself became the document of record for services. 100%. Solving this problem is why I started OpsLevel [1] a few years back. Everyone always starts with a spreadsheet because they're flexible. But spreadsheets quickly fall apart because they're not complete / up-to-date, automated, or really scalable. We figured we could automate a whole lot of collecting service info from different places (Git, k8s, other deployment streams) and keeping it up-to-date. [1] - https://www.opslevel.com https://www.opslevel.com
- chime 4y ago
  I got interested in OpsLevel immediately upon reading your comment but was disappointed to find out that there is no public pricing and I have to contact for a demo. That goes from Cloud SaaS to Enterprise territory. Maybe some day we will grow enough to give you a call but your post made me realize we should definitely look beyond spreadsheets to document and manage our infrastructure. Thank you and hope you open up your pricing and trial accounts in future.
  - kenrose 4y ago
    Thanks for that feedback re: pricing and demo. It's always a tricky balance, but I definitely sympathize with the feeling of just getting started without having to talk to a salesperson.
corwinstephen 4y ago
Unrelated to the discussion, just wanted to comment on Backstage's tagline: “Build an ecosystem, not a wilderness" which is ironic because a wilderness is arguably the most complete and perfectly functioning ecosystem you're gonna get.
- lgrebe 4y ago
  i like that thought. What would be a more ideal pair then? Build a wilderness, not a parking lot
  - codingdave 4y ago
    "Build an ecosystem, not dystopian sprawl"
  - lazyasciiart 4y ago
    Create a garden, not a wilderness. OR (depending on your audience) Build an ecosystem, not a garden.
  - georgeoliver 4y ago
    An ecosystem, not a Superfund site.
  - grangerg 4y ago
    Build an ecosystem, not an experiment. Build an ecosystem, not a science project. Build an ecosystem, not a microbiome.
  - SerCe 4y ago
    "Build a universe, not a multiverse" could capture the meaning pretty well, in my opinion.
robbyking 4y ago
Is there a term for this phenomenon, my dear Watson?
BannedInSweden 4y ago
The main problem with Backstage (BS) is that while it does provide some canned functionality, any extension of that functionality requires the utilization of their plugins system and wholesale buy-in to their ecosystem. Welcome to Wordpress for enterprise developers folks! The plugin system isn't bad - but its a false narrative to believe you plunk this down and get some sort of valuable developer portal at an enterprise level (small biz sure - fortune 500...yeah no). Spotify does open-source a number of their plugins, but after having looked extensively at which ones they make available and which ones we would have to write (and deal with their plugin system for) we opted out. The cost/benefit ratio is definitely there for a technical writer, but IMO its not there for serious development. (Pls - Anyone who disagrees with that - begin by telling me why you don't use Joomla as a base for all your custom applications ) Team integration at a company level is another challenge with Backstage. GitHub (the basis and sort of harvested DB for BS) is largely disconnected from company structures and AD and all the things for most companies. Yes GitHub enterprise is a thing... no in general its still not connected to company structures. There are teams in Backstage, but they are generally managed in isolation from the rest of the company which presents its own challenges and integration problems with other systems. Don't even get me started on the fact that asking everyone to put their service defintions in specific files in specific places in GitHub is no better/worse than making them enter it into a ui or spreadsheet or confluence article or anything except now its scattered in 10,000 repos - good luck getting everyone to change that. Ultimately this isn't software that you simply install and use. Its a base that will likely require extension, and doing so means going down a one way path of adoption. Nothing it does is compatible with anything else. Is that good for Spotify - sure. Lots of folks helping build software they want to use is great. Is it good for the community? I'm not so sure. This article felt like a paid add (not suggesting it was - just saying it read like one) more than an honest plus/minus of the software and is anyone really surprised a technical writer couldn't build a proper enterprise developer portal by themselves? In other news - water is wet, the sky is blue and my kid wants to watch youtube.
- Melatonic 4y ago
  So what do you recommend then instead?
NonNefarious 4y ago
Backstage is a well-known entertainment-industry site and publication. What's the motivation for trying to duplicate it?
- qbasic_forever 4y ago
  They're... not? "Backstage" is a noun. It's a place. It so happens some entertainment industry publication uses it as a name, and a piece of software that is totally unrelated also use it as a name.
  - NonNefarious 4y ago
    It's capitalized in the title, so it's a PROPER noun. And I've worked in software development for a long time, and have read HN regularly for a long time, and I've never heard of "Backstage" as software. There's a wide world out there, which some HN posters "forget."
gregw2 4y ago
Has anyone done this sort of thing for data, not just for services? I can't seem to find a data catalog that lets my tie information across databases + APIs + Kafka topics. Each catalog of schemas is separate with no way to link them really.

284 points by danwee 4y ago

x3ro 4y ago

Curious, I just started a project to integrate Backstage at a Fortune 500, with > 10000 repositories. It does seem like a good foundation so far. Their idea of what it’s supposed to accomplish internally is mostly the same as what this blogpost describes.

citruscomputing 4y ago
Anything you've learned worth sharing? How has your experience with Backstage been? Why did you choose it over other options? I might be working on a similar project soon.
- moralestapia 4y ago
  Are there other good options? Edit: Thanks everyone!
  - agmiklas 4y ago
    opslevel.com is worth checking out. (Disclosure — I’m an investor.)
    - kenrose 4y ago
      Thanks Andrew. (Disclosure: I'm a founder/CTO). Backstage is super configurable, but requires that you build your own developer portal. That generally requires a dedicated team of people at your company to think about dev workflows to support, building plugins, plus hosting/maintenance. At OpsLevel, we're focused on a much more turnkey solution. We want to get you up and running in under an hour, not weeks / months.
  - deleted 4y ago
    [deleted]
  - gsdatta 4y ago
    (Shameless plug) – founder of https://www.cortex.io https://www.cortex.io (YC W20) here! We build an off-the-shelf developer portal. Backstage is great if you have lots of time/very niche requirements, but most of our users need a system that "just works" to drive ownership/best practices without adding a ton of overhead
  - tecleandor 4y ago
    We didn't have enough time for testing, but there's also Clutch, coming from the Lyft team. (Checking right now I'm not able to see a "releases" page with versions and that stuff...) https://clutch.sh/ https://clutch.sh/
    - jdwithit 4y ago
      First time seeing this, but reading the docs it looks more like a modern take on Rundeck[0]. A way to give developers one-click access to operational tasks. Rather than a service catalog and developer portal like Backstage. [0] https://www.rundeck.com/ https://www.rundeck.com/
  - thisisbrians 4y ago
    We've just started using Atlassian Compass (https://www.atlassian.com/software/compass https://www.atlassian.com/software/compass) for our software catalog, but it appears to be much less featured than Backstage. We're taking a look at replacing it with Backstage, and curious if anyone else has notes on the comparison.
  - password4321 4y ago
    Might find some near previous mentions: https://hn.algolia.com/?query=backstage.io%2F&sort=byDate&type=comment https://hn.algolia.com/?query=backstage.io%2F&sort=byDate&ty...
  - derkoe 4y ago
    Just saw this video where a similar platform is introduced https://youtu.be/Abdp_BnRIx0 https://youtu.be/Abdp_BnRIx0 This is the website https://kustodian.io/ https://kustodian.io/ It has more features including onboarding, access control, etc
- x3ro 4y ago
  It’s too early to say, unfortunately (which is why my initial post was not super useful, admittedly). All I can say for now is that, in all likelihood, a _lot_ of customization will be needed. Ask me again in two months :D

tus666 4y ago

You would think a writer would know how to write a less grammatically ambiguous title.

superdug 4y ago

This is great, and I think if it was fully adopted initially in greenfield, this would be a completely feasible solution. My question is though, these problems exist at large organizations and will be seen as "another tool to rule them all" synonymous with things like "sharepoint". Disclaimer: I'm not saying that backstage is anyway comparable to sharepoint except that it presents itself as this grandiose solution to all things on boarding and learning on your own. With that said, what's the low hanging fruit to entice adoption of backstage into an organization that already has a "process" like mentioned in the article of whiteboard meetings with stakeholders. Obviously that's not a great use of time, but it's also no extra learning or work, that SME can talk about their function without any preparation and can interactively answer any questions the learner asks at the time. That doesn't scale in practice, but it also doesn't require any more whole team buy in

royjacobs 4y ago
You are right, this is not going to be trivial and you definitely need buy-in on a management level. Backstage is pretty malleable but the only way to get it to work in an organisation if there is only a single source of truth for things like your software catalog. If there is a lot of legacy in your org, or if there is not enough buy-in then it will definitely be "yet another" system. There's a lot of functionality to unlock once you have a bunch of data in Backstage, though, so that could help tip the scale. The cloud costs dashboard that helps to show how much every service costs is a good demo :) One benefit to Backstage's approach is that you don't necessarily need to change your processes and tooling to work with Backstage. It can help, but it's not a strict requirement. Other tooling in the space requires you to buy in to their specific workflows and so on whereas Backstage is a bit more agnostic.

grinnick 4y ago

My company - roadie.io - offers SaaS Backstage. We're the second largest contributor after Spotify and we're co-hosting the first ever BackstageCon at KubeCon NA this year. Get in touch if you ever want to discuss Backstage. Email in bio.

pforret 4y ago
No pricing on your page? Are you “contact our sales team” expensive?
- 0xbadcafebee 4y ago
  https://roadie.io/pricing/ https://roadie.io/pricing/
- grinnick 4y ago
  ? There is transparent pricing from 50 up to 150 developers: roadie.io/pricing/ It's linked directly in the header. For deals bigger than 150 devs, we have found customers prefer to talk to sales.
  - kitbrennan 4y ago
    FYI: the link to the pricing page doesn't appear in your mobile menu
    - grinnick 4y ago
      Wow you're right. That's a bug. Thank you!
  - deleted 4y ago
    [deleted]
0xbadcafebee 4y ago
FWIW, it would be great if you had a breakdown of the TCO. The price is at a point where many orgs would have some suit decide "we have a DevOps guy, we'll just run Backstage ourselves and save $27K/yr". I think it's worth the money but you need to show the suits where that money is going, what kind of value they're getting from having you run it, and consider the risks (what if it gets compromised, goes down, etc). Also, I don't see SSO mentioned; you really want to mention that, it's pretty important for enterprise.

jakswa 4y ago

It's hard to infer from some quick documentation-reading whether kubernetes is required to enjoy a lot of the described benefits. Feels like a big first step: "Adopt kubernetes." Having been at a medium-sized org leaning into kubernetes, I can see the draw of a system like this, especially for non-IC roles.

royjacobs 4y ago
No, that's not needed. There's a K8S plugin for Backstage that can link your deployments to the services in Backstage's service catalog, which is useful. But that's pretty much the only part of Backstage that would "require" Kubernetes.
- azemetre 4y ago
  Isn't the only thing required for Backstage a GitHub account? It's been a while but I remember GitLab not having the same feature parity and OSS alternatives like Gitea being completely left in the dust. Kinda disappointing if this is still the case, that an OS tool requires corporate owned software to use but I suppose life is full of jokes.
  - royjacobs 4y ago
    No, there's no requirement for any kind of source control at all. If you do have source control in your company (and, if so, welcome to the 1990s!) you can set it up in such a way that all your repos get scanned for metadata that gets ingested into the software catalog. There's implementations for GitHub and Gitlab (I built that one at $PREV_JOB) and others. Also, other kind of metadata, like user and group information, can come from sources like LDAP, Azure AD, etc. To be clear, Backstage is not an alternative to Gitea, Github or anything like that. It's not a source code repository hosting tool.

mdlnr 4y ago

I also really dig the approach of Backstage but found maintaining the installation a real pita. They even give you a tool that tells you which lines have to be manually updated in your installation when updating (https://backstage.github.io/upgrade-helper/ https://backstage.github.io/upgrade-helper/).

grinnick 4y ago
This is exactly why we created https://roadie.io https://roadie.io I'm the founder.
kenrose 4y ago
Agreed. We've seen this with our customers at OpsLevel who lean away from Backstage. Installing (and updating) Backstage is painful. One of our team members who previously ran a Backstage instance at $OldJob wrote about that pain: https://www.opslevel.com/blog/hands-on-backstage-learnings https://www.opslevel.com/blog/hands-on-backstage-learnings
prmoustache 4y ago
The problem isn't really installing backstage but integrating all the stuff around it. It is not a turnkey solution per se and what they call plugins aren't plugins in the traditionnal sense where you would just download a package and put it in a directory. It requires editing the actual react code to set most of them. So maintaining backstage involve maintaining a set of patches and a pipeline to build a docker image.

iancmceachern 4y ago

My parents owned anf ran a jewelry store for 35 years, nearly their entire working life. My Dad was a master jeweler, goldsmith, sculptor. Among many things, they would string and re-string pearls for folks. Usually family heirlooms that they wanted to keep, but also be able to wear and not fear they'd break and fall all.over the floor. After years of doing that, and also buying raw oearls from overseas, stranding them, and then selling them, my Dad asked the supplier, do yoi guys do stranding? Yes, yes they did, for free. He could have been ordering pre-strung pearls for the same price the whole time. Stranding pearls takes time.

bombcar 4y ago
One of the questions I like to ask contractors before beginning work is "what changes would make this cheaper/easier for you?" Often simple things like moving a planned wall an inch or switching the location of something can make it vastly easier; or there will be things they can get preassembled or done for free. And sometimes the factory building whatever has a giant machine that can easily do what would take you quite a long time to do by hand.
- lkois 4y ago
  I used to work in a place that assembled machines based on old designs that rarely got reviewed, since if it ain't broke don't fix it. When working on one particular unit, I found that they would order a bunch of plastic panels, cut to size, and some with precut holes. And others with secondary drawings, instructing us how to drill out a bunch of holes ourselves. Sometimes not even all the holes, just a few, in addition to the precut. When I asked why we didn't just ask the supplier to cut out ALL the holes, I basically got a shrug. So I merged the secondary drawings and sent them to the supplier, and the assembly team never wasted time on that nonsense again.
- thehappypm 4y ago
  It’s funny. They seem to be two kinds of contractors out there. Type one will push as hard as possible for you to design things in a way that makes it easier for them. To the point where there are all sorts of design compromises like a beam in the middle of your kitchen. The second type is the one who wants to deliver exactly the vision of the client, to the point where they are adding a huge amount of complexity to perfectly meet unreasonable demands.

mcdonje 4y ago

His org used jira but not confluence? Why couldn't they just document these things in confluence? Edit: This is a serious question. What is that value prop of backstage over confluence?

1123581321 4y ago
Structure of the data and more pleasant/immediate workflow increases adoption so it doesn’t go stale, like Confluence so often does. Some teams need those nudges more than others due to personality, turnover, speed of growth and complexity of service architecture.
skrtskrt 4y ago
backstage has plugins that can help with autodiscovery of a lot of this stuff. The stuff that's not autodiscovered can live right next to your code, in any repository, so devs can just update some YAML keys when they're making other changes. You can lint the backstage changes as part of PRs Also I've never ever seen developers consistently keep stuff up to date in Confluence. There's just so much friction in that interface.
- mcdonje 4y ago
  Auto-discovery does sound appealing. Thank you.
rdonovan 4y ago
Author here. We did use Confluence, but as other folks had said, it went very stale. Not everyone could edit everything and there was no structure. Confluence is a mess in my experience.
- WesleyJohnson 4y ago
  Have to agree. Without a clear set of standards on how to structure things, it ends up being chaos very quickly. We had a PM for a while, who gravitated more towards QA, and when they got ahold of Confluence they went crazy (in a mostly good way). We had so many great "How To" articles on how to perform various tasks in our system form an internal user perspective, all authored by the same SME. Unfortunately, given their affinity for testing things, the How To docs starting taking on that QA perspective and everything ended up in a QA "space". Sure, it's easy to move them around, but there wasn't a clear cut way on how to separate the "How To" from the "QA" - and then they left. Since then, people add things when managers say "make sure that's in Confluence" and it ends up getting placed in the areas they're most familiar with, not necessarily where it should be. Add in the aforementioned lack of standards and no two documents look the same. Then we started using Confluence for devs to write Test Plans and QA to execute them - and now it just makes my brain hurt whenever I have to go in there. Some of it is a cultural problem: we're email and Teams heavy and so much of our "documentation" is buried in those tools. So then we adopt something like Confluence to move our knowledge base to that, but finding stuff in Teams is a nightmare (posted in another thread on that). So now rather than having one tool to rule them all, we just have another half-baked attempt. We're monolithic for the most part, so I'm not sure Backstage would help us, but the article mentioned Stack Overflow for Teams, so maybe that would? (insert relevant XKCD here on competing standards)

bdwalter 4y ago

(Shameless plug) Cofounder of OpenContext.com here. We're a bit different than a developer portal or services catalog, we're a complete context graph of all the assets in your product pipeline. Everything from products, documents, microservices, codepaths, vulnerabilities, people, teams, etc and the relationships between them. The complete context for DevSecOps. Check us out.

ralphael 4y ago
No need to apologise, a polite "I ran X which solves Y" related to the post is encouraged. Helps the rest of us learn about other solutions out there :-) Will checkout OpenContext, thanks for the link

qbasic_forever 4y ago

The real gem highlighted by backstage is the MkDocs Material theme: https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/ It's seriously awesome and has a lot of nice customization options. Out of the box it makes very clean and professional technical docs from a pile of markdown files. Even if you don't need to go the whole backstage route, seriously consider using mkdocs and the material theme.

deleted 4y ago
[deleted]

powersurge360 4y ago

I am becoming increasingly skeptical that good internal documentation is even possible. I've been working in software development for around 12 years and have _never_ seen it done well and asking around the best I've heard offered up is the equivalent of an internal stack overflow. For a while, I thought that maybe an exception would be having a technical writer on staff but after reading this post I'm significantly disheartened on that front too. I'd be interested to hear if anyone on hacker news has experienced good internal documentation and even more interested if any of you folks have experienced anything truly _great_. For my contribution, I've found that documentation fails for a couple of reasons. The first is the burden of correctness. The people who most would like documentation are also the people who most need the documentation and they usually are also the people most likely to be reluctant to contribute to the documentation because they don't feel they can accurately represent the information. Imagine someone ramping into a feature and spending a few days reverse engineering how it works, collecting info, etc. Sometimes they'll put it up somewhere but a lot of the time contributing partial information feels 'wrong'. And the second bit I find to be a big reason why documentation efforts fail is just the sheer friction of putting it into the documentation store to begin with. In confluence, for example, if you have a bit of information it can be tough to work out how to categorize it, where in the hierarchy it should go, etc, etc. Or if it's a GitHub wiki you want to put it somewhere that it is discoverable but also be careful that it's 'correct' because you don't want to break backlinks if it gets recategorized. I've mostly given up on it at this point. Instead, I take detailed personal notes and make them publicly available. It doesn't have to be correct because being advertised as personal notes means that it's my opinion on the truth rather than objective fact. It isn't far away from my codebase, I can just tap a short keybinding in my editor to type my notes or search them and I can link directly from the notes to lines of code in files to jump back and forth. The particular system I use means that if I write a short snippet of code to solve a one off issue (like calling a path helper to derive a URL that I can't find in the interface) I can even drop it in a code block and execute it right from my note-taking tool. It isn't ideal for sure but I've gotten way farther in having a shareable knowledge base this way than I have in literal years of trying to get a shared, useful documentation store spun up.

austinwade 4y ago

kenrose 4y ago

> So when I had questions, I needed to track down who owned the service, where their code lived, where their Jira ticket project was, which Slack channel they lived in, and where in the wiki their internal documentation was. Keeping track of this for 100+ services was a pain, so I ended up creating a spreadsheet. It turns out that everyone else in the org needed this information, so this spreadsheet that I created for myself became the document of record for services. 100%. Solving this problem is why I started OpsLevel [1] a few years back. Everyone always starts with a spreadsheet because they're flexible. But spreadsheets quickly fall apart because they're not complete / up-to-date, automated, or really scalable. We figured we could automate a whole lot of collecting service info from different places (Git, k8s, other deployment streams) and keeping it up-to-date. [1] - https://www.opslevel.com https://www.opslevel.com

chime 4y ago
I got interested in OpsLevel immediately upon reading your comment but was disappointed to find out that there is no public pricing and I have to contact for a demo. That goes from Cloud SaaS to Enterprise territory. Maybe some day we will grow enough to give you a call but your post made me realize we should definitely look beyond spreadsheets to document and manage our infrastructure. Thank you and hope you open up your pricing and trial accounts in future.
- kenrose 4y ago
  Thanks for that feedback re: pricing and demo. It's always a tricky balance, but I definitely sympathize with the feeling of just getting started without having to talk to a salesperson.

corwinstephen 4y ago

Unrelated to the discussion, just wanted to comment on Backstage's tagline: “Build an ecosystem, not a wilderness" which is ironic because a wilderness is arguably the most complete and perfectly functioning ecosystem you're gonna get.

lgrebe 4y ago
i like that thought. What would be a more ideal pair then? Build a wilderness, not a parking lot
- codingdave 4y ago
  "Build an ecosystem, not dystopian sprawl"
- lazyasciiart 4y ago
  Create a garden, not a wilderness. OR (depending on your audience) Build an ecosystem, not a garden.
- georgeoliver 4y ago
  An ecosystem, not a Superfund site.
- grangerg 4y ago
  Build an ecosystem, not an experiment. Build an ecosystem, not a science project. Build an ecosystem, not a microbiome.
- SerCe 4y ago
  "Build a universe, not a multiverse" could capture the meaning pretty well, in my opinion.

robbyking 4y ago

Is there a term for this phenomenon, my dear Watson?

BannedInSweden 4y ago

The main problem with Backstage (BS) is that while it does provide some canned functionality, any extension of that functionality requires the utilization of their plugins system and wholesale buy-in to their ecosystem. Welcome to Wordpress for enterprise developers folks! The plugin system isn't bad - but its a false narrative to believe you plunk this down and get some sort of valuable developer portal at an enterprise level (small biz sure - fortune 500...yeah no). Spotify does open-source a number of their plugins, but after having looked extensively at which ones they make available and which ones we would have to write (and deal with their plugin system for) we opted out. The cost/benefit ratio is definitely there for a technical writer, but IMO its not there for serious development. (Pls - Anyone who disagrees with that - begin by telling me why you don't use Joomla as a base for all your custom applications ) Team integration at a company level is another challenge with Backstage. GitHub (the basis and sort of harvested DB for BS) is largely disconnected from company structures and AD and all the things for most companies. Yes GitHub enterprise is a thing... no in general its still not connected to company structures. There are teams in Backstage, but they are generally managed in isolation from the rest of the company which presents its own challenges and integration problems with other systems. Don't even get me started on the fact that asking everyone to put their service defintions in specific files in specific places in GitHub is no better/worse than making them enter it into a ui or spreadsheet or confluence article or anything except now its scattered in 10,000 repos - good luck getting everyone to change that. Ultimately this isn't software that you simply install and use. Its a base that will likely require extension, and doing so means going down a one way path of adoption. Nothing it does is compatible with anything else. Is that good for Spotify - sure. Lots of folks helping build software they want to use is great. Is it good for the community? I'm not so sure. This article felt like a paid add (not suggesting it was - just saying it read like one) more than an honest plus/minus of the software and is anyone really surprised a technical writer couldn't build a proper enterprise developer portal by themselves? In other news - water is wet, the sky is blue and my kid wants to watch youtube.

Melatonic 4y ago
So what do you recommend then instead?

NonNefarious 4y ago

Backstage is a well-known entertainment-industry site and publication. What's the motivation for trying to duplicate it?

qbasic_forever 4y ago
They're... not? "Backstage" is a noun. It's a place. It so happens some entertainment industry publication uses it as a name, and a piece of software that is totally unrelated also use it as a name.
- NonNefarious 4y ago
  It's capitalized in the title, so it's a PROPER noun. And I've worked in software development for a long time, and have read HN regularly for a long time, and I've never heard of "Backstage" as software. There's a wide world out there, which some HN posters "forget."

gregw2 4y ago

Has anyone done this sort of thing for data, not just for services? I can't seem to find a data catalog that lets my tie information across databases + APIs + Kafka topics. Each catalog of schemas is separate with no way to link them really.