4 ways we implement platform engineering at Sportradar

At Sportradar, we regularly conduct developer experience workshops, where we ask our internal engineering community to talk about their experiences and challenges. These are useful in many respects and they always leave me full of ideas for how we can extend support to our developers. One of the ways we have done this is to introduce a cohesive approach to platform engineering, allowing developer teams to become self-sufficient and cross-functional.

I believe that an essential element of platform engineering is listening to what your customers and community needs and wants, and delivering on those. And for our teams in the centralized platform and DevOps practice, our customers are Sportradar’s developers. 

We employ platform engineering in four ways at Sportradar.

1. Restructure teams for self-sufficiency 

At Sportradar, we draw on the Spotify model, which relies on each squad—including DevOps—having the team expertise necessary to build features and apps for their end-user base. We started our own “Sportify” reorganization process in mid-2019, and it is now fully actualized. Like many companies, one way that Sportradar grows is through acquisition, so there's always a transition period as we acquire new companies and we help align people to our model. In our “Sportify” model, platform teams are a central function while DevOps specialists are embedded into the squads.

While the squads are smashing targets and generating organizational-wide benefits, there have been some challenges. Each team has their own set of goals and principles driving decision-making, so drawing on common resources for things like using Kubernetes or setting up observability monitoring can present difficulties. 

To tackle this, we created a new engineering enablement group to support the use of best practices in each squad, this aligns both DevOps and platform engineers around common principles and goals, as well as evangelizing centralized tools and approaches. In this newly formed team, we look to the big engineering challenges and then produce frameworks and tools to address them. We also work hard to ensure that there is complete alignment between DevOps in the squads and the core platform team.

2. Use paved roads for common developer tasks

The engineering enablement group uses the paved roads approach to speed up new projects and reduce developer friction. Other companies might call it golden standards or golden paths—but whatever name it goes by, it means engineers will achieve their outcome much more quickly. 

When developers build applications, they want the apps to be performant, delight customers, and drive revenue. If you divert off the paved road, you can still get to those outcomes, but it's going to take you a little bit more time. When on the paved road, you remove a great deal of complexity. This is where the union of engineering enablement, centralized platform, and DevOps teams comes in. The central functions define the managed services needed to support developers to take a paved roads approach; sharing a common stack that aids observability, software development lifecycle decisions, CI/CD pipelines, and other frameworks and solutions.

3. Create a core set of common metrics

On paved roads, New Relic’s observability function becomes more available and standardized across the organization. All squads measure three core metrics: availability, reliability, and performance. When starting a new project, developers take a paved roads stack, including New Relic and purpose-built New Relic apps, to introduce these core metrics, allowing developers to get on with writing the code for their app rather than building and managing an app platform. 

New Relic is ultimately removing complexity: it's a managed service, so developers don't have any servers to look after. It's low complexity because auto-instrumentation means devs can drop the agent into their apps. We can also use some of the other existing frameworks in a paved roads model to synthetically test applications in a non-production environment. Common metrics in a paved roads model help you bring all of these things together and time-to-market is drastically reduced.

4. Publish a managed services catalog

An internal developer portal provides a scorecard against all of our applications and services. A services catalog is used to both bootstrap the project and add the service to the developer portal. Squad developers select what they want, and the catalog provides an opinionated stack with all the components of the app or service they want to build. It ensures that developers can focus on what is important to them; building great applications. The platform team provides all managed hosting solutions and core services, name resolution, networking, and whatever else may be needed. The DevOps centralized team provides the automated pipeline and observability capabilities. The template of that paved road is bootstrapped and the developer can focus solely on the complexities of applications, and not necessarily the ecosystem around it. 

We also have a product owner within the engineering enablement group, whose job is specifically to look across all the platform and DevOps functions and make sure that the products that we're building all make sense, and that these paved roads implementations join up in a coherent fashion and effectively serve the need of the developers.