# Backstage demo

## Overview

[slides](https://remarkjs.com/remarkise#1)
- Spotify had a large spike of growth a few year ago
- they were able to hire a lot of developers very quickly
- but their onboarding lagged behind
- it was taking developers longer and longer to get anything done
- They did a survey with their developers and found the biggest pain points were
- context switching and
- the amount of undocumented institutional knowledge that people need to get things done
- There are three core challenges that a platform must address for developers:
- The first is we want to help developers build quickly while passing on knowledge.
- The second challenge is helping developers maintain a mental model of systems their team owns.
- The third challenge is helping developers keep an eye out for things to reuse.
- Spotify reduced software development in their org down to three jobs to be done:
- create
- manage
- explore
- They created an internal developer portal organized these jobs and open sourced it for other people to use.

[create](http://127.0.0.1:3000/create)
![[Screen Shot 2021-08-12 at 2.41.14 PM.png]]
- The create job is facilitated with application starter kits.
- When you need to build a new application, you select one of the starter kits that your org has created, and it generates a repository following the standards set by that organization.
- In the case of Lighthouse, our team is buiilding a Java starter kit that produces a hello world application that can be deployed immediately to a kubernetes infrastructure.
- So out of the box, developers get an application they can start experimenting with that deploys, scales, includes testing infrastructure.
- It puts the developer in a state where they can immediately focus on value adding work- their application logic. No fiddling with infrastructure configurations. no talking to a devops person about terraform.
- starter kits can make the right thing easy for new developers and streamline (but not replace) onboarding
- this embodies self service in that that developers don't have to manually set up their own infrastructure or ask a lot of questions about engineering practices to start building value adding applications. they can start from scratch and go through the entire development and deployment lifecycle in a few minutes

[manage](http://127.0.0.1:3000/catalog/default/component/wayback-search/)
![[Screen Shot 2021-08-12 at 3.19.32 PM.png]]
- Once an application is added to backstage either through the starter kit or by manually adding it, then backstage can show a summary view of application
- The intent is to provide a single pane of glass about the current state of the application including information about its deployment, it's operational state, documentation and specifications for how to use it, provider / consumer relationships, and points of contact for questions.
- This supports developers understanding by providing a mental model of the applications they manage.
- Each tab is a react app and there is an infrastructure to keep plugins decoupled. This enables teams to contribute to their own developer experience by adding plugins to the backstage instance. At spotify only about 20% of the plugins in their instance of backstage are built and maintained by the core backstage team. This embodies self service in that core maintainers are not a bottlenecks for new features in backstage.
- one of the plugins available is TechDocs (no demo for this but we are [deploying](https://department-of-veterans-affairs.github.io/lighthouse-backstage/) our techdocs to github pages for now)
- Tech docs is a documentation in code generator. so all documentation about a service or an application is inside of the code and is deployed with application. High proximity promotes keeping documentation up to date. Features like plantUML rendering allow developers to define diagrams as code.
[api docs](http://127.0.0.1:3000/catalog/default/api/wayback-search/definition)
![[Screen Shot 2021-08-12 at 3.38.55 PM.png]]
- there's also a renderer for api specs which lets you try out services in the browser

[explore](http://127.0.0.1:3000/catalog)
![[Screen Shot 2021-08-12 at 3.36.56 PM.png]]
- All applications created and added to backstage are visible in the catalog. The catalog offers filtering and a summary of each application and links to the catalog entry we looked at in the manage screen.
[explore](http://127.0.0.1:3000/search?query=wayback&pageCursor=)
![[Screen Shot 2021-08-12 at 3.37.05 PM.png]]
- Discover and exploration are also facilitate by the search
- search is being actively developed by spotify- it supports third party indexing services like Elastic Search and provides complete control over what is indexed and how results are displayed

[plugin marketplace](https://backstage.io/plugins)
![[Screen Shot 2021-08-12 at 3.42.25 PM.png]]
- There is a marketplace of third party plugins we can use
- At this point we're not considering using any of these yet. A lot of them provide really basic value but new plugins are added all of the time

[some diagram with platform and backstage]
- How does backstage fit into a platform?
- Backstage is the first and primary place developers go to do their core responsibities: create, manage, and explore
- Backstage doesn't provide platform capabilities itself. Other platform teams build capabilities and expose them through backstage. The starter kit team is a good example- they're building a starter kit with a CLI but they're going to wrap it in a service (api) that will be integrated into backstage
- need some more stuff here

I want to include this stuff but it might not be relevant. I think Patrick will be interested in this though.
- Configurations for infrastructure are in code. So nothing about provisioning resources like databases or s3 buckets is available through backstage. we may provide some visualization of the state of their resources (i.e. this component is a consumer of this resource) but ultimately all of the functionality is driven by code
- We'll probably extend this pattern to other platform capabilities like API Gateway where developers define the state they want their application in and the delivery infrastructure makes it happen.
- Teams control their own CI / CD. So we don't care how they build their apps or what checks they do- we get a container and we run it in our infrastructure.
- ThoughtWorks encourages self service with the idea that the platform reports on level of adherence to paved path and does fleet management via automated PRs into repos. meaning if you change the way something should work in your starter kits, you give teams an opportunity to opt in to the new behavior by approving or adjusting an auto generated PR.
- Ultimately though you don't interfere in their deployment pipeline by adding checks or governance that blocks delivery. governance bottlenecks are discouraged
-