Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Happy developers make happy code: How Backstage Makes Developers Happy at Spotify
Similar to Happy developers make happy code: How Backstage Makes Developers Happy at Spotify (20)
Recently uploaded
Recently uploaded (20)
Happy developers make happy code: How Backstage Makes Developers Happy at Spotify
- 1. Happy developers make happy code
- 2. Himanshu Mishra @OrkoHunter Developer Advocate @ Spotify How Backstage Makes Developers Happy at Spotify
- 3. Backstage is an open platform for building developer portals. Created at Donated to
- 5. Trends like microservices, SaaS sprawl, and cloud-everything create a chaotic ecosystem for engineers. Every company uses different subsets of these tools and faces different challenges. Your whole stack is getting more complex; onboarding and collaboration are becoming more difficult. Software is still eating the world
- 6. Unifies all your tooling, services, apps, data, and docs with a single, consistent UI Makes sense of everything in your ecosystem, regardless of how and where individual components are running Let developers focus on what they do best (leading to much less activity in #aaargh Slack channel) A developer portal = one frontend for your entire infrastructure
- 10. Backstage lets any developer: ❏ Create new software in seconds, aligned to your best practices ❏ Manage all the software they own in one centralized location ❏ Explore the entire software ecosystem, enabling collaboration across your org
- 11. ❏ Manage the complexity of your growing org (100 million devs by 2025!) ❏ Manage the complexity of your growing software ecosystem ❏ Leverage the power of open source (all the tools via plugins, a world of support) Backstage lets any company:
- 12. Backstage has a customizable, extensible plugin architecture ❏ Built with modern technologies and common frameworks. ❏ Makes it easy to develop for and contribute to your dev portal. ❏ Cloud-agnostic and vendor- neutral.
- 14. Why open source?
- 15. A sustainable OSS model By building a developer portal on an open platform, you can: ❏ Leverage common integrations and best practices developed with the community ❏ Customize those integrations to suit your unique needs Backstage community Your company Contributions Contributions
- 16. Backstage is owned and led by a diverse, rapidly growing open source community. Stars on GitHub 15k Contributors (+10 per week) 800+ Adopting Companies 100+ Evaluating Companies 200+
- 17. Backstage is building a proven track record across industries And many more, including government agencies and big tech orgs with 100k+ developers
- 18. Demo
- 19. Behind the Curtain: Backstage Architecture
- 21. Key Terminology ❏ Core Base functionality built by core developers in the open source project. ❏ App An instance of a Backstage app that is deployed and tweaked. The app ties together core functionality with additional plugins. The app is built and maintained by app developers, usually a productivity team within a company. ❏ Plugins Additional functionality to make your Backstage app useful for your company. Plugins can be specific to a company or open sourced and reusable.
- 22. Core Philosophy ❏ Backstage is the interface ❏ Aggregator, rarely the source of truth ❏ Autonomy ❏ We build it together; no big central platform team ❏ The team closest to the problem owns the plugin ❏ Ownership ❏ There should be a single point of contact for any software ❏ These owners are empowered and responsible for metadata
- 23. The Software Model ❏ Core entity kinds ❏ Domain, System, Component, API, Resource, User, Group ❏ For each kind, many types ❏ Service, Website, Library, OpenAPI, GraphQL... ❏ Relationship graph ❏ ownedBy, providesApi, memberOf, dependencyOf... ❏ Annotations
- 24. Getting Declarative: catalog-info.yaml ❏ Lives with the source code (GitOps) ❏ Uses the Kubernetes object model ❏ Extensible ❏ Optional, there are other ways
- 25. Example: catalog-info.yaml apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: petstore description: The Petstore is an example service that provides an OpenAPI spec. links: - url: https://github.com/swagger-api/swagger-petstore title: GitHub Repo icon: github spec: type: service lifecycle: experimental owner: team-c providesApis: - petstore-api
- 26. Encouraging Consistency: Software Templates ❏ Encode your org’s technical best practices ❏ Also automatically register new software ❏ Artisanal, hand-crafted yaml not required
- 28. What’s a plugin? ❏ Backstage is built to be extended ❏ Customize for your infrastructure ❏ Plugins are npm packages ❏ Frontend and backend plugins ❏ Core features are plugins too!
- 29. What’s actually in Backstage core? ❏ Reading data from external sources ❏ Connecting to data stores ❏ Connecting to external services ❏ Base entity kinds ❏ Config reading ❏ Common CLI ❏ Material UI theme
- 30. Simpler Catalog Extensions: CI/CD ❏ Often frontend-only, React components ❏ API calls proxied to underlying services ❏ Catalog annotations inform how to pull data User UI Internal User Browser Proxy Circle CI Circle CI Plugin
- 31. Deeper Catalog Extensions: Documentation ❏ A service unto its own, with a Catalog interface ❏ Leverages core config / external read capabilities ❏ Catalog annotations still informative TechDocs plugin TechDocs Backend plugin Caching (optional) TechDocs recommended deployment architecture Cloud Storage Request TechDocs site CI/CD System Build docs and store generated static content techdocs-cli Repo 2 (with docs) Repo 1 (with docs) New commit New commit Fetch files to render
- 32. Extending Backstage Itself: Search ❏ Not everything revolves around the Catalog ❏ “Batteries Included” mentality ❏ Service-to-service communication with other plugins
- 33. Deployment
- 34. Service Catalog Plugin Lighthouse Plugin Tech Radar Plugin Proxy Service Catalog Backend Circle CI Plugin Lighthouse Backend UI User’s Browser Internal d s DB d s DB Circle CI A true platform, inside and out ❏ A small team maintains the core features of the Backstage app ❏ Different platform teams build and maintain all the other plugins ❏ Feature teams use the plugins to build and maintain their software (and provide feedback directly to the plugin owners)
- 35. Adopter Deployment Strategies ❏ Manual Kubernetes deployment ❏ Helm charts ❏ CDK / Fargate / Aurora
- 36. Where do I start?
- 37. 1 2 3 4 1 TRY 2 POC 3 PARTNER 4 EVANGELIZE 1. Try it into your laptop Create your app and play around! (Less than 1 hour) 2. Connect with your service This part requires development (A few weeks by 2-5 devs) 3. Start small (but strategic) Partner with a feature or core service team on a narrow but high-value use case (1-2 quarters by 2-5 devs) 4. Spread the word! Evangelize and build your expansion/ adoption strategies (Ongoing by 2-5 devs)
- 38. Great resources Case studies, explainers, and one-on-one demos: backstage.spotify.com Community Sessions: github.com/backstage/community Discord: https://discord.gg/MUpMjP2
- 39. Positioning the investment to internal stakeholders Taking Backstage from proof-of- concept to production Referring to trusted partners to help you get up and running Spotify is here to help
- 40. Questions?
Editor's Notes
- Backstage is an open platform for building developer portals. It was created at Spotify and open-sourced in March 2020. Since open sourcing it, Backstage has become an Incubated project at the Cloud Native Computing Foundation (home to Kubernetes and Envoy).
- Let’s back up a second and talk about Developer Portals. It’s a fairly new product category, so it’s good to spend a bit time to explain what a Developer portal is and what it isn’t. (Backstage can also be considered what’s known as an IDP — an internal developer platform. We won’t make a distinction for our purposes here.)
- Software is still eating the world, there is an explosion of available technologies. As a result, it’s difficult to learn them all in depth, keep track of how it fits in your stack and learn their interfaces/languages/portals. Your whole stack is getting more complex, and things like onboarding and collaboration can become more challenging
- A developer portal is more than an intranet for devs. It’s more than just a service catalog. A developer portal is one frontend for your entire infrastructure, integrating: Tooling — CI/CD, Kubernetes monitoring, security tools (Snyk), testing (Lighthouse), etc. Services/applications/data — basically, all the software/data that your teams build and manage Docs — For components, APIs, etc.…as well as tutorials, guides, org charts, strategy docs, etc. All in one place, regardless of how or where the individual components are actually running, or who manages them Let developers focus on creating that feature, keeping your business running, and learning new things, instead of using numerous portals to perform that one basic task. ----- [OTHER WAYS TO DESCRIBE IT] A single pane of glass, whether it’s a tool from your cloud provider or proprietary tooling that you built in-house to integrating with Jira, Confluence, Stack Overflow, etc. It’s a centralized, streamlined operating environment for your whole engineering org.
- Every development shop wants roughly the same things: Speed without compromising Safety Scale without compromising Quality And the ability to tame their increasingly chaotic software ecosystem Spotify is no different.
- If we at Spotify were able to to tame our chaos and improve developer effectiveness with Backstage, we think it could work anywhere.
- Let’s go back to the year 2016 Spotify was in hyper-growth mode (expanding from a music streaming app to a highly personalized audio experience). But onboarding new engineers was becoming hyper-confusing. They were focused on speed-to-market. Yet their teams were slowing down because of internal fragmentation. While their headcount kept going up, their individual developer effectiveness metrics kept going down. Specifically, they measuring the number of days new engineers took to get to their 10th PR, which was skyrocketing to 60 days. Spotify built this developer portal — what you now know as Backstage — to tame the chaos. And that changed everything — aligning a distributed, autonomous culture, and bringing together hundreds of squads, thousands of engineers and tens of thousands of software components. Backstage at Spotify now enables better collaboration, unlocks collective potential, and empowers teams to do what they do best.
- There are a lot of features to Backstage, but these are its 3 main “jobs to be done”. [READ THE CREATE-MANAGE-EXPLORE BULLET POINTS] Instead of being frustrated by infrastructure, your developers get back control over it. Frees them up to focus on what they want to focus on (building features, etc.).
- Your engineering org consists of both software and people. The global developer population will grow massively the coming years, and we believe this will also be true for your organizations’ developer population if it isn’t already. You’ll need to handle this growth of both people and complexity Ideally, you can leverage the power of Open Source through plugins, and the world of support from this fast growing community Backstage will help you manage this.
- Backstage is powerful, largely because of its highly extensible plugin architecture. Plugins are essential additional functionality to make your Backstage app useful for your company. Plugins can come from anywhere — internally from your teams or externally from the Plugin Marketplace. Plugins can be specific to a company or open sourced and reusable. With Spotify’s Backstage, it has been very powerful to get contributions from various infrastructure teams added into a single unified developer experience. When we open sourced Backstage, we focused on making it open to build for, so that it’s possible to make it work for different organizations. You add functionality and integrations to Backstage by either adding or building plugins for it to tackle challenges specific to your organization. We’ll cover plugins more deeply later as we peek behind the curtain on the Backstage architecture.
- The internal version of Backstage at Spotify looks like this, you can probably spot some plugins. You can tailor this to your own branding and visual likings, in fact, we see many adopters being creative in both naming and branding.
- The teams at Spotify depend on their internal version of Backstage every single day. It’s considered mission-critical to their company. They believed the best way to ensure its future here was open sourcing it. In other words, to ensure they could keep relying on it in here at Spotify, they needed it to become the standard out here in the world.
- While the famous quote “software is eating the world” is still true, Software itself is being eaten by Open Source. Proprietary software is being replaced by Open Source alternatives, because companies see the advantages of using Open Source Software, like: cost-and-time savings, efficiency, etc. Also, because of this, traditional Open Source companies are playing a less critical role. Open Source innovations now happen at companies like Google, Facebook, and, well...Spotify. It can also play an important role in attracting and retaining talent. Your Developers will value: Collaborating & Interacting with a large, healthy, community Continuous community Support The ability to contribute to the project directly, or by creating plugins In turn, your contributions could be improved or extended by other community members, which will accelerate your organizations innovation.
- We love these numbers. The interest from so many companies show us that it’s not just Spotify — there’s a real need for developer portals and a product like Backstage. And the continued growth in external contributions shows us that it is working as a platform — that it will continue to scale and evolve and improve as adoption grows.
- Backstage is building a proven track record across industries. We’re continuing to see more and more great companies adopt Backstage. Here’s just a few that are doing awesome things with Backstage. And if you ever decide to adopt Backstage and feel comfortable sharing this, we’d love to see you on our public adopters list
- Before we dive into the architecture, let’s take a look at how Backstage looks.
- [GO INTO THIS SECTION IF TIME PERMITS FOLLOWING OVERVIEW] [SKIP DIRECTLY TO THIS SECTION IF AUDIENCE DOESN’T NEED THE OVERVIEW] So now, I’d like to take you a level deeper on the “how” and “why” Backstage works the way it does
- Let’s talk about some of the key concepts and philosophies behind Backstage. And these concepts have really matured over the years at Spotify. We’ve come to these conclusions over time.
- Backstage is constructed out of three parts. We separate Backstage in this way because we see three groups of contributors that work with Backstage in three different ways: Core: Base functionality built by core developers in the open source project. App: The app is an instance of a Backstage app that is deployed and tweaked. The app ties together core functionality with additional plugins. The app is built and maintained by app developers, usually a productivity team within a company. Plugins: Additional functionality to make your Backstage app useful for your company. Plugins can be specific to a company or open sourced and reusable.
- INTERFACE: One of the core philosophies is that Backstage is the interface, it's really an aggregator. You're undoubtedly going to have many infrastructure tools. And you want to expose all those tools through the same interface, but we're not looking to reimplement them. CI/CD is a good example where you want to show the status of your build. But if you want to go off and troubleshoot the build, it's probably better to launch into the external system. Otherwise, you have to reimplement the whole thing in Backstage, which doesn't really make sense. So we're really looking to give you that single pane of glass, that single place to go to check on everything from which you can get to the other tools if you need to. So Backstage is rarely the source of truth, we're aggregating information from other external source systems. And that makes it a lot more flexible, and easy to adopt, because you're not replacing everything in your infrastructure, you're just adding a layer on top of it, and that layer that brings it all together in a single interface. AUTONOMY: Now at Spotify, we have this culture of autonomy. Basically each team is able to operate on its own and make the best decisions for themselves. So we knew when we started Backstage, we couldn't have a big central platform team that dictates everything from the top-down and implements the whole platform for everyone. So Backstage was really built around this plugin mechanism as a way for everyone to build it together. Internally, we have a team of 4-6 people managing our internal deployment of Backstage at the core. And then there's over 150 plugins contributed from over 100 other teams who own that domain of expertise. So the plugin for the build system that shows the status of current builds is provided by the team that owns the build systems. Or for data pipelines, there's a plugin that shows you the status of data pipelines, and that's owned by the data team. And that really works well for us, for our culture, and we’re finding that virtuous cycle is working for other adopters as well. Not only can you grow so much faster, because you’re not relying on a single team to develop all these things and running into resource constraints. Oftentimes, your team doesn’t have the experts in any given domain. So it's better for the team that owns the problem to be closer to it, and to build the plugin offering for that. OWNERSHIP: Similarly, with a Software Catalog, for each piece of software at a company, we believe there should be a single point of contact for that software. And they should be the owners of the metadata around that piece of software. The team that wrote the software should decide if it's production-ready or still experimental, for example. You should be able to declare what kind of dependencies you have on other pieces of software at the company. So we really follow this GitOps model (we'll talk a little bit more about later). But it's really about putting ownership in the hands of the teams that own the software, and not trying to build a central place of ownership.
- CORE CONCEPT: So we've let talk about the software model that's used inside Backstage. As we’ve said, we developed it at Spotify over time but we find that pretty much every company fits into this model in some way. One of the primary things we're tracking are software components: source code for a service or a library or a website. And then those components may belong to systems which may belong to domains. These are kind of going up higher and higher into the stack. So if you think of a system, it might have a certain service that's deployed, it might have a memcache instance, it might have a database related to that — these all comprise one single system of functionality. And the software components can provide APIs, they may rely on low-level resources, i.e. a load balance or a database, all things that are tied into a service. And you can distinguish those types a bit further: an API might be open API, it might be GraphQL, or something else. So we have a type specifier, that allows you to distinguish a little bit what a particular thing is. And then we also track by means of ownership: users and groups in the catalog. So you can look at a piece of software and know who owns it, what team it lives in, what business unit they are part of, etc. Then most importantly, you want to track how these things relate to each other: Who owns this piece of software? What APIs does it provide? What groups is this user a member of? So we want to build this whole software graph in order to make sense of all the software at your organization. Additionally, there are annotations. As you'll see in a second, we follow the Kubernetes object model for defining software. And annotations are a way to add more information that Backstage doesn't necessarily need to know about.
- So the way the Backstage works at Spotify — and if you're starting from scratch — is you define these yaml files that live alongside your software following the GitOps model “declaring things in the source sources truth.” And these use the Kubernetes object model format just for the yaml file format, they're extensible through annotations so you can add your own custom fields if you need to. But, truthfully, these yaml files are optional. Plenty of looking to adopt Backstage didn't want to go out and define yaml files for hundreds of services before they could start to see the value out of their developer portal. So there are other ways to get your software into the Catalog. You can also create custom processors that ingest other definitions for your software, for example.
- This is what a typical catalog info looks like for Backstage. It should be very familiar if you're used to Kubernetes: You have your kind, which in this case, is a component The spec-dot-type for this is a service You can see lifecycle, the owner, etc. And then there's soft links for the relationships (this says that it provides the pet store API. And you can define some other interesting things here).
- So then with Software Templates, as you saw, you can basically bake in your org’s best practices. You can kind of continuously update these over time and these automatically get registered in the Catalog when you build new software. This way, you don't have to create that yaml yourself, it's automatically included in the software template.
- As you saw in the demo, the power of Backstage is in its extensibility and customization. We’ve seen that power firsthand and wanted to share more on some of the common patterns that we've seen operating Backstage internally at Spotify as people have extended it.
- So what is a plugin anyway? When the rubber meets the road, a plugin is actually just an NPM package. A pile of TypeScript or JavaScript that gets bundled and is available through an NPM, you'll see a bunch of these packages on NPMJS.com prefixed with @backstage. As we mentioned before, our internal Backstage team is only 4–6 engineers. But we have over 150 plugins, which were built by teams across the company, according to their expertise (Kubernetes, security, data pipelines, etc.) Plugins can extend backstage both from a frontend perspective and a backend perspective. On the front end, you'll see like React components that can be, for example, mounted to routes to show different panes of information. They can be API definitions for reaching out to services, etc. And then on the backend, you can typically connect the Backstage frontend to some other service running somewhere else. A lot of the core features that you saw in the demo are actually plugins, the Catalog itself is a plugin (or a series of plugin, some frontend, some backend), Search is a plugin, the documentation view that you saw is a plugin.
- So everything that you just saw is a plugin, what's actually in the core at all? A lot of things you'll see on this list is because Backstage is like a web framework of sorts. So a lot of the common things that you see in web frameworks, you'll see represented in Backstage core as well, like configuration management, having a CLI to be able to build and bundle things in a standardized way so that people don't think about it, connecting to data stores, etc. All the while, providing like a nice, consistent UI Some of the “secret sauce” that we've put together over time, are packaging up some of the core concerns that a lot of plugins tend to have. And one of the most important ones is just being able to read static information from external sources. All those catalog info.yaml files being used in the Git Ops model live in Version Control somewhere. And adopters can choose whatever version control system they want. So we need a standardized interface to be able to connect to GitHub or GitLab, or Bitbucket, or the enterprise versions of all of those things.The core provides plugins via one nice, easy interface to power the experiences they need to power and one configuration interface for adopters to be able to hook it up and go very quickly.
- In terms of what we've seen, the most obvious pattern is like that CI/CD extension and being able to see the builds. And sometimes it might be GitHub actions, maybe it's a Circle CI, maybe it's a custom-built thing on top of Jenkins internally. But for a lot of those, going back to that “Backstage as the aggregator” point of view, it's really just a lightweight interface into an existing service. Backstage actually provides very easy proxying mechanisms. You could just have a frontend plugin that provides the components to show the view of builds, for example. And it just makes the connection to the Backstage backend that gets proxied out to the actual underlying service somewhere else in the cloud or whatever you’re running on. The way that each of those entities in the Catalog are connected in the UI is through those annotations, where we can put a little bit of extra arbitrary metadata, i.e. “this component in the catalog gets built with Circle CI, and the slug through this particular component is X slash Y.” The frontend plugin grabs that from the Catalog, proxies the request through the backend to CircleCI and powers that frontend in that way.
- A different pattern that we've seen internally — Having run Backstage at scale for a number of years — is that, oftentimes, you'll end up in a situation where existing services are lacking. We found this out when we were building a documentation solution for ourselves. What often ends up happening is an entire service ecosystem gets built up to solve a particular problem and then the only UI on top of that service is Backstage. Rather than having to build out a custom centralized website where all documentation lives, we already had this software catalog where everything that anyone worked on existed. And all we had to do was build a little tab off to the side for a particular component to be able to show documentation for that software component. In the diagram, you can see all of the sort of complexity behind the service. And then Backstage is really just the the UI layer on top. So with the technical documentation, our philosophy was docs-like-code like Git Ops where the documentation itself also lives in source control next to the component itself, and the component yaml. And so we also leveraged that core reading data from VCS to power our documentation solution.
- And finally, in a third big pattern we see, we've been speaking a lot about extending the Software Catalog and the software catalog is very important. But not every extension of backstage is an extension of the Software Catalog. A good example of this is Search. In the demo, you saw that you can search for individual entities in the Software Catalog and you can search for pages and paragraphs of documentation corresponding to all of those things. Because plugins are effectively just NPM packages that you can connect together using a core plugin API, you can effectively, do whatever you want. Search is an interesting one, too, because Backstage tends to have this “batteries included” mentality, we want you to be able to get up and running very quickly. So the default search engine that you get with Backstage is actually just an in-memory search engine. However, we recognize that that's not going to scale for most organizations. So we — like most things with Backstage — make that extensible as well supporting different search backends, like Elasticsearch or even Postgres, for people who don’t necessarily want to maintain that much bespoke infrastructure for their Backstage instance with one database instance, one backend, etc. Finally, with Search, because we’re built on plugins extend other plugins, the plugins are very separated from each other being their own packages themselves with their own API Interfaces with service-to-service communication is well-defined over HTTP. That keeps things flexible and decoupled in a way that helps scale Backstage.
- So how do people tend to deploy Backstage?
- As a platform, Backstage needs to be able to scale within all kinds of companies (big, small, or massive — or “small now but growing ridiculously fast”). Ownership in Backstage at Spotify works like this: — Core Backstage team owns the platform. — Platform experts own their individual plugins. — Feature teams own the software they create/maintain using those plugins. With feedback loops and contributions between all these groups. Backstage, as a whole, isn’t a particularly opinionated on how its deployed. We have adopters using a variety of strategies. When you build Backstage, ultimately what you get is a Docker image that can be deployed, however you like.
- So you can do it manually through Kubernetes and Kubecontrol You can create a Helm chart, we have a Backstage Helm chart in our concrib folder in the open source repo Or you can even go so far as to deploy CDK and Fargate and Aurora Our philosophy is the best way to deploy Backstage is the way you deploy everything else; it’s designed to fit in your infrastructure as a tool and we don’t want you doing something unusual and bespoke just for Backstage, it should follow the same deployment mechanisms that you use for everything else
- “Backstage sounds great — but I have 20 bazillion software components running in production and docs spread out across Confluence, Google Docs, and who knows where else. And I’m onboarding new engineers every week” We get that! So where to start? Start with a focus on that one problem you’d like to solve with Backstage. We recommend starting with a narrow use case and ratcheting up small wins as you go. Get to know the product, learn to navigate our community - spread knowledge internally as you go.
- There are a lot of features to Backstage, but these are its 3 main “jobs to be done”. [READ THE CREATE-MANAGE-EXPLORE BULLET POINTS] Instead of being frustrated by infrastructure, your developers get back control over it. Frees them up to focus on what they want to focus on (building features, etc.).
- Here’s a few good places to start. First and foremost, get involved in the community through our Community Sessions, on Discord, and on GitHub. We’ll be adding more and more resources to the backstage.spotify.com site as well [PASTE IN CHAT] Case studies, explainers, and one-on-one demos: backstage.spotify.com Community Sessions: github.com/backstage/community Discord: https://discord.gg/MUpMjP2 Backstage Newsletter: https://mailchi.mp/spotify/backstage-community
- And, of course, as the original adopter, Spotify is here to help. It’s still new, but we’ve had over 18 months with Backstage in the wild. We’ve helped a lot of companies now, all a little different — and the more companies we talk to, the more we build up knowledge, experience, and best practices around adoption. We want to share that knowledge wherever we can. And, we have our trusted partners who can help you get up and running.