Language: English
When adopting Backstage for your organization, one key decision you’ll need to make is whether to go with a self-hosted or managed solution. Both options come with their own set of advantages and challenges, and the choice largely depends on your team’s needs, resources, and the level of customization you require.
Self-Hosted Backstage
The default approach for adopting Backstage is deploying it in a way that aligns with how you deploy other services. Popular methods include deploying Backstage using Kubernetes on cloud platforms such as AWS or Azure. While Spotify has successfully used Google Cloud for their Backstage instance, the framework doesn’t impose any specific cloud provider requirements, giving you flexibility on where and how to deploy.
One of the key advantages of self-hosting Backstage is the high level of customization it offers. You can configure the platform to meet your exact needs. Some teams even go as far as utilizing only the backend of Backstage and building a completely custom frontend using their own design systems. This means you have the freedom to tailor your Developer Portal exactly how you want it. However, this high level of flexibility comes at a cost. The more you deviate from the default open-source framework, the more work you’ll need to do to keep your instance up-to-date with new features and fixes.
The main challenge with a self-hosted Backstage is the maintenance effort involved. Your team will need to invest time in understanding the internals of Backstage, perform monthly upgrades to the core libraries, and ensure that each plugin is updated when new releases come out. Depending on the scale of your Developer Portal, managing your self-hosted Backstage instance could require a full-time or part-time engineer.
Managed Backstage
For organizations that don’t want to take on the maintenance burden, managed Backstage offers a compelling alternative. Various vendors provide commercial offerings for managed and hosted Backstage instances. This approach is particularly popular with scale-ups that require a functional platform without the need for heavy customization.
With managed Backstage, the biggest advantage is ease of use. You get a fully operational production instance without needing to dive deep into the technicalities of React or Node.js. All integrations and plugins are set up through a simple UI, and updates are automatically pushed to your instance. This translates into needing fewer people to maintain your Developer Portal, making it a good option for teams that want to focus on other priorities.
However, the trade-off is flexibility. Managed Backstage offers less room for customization compared to the self-hosted version. You may find yourself limited in how much you can alter the platform to fit your organization’s unique needs. While this may not be an issue for many, those with specific requirements may find it restrictive.
Which Option Should You Choose?
Ultimately, the decision between self-hosted and managed Backstage depends on your team’s capabilities and goals. If you have the resources and need extensive customization, a self-hosted approach will give you more control and flexibility. On the other hand, if you want a hassle-free, scalable solution with minimal maintenance, a managed Backstage instance might be the right choice for you.
By understanding these two deployment options, you can make an informed decision about the best approach for implementing Backstage in your organization, helping you enhance your Developer Experience while managing the complexity of your tech ecosystem.