Spotify has entered the next phase of the open source Backstage catalog project by adding support for templates through which the process of deploying software components now can be automated.
Backstage was developed by Spotify to create an open source catalog through which DevOps teams could build portals through which developer tools are centrally managed.
Stefan Ålund, platform developer experience product lead for Spotify, said the goal is to bring some order to what otherwise would be a chaotic IT environment. By standardizing the tools made available to developers, Backstage enables IT organizations to develop more consistent workflow processes, he noted.
Ålund said DevOps teams via custom templates can automate those workflows to the point where a microservice, website or other software component can be deployed via a single click. That approach also serves to encourage reuse of both developer tools and the modules those tools were used to create, he said.
In some instances, those templates will eliminate the need to depend on site reliability engineers (SREs) to deploy the same code over and over, he added.
Spotify is currently proposing to make Backstage a sandbox-level project that would be further developed under the auspices of the Cloud Native Computing Foundation (CNCF).
In the meantime, Alund said Spotify will continue to refine a service catalog that has been widely employed across DevOps teams for the past four years on top of a core instance of the open source Jenkins continuous integration/continuous deployment (CI/CD) platform.
It’s not clear how DevOps-mature an organization must be to realize the need for a catalog through which modules of code could more easily be reused. In some cases, the transition to microservices may inevitably force the issue. Rather than having developers potentially reinventing the microservices wheel, a portal would make it easier to discover what software assets already exist and deploy them automatically.
A catalog also provides the added benefit of making it easier to track the provenance of a project as well as who currently has operational responsibility for it within the context of a larger software supply chain enabled by best DevOps practices, Alund noted.
Regardless of the level of DevOps maturity inside an organization, the need for a catalog to track services quickly becomes apparent as the number of microservices developed increases. It’s said that every company is now a software company. If software is to be managed as a digital business asset, then it’s critical for organizations to determine what modules of code they have and then determine which modules are the most valuable to the organization.
Only then can every company that aspires to be a provider of software that happens to manufacture something or provide a service be managed like a true software company. Anything short of that goal is just a mere statement of aspiration.
