Integrating Backstage at DAZN
Early on our journey within DAZN we introduced Microservices and Microfrontends.
Microservices and Mircrofrontends were chosen as one of the main benefits is they empower and spread out work among autonomous teams, whether co-located or distributed, without slowing down delivery throughput.
They fit perfectly with our adopted Engineering motto: “You build it, you own it”, allowing us to scale and empower our teams, especially considering that DAZN Engineering has more than 500 people and 60 teams, and we are still growing.
But, since every technical or architectural decision has tradeoffs.
With our microservice architecture, we found ourselves trying to answer questions like:
- who owns this service?
- what does it do?
- where does the code live?
- what are the services dependencies?
- …
Service Ownership
We needed a way to clearly establish ownership of our services, and have access to consistent documentation for them, so anyone with an interest in understanding a service could find that information without navigating around difficulties like inconsistent, incomplete, or outdated documentation.
Discovering service information is especially relevant during incidents.
It was around 2018 when we started establishing a method to centralize information surrounding our services. We felt it was important that this metadata/documentation lived in our repositories with our code, and be part of the development cycle so that it could stay relevant.
After many discussions, starting with a classic “back of the napkin” design in a hotel in Seattle, we introduced our dazn-manifest file.
The dazn-manifest is a YAML file that lives in our Git repositories, alongside our code and services, allowing us to describe aspects of a repository and the components within it, driving our tooling, and making answering questions around ownership and documentation.
The dazn-manifest file was the step forward that helped us build a service dictionary, where engineers and operations could find all the information about a service.
Fast forward three years and the dazn-manifest file has evolved to form the basis of multiple infrastructure services that now leverage the manifest file’s information.
Whilst the manifest file has been integrated into many systems behind the scenes, we didn’t have a central place to view the service catalog that the manifest file helped us create.
Until now.
Enter Backstage
In March 2020, Spotify open-sourced Backstage: a developer portal that aligns very well with our objectives.
Spotify then handed control of the project to the CNCF where it became a sandbox project in September 2020, receiving extra resources, feedback, and a credibility boost.
What really stood out to us when we saw Backstage is how much it aligned with our previous thinking which went into our manifest file (and the vision we had for it).
Backstage is a single place to view software and services in a single place. Clearly, Spotify had been suffering the same pains as we did, and had come to similar conclusions and solutions.
Backstage makes it possible to view, and manage thousands of services, through discoverability.
For example, Backstage provides an interface for every team to view all the services that they own, the dependencies of the service, and its documentation. Backstage exposes views for managing software at the team, domain, and service level.
Backstage also leverages a plugin-based architecture that allows extensions of the Backstage platform, allowing Backstage adopters to benefit from the growing community, and also extend the platform to suit any individual needs.
Integrating The Backstage Software Catalog with our own DAZN Manifest
Backstage natively supports importing catalog data through the use of entity descriptor YAML files, which looks very similar to our own dazn-manifest file. Luckily, Backstage also allows us to ingest data from any arbitrary external source. In our case, our manifest file.
To support functionalities that require information not held in the dazn-manifest, we’ve now updated our manifest RFC to adopt the concept of “annotation” (which is a feature heavily inspired by Backstage’s own catalog descriptor file).
Using annotations we can now power several Backstage plugins such as Jira, TODO, and PagerDuty. We are also leveraging annotations to populate Backstage metadata that isn’t currently supported by dazn-manifest, such as system and lifecycle entities.
We as the DX team are committed to making Backstage a first-class citizen in the DAZN ecosystem.
Whilst we didn’t jump immediately on the Backstage adopter’s train, we’re now working with Spotify and the maintainers, contributing back to the open-source of Backstage (eg, here, here, here, here), and helping to shape Backstage into the tool that takes our early work on DAZN manifest further massively improving our developer experience.
As you can see below, we are not alone in believing in the future of Backstage, DAZN is in good company alongside the other Backstage adopter’s: backstage.spotify.com/
