Product vision and problem analysis

Backstage is an open platform that can be used to build developer portals. It is used by companies to give developers a platform that can store information about their tooling, data, software components and documentation. It aims to give back control of the infrastructure to the developer. Backstage does this through three main elements: a software catalog, software templates and a documentation platform (TechDocs).

The software catalog is used to manage all of the company’s software. These may include: ML models, websites, data pipelines, microservices and libraries. The software templates are used as boilerplates to quickly create new project and standardize tooling that is used within the organization. Furthermore the documentation platform is used to keep track of the documentation of the components that make up your service’s technical documentation. Additionally Backstage can be extended by implementing open source plugins.

In essence Backstage can be viewed as a UX layer on top of the infrastructure behind a service. It is an abstraction of what is happening on a technical level. The challenge with Backstage is the scope of the project, which is extensive.

Key domain concepts

Backstage boasts it can unify the developer workflow within big developer teams. For big developer teams ad-hoc solutions to collaboration and knowledge sharing becomes a problem. Within software organizations this becomes apparent for teams of 100+ software developers. To solve this Backstage focuses on three focus points.

Create

Allow developers to easily create software that fits and integrates into the organizations existing software architecture. For example Backstage has so called “templates” which allow developers to easily setup Git, reservation of production resources, CI/CD setup, etc…

Manage

Developers should be given the tools to easily manage their tools in a unified way. Backstage eases the process of monitoring applications and managing dashboards in a central place. Some default tools Backstage provides are integrations with cloud consoles, security dashboards, CI interfaces and more.

Explore

Onboarding new developers and sharing documentation is eased using documentation tools. Documentation for the tooling is put in the same place as the dashboards of the software services. This allows for new employees to easily get up to speed exploring current services, and the organization to share knowledge.

Use cases

Thus, to achieve all these focus points Backstage provides developers a “Software catalog” where developers can easily see all services an organization is running. Furthermore, the software catalog standardizes the way dashboards look and instantly provides authorization to management tools and documentation.

Current and future (external) context

In the context view we can see a couple of boxes, which represent the groups of entities that Backstage interacts with. As Backstage offers a central control point for all software services, allowing for good cooperation in teams working on different parts of a system, the current context in which the system can be used is in any software company consisting of 20-1000+ developers. The main developers and users of Backstage are the teams of software engineers working at Spotify.

Currently, an estimated 1000 developers are working together on the same system at Spotify using Backstage for organization in order to keep the system well maintained and integrated as well as cleanly documented.

Most of the external and future context of Backstage can be represented using integrations called “plugins”, Spotify has an internal installation of Backstage that has over 100 different integrations. These integrations are created without having to modify Backstage, thus external systems can be integrated into Backstage without having to make big changes, allowing its current context to quickly be expanded.

A part of the future context is further extension of the ecosystem in which plugins/integrations are readily distributed to allow users to pick the tools that match their stack, which is currently available at https://backstage.io/plugins.

Stakeholder analysis

Backstage is a platform that is used company wide, and within a number of companies. This creates a high number of potential stakeholders. The main stakeholders that can be identified are the following: companies, platform engineers, end-users (developers at a company), engineering managers, contributors (developers who contribute to the opensource project), plugin developers.

The companies are the organizations who should benefit from using Backstage. An example of a big company that uses Backstage successfully is Spotify. They use Backstage to streamline the developer experience.

The platform engineers are a specific subset of users. They use Backstage to create an insight of the services being run within the company. They rely on Backstage as a platform to integrate external services.

The end-users are the actual developers within a company that use Backstage as a tool to help them with their engineering tasks. They rely on Backstage as a hub for information. They will not actively be connecting services into Backstage.

The engineering managers use Backstage to maintain standards within the organizations. This will mean that they will manage information about for example migration or certification. If Backstage operates properly, they should be able to create a cohesive ecosystem.

The contributors are part of the Backstage community and will make contributions towards the Backstage repository. Not only do they influence the development of the project, they also have a say in the product vision behind Backstage.

The plugin developers play a role in the ecosystems that surrounds Backstage. As mentioned, Backstage can be extended in functionality by integrating open source plugins. The plugin developers therefore play a role in shaping the ecosystem around Backstage.

Key quality attributes

As one of the main focuses of Backstage is “Allowing new developers to get started quickly, thus not requiring knowledge to be passed by mouth. Ensuring senior developers don’t need to get distracted”. The primary key quality attribute of the system is Learnability: allowing new users to quickly get familiar with Backstage.

The secondary key quality attribute is Ease of Integration as the aim of Backstage is to integrate all different aspects of the development cycle into one platform. This is achieved by giving users the ability to create plugins allowing users to integrate a new component without actually having to modify the system directly, preventing technical debt from having to be paid.

Roadmap

Interestingly enough, Backstage provides two clear distinctions between their roadmaps. One is for a current development cycle, which is 3 months long, contains a future work section where the proposed features are on the radar but not yet scheduled. And a second longer term roadmap for the next 12-36 months, which isn’t publicly available.

Current cycle

During the time of writing (March 2022), we have come at an exciting time. This current cycle plans the release of Backstage 1.0 which includes all the Core features, as well as the Catalog (the centralized system that keeps track of ownership and metadata for your software) and Scaffolder (the tool that helps you create components inside Backstage with the help of templates and TechDocs, which is a documentation solution built directly into the code).

Furthermore, on a organizational level of the project, they aim to do a Security Audit by a third-party to uncover potential vulnerabilities within the project. Lastly Backstage requested to be moved to the Incubation Stage of the Cloud Native Computing Foundation (CNCF). This means that the project is evaluated as more mature compared to its current Sandbox phase and it can be adopted by more enterprises.

On the radar

The project is looking to improve in the next iterations on various topics. The following list has been suggested:

• Improving the Backend Services, which makes it so the different modules can be decoupled from the frontend and Backstage instances can be scaled and maintained better
• Security Plan, the project plans to do this to mature the platform even further, making it more suitable for adoption
• Search 1.0, the Backstage Search still has some issues left until it can be fully released
• Techdocs Addon framework, improving TechDocs by implementing it with the Addon feature, which are added on top of the base docs
• Composable Homepage 1.0, finalizing the first version of this by adding some composable components
• GraphQL support, This will make it so the user can query Backstage backend services with a standard query language for APIs
• Telemetry, logging more data and metrics of the system so it can be improved upon
• Improved UX design: Create a more user friendly experience with the help of visual guidelines and templated

The community around this project would like to see these improvements in the near future, and they can be worked upon if so desired. That being said, the focus of the team this iteration is not on these features.

Ethics

The project itself is a great tool to manage different tools within a company environment. With this however always comes the need of authentication. This authentication has to be done in such a way that unauthorized users can’t influence the tools they aren’t suppose to be influencing.

Backstage itself solves this by using Third Party authentication providers. This means that the project itself does not store authentication of the services but rather the service will authenticate from within Backstage. By default, the application has zero authentication providers, which means only guest access is available. Within the Core Library there is an option to use commonly used authentication providers, such as OAuth2Proxy and Google.

If the users want to add a custom authentication provider, then Backstage allows this as well. With the help of the library Passport, the project can allow certain authentication strategies.

Another ethical aspect that can be of concern is the future idea to add Telemetry. While the use of telemetry is not inherently a bad or unethical decision, it leaves room for invasive data collection if implemented like this. The future has to determine whether this will be the case or not.

A final ethical concept that needs to be looked at is naturally the aspect of development in an Open Source environment. The project is under Apache License 2.0, which itself allows people to modify and use Backstage for commercial use. This being said, not everything of the project is currently Open Source. There are quite a few plugins that Spotify uses internally that do not get distributed outside of the company. However, this does not need to be malicious practice, quite the contrary. From the perspective of Spotify it makes sense to not share their entire system, which might allow competitors to copy their software. This will not benefit them in any way. Therefore, the concept of Open Source is fair in its usage during this project.