Hello! I’m Ilseon Choi, a cloud security and platform engineering expert. π
If we discussed the necessity of a developer portal in the last post, today we’ll delve into the actual entity: Backstage. Let’s explore its philosophy and structure, understanding why it’s called a “framework” rather than just a “tool to install and use”!
π Chapter Overview and Learning Objectives π―
Backstage was born to overcome the limitations of microservice management that Spotify experienced during its rapid growth. It was later donated to CNCF and is now an open-source project with a strong community.
In this chapter, we will learn:
- The decisive reasons for Backstage’s creation π‘
- How to align Backstage’s core values with your organization π€
- Understanding Backstage as a ‘framework’ rather than a ‘product’ ποΈ
- Identifying the components that make up a Backstage instance π§©
1. The Birth of Backstage: Spotify’s Challenges πΈπͺ
The background of Backstage’s birth closely resembles the problems many mature IT organizations face today.
π Side Effects of Rapid Growth
Spotify hired new engineers every week, and the number of microservices grew exponentially. The platform team soon hit its limits. Even basic questions like “Which service is running, and who is responsible?” became difficult to answer.
ποΈ From System-Z to Open Source
Initially, they created an in-house microservice catalog called System-Z.
- Initial: Only metadata such as repository links, responsible teams, and PM names were managed.
- Evolution: Integrated service dependencies, API documentation, and software templating (Scaffolding) features.
- Result: Documentation was managed alongside code, ensuring up-to-dateness, and it became a self-service platform where engineers could directly create resources.
Spotify didn’t keep this innovative tool to themselves; they donated it to CNCF. Now, hundreds of organizations, including Fortune 500 companies, are revolutionizing their developer experience through Backstage. π
2. Backstage’s Philosophy: Autonomy and Ownership βοΈ
Backstage is not just a page that collects tools. It embodies a clear DX (Developer Experience) philosophy.
π Information Aggregator
Backstage does not aim to replace existing CI/CD tools or LDAP directories. Instead, it acts as an ‘information hub’, gathering scattered information to help developers navigate without getting lost.
π‘οΈ Autonomy & Ownership
- Autonomy: A central team cannot create all plugins. Analytics teams are encouraged to manage analytics plugins, and security teams to manage security plugins themselves.
- Ownership: Every software component should be owned by a single team. This ensures information remains up-to-date and accountability is clear.
3. Backstage is a ‘Framework’ ποΈ
This part is the most important. Backstage is not a ‘finished product’ that ends with a single installation file (.exe or .dmg).
Backstage is a collection of libraries based on React (frontend) and Node.js (backend). In other words, it’s a platform that you ‘develop’ and ‘assemble’ yourself to fit your organization’s needs. With approximately 25 core packages and over 150 open-source plugins available, you can pick and choose only what you need.
4. Backstage Instance’s 3-Tier Model π§©
The Backstage you will build is broadly divided into three layers.
- Core: Open-source based code managed by the Backstage main team. It serves as the backbone of the system.
- App: This is the instance you will actually deploy and that developers will access. It is created via CLI and is the area where you customize it to your liking.
- Plugins: These are units that extend functionality. The software catalog itself exists as a plugin, and you can install various plugins provided by the community or create your own.
Backstage is the best solution for reducing developers’ cognitive load in the cloud-native era. If you want to reduce the complexity of your organization, pay attention to Backstage right now! π
Leave a Reply