What is Platform Engineering

A few weeks into my role as Head of SRE at DAZN I realised that to really deliver on the benefits of SRE, DAZN needed more than just an SRE team (or two) and I went about designing a broader org that I thought would empower and drive DAZN forward. 4 years later I wanted to look a back on what I designed and share what has worked and what could be better.

The Teams

At DAZN, Platform Engineering consists of 4 areas, Cloud Engineering, SRE, Developer Experience and Core Services. Each area works cross functionally to deliver products and services to the wide engineering community.

Cloud Engineering focuses on our AWS estate building tools and systems to make managing a large number of accounts and users manageable and ensuring that no matter what team you work in you have a standard platform of VPC, IAM Roles, Bastions, ECS Clusters, Transit Gateway Connects etc.

Developer Experience (DX) focuses on the tools that developers use everyday to make their life easier. This includes our backstage deployment and our change management tooling

SRE looks after everything reliability, from our central logging pipelines that ensure all logging matches a standard pattern across DAZN to our large new relic estate. SRE also own our pagerduty and engineer incident response process.

Core Services own some of the systems that are using to power the production DAZN application. Traditionally this were things that were owned by multiple teams part time and were never really given the love they deserved. With core services in place we were able to focus on these critical services and really make them best in class in terms of security and stability.

What Works

• Collaboration — All of my teams (and their leaders) work very closely together. Generally projects are owned by one area but will seek input on delivery from the others. For example, dazn-cli is a tool installed on all developers laptops, it is owned by DX but has functionality built by all the other teams to integrate deeply into our platform.
• DX Everywhere — We have also found that having DX closely connected to Cloud and SRE has ensured that the services we delivered to engineers have been fully thought out from a user experience and they have been instrumental in helping platform shape its tone of voice and communication strategy.
• Developers are our Customers — With a platform engineering function it is critical to treat your internal customers exactly like you would paying clients. This means be clear with what they need, make sure you are delivering value and ensure your documentation is up to scratch. You also need to sell what you are doing rather than trying to force adoption.
• Guidance over Governance — With a relatively small platform org looking after hundreds of developers it is critical that you don’t become a bottleneck. The way we have done that with Platform Engineering is to focus on providing guidance on how things can be done and tooling that supports that guidance rather than gates and blockers to prevent engineers coming up with their own solutions. At the end of the day, if there is a clear way forward and the guidance makes sense most teams will happily follow it, there is no need for fences.

What could be better

• Metadata — The single biggest win platform engineering has delivered is something called “dazn manifest” which is a json file in the root of every repo that describes the services built by the repo and the team that owns it along with details about on-call, dependancies and cost control. It took us years to build adoption around the manifest and that was predominately because we didn’t focus on delivering developer value. from a platform perspective it was critical to understand who was looking after what but obviously the teams themselves already knew so there was no real value for them. It wasn’t until we started to automatically manage deployment notifications to new relic and take the toil out of PagerDuty configuration did it start to click with engineers the value it could bring.
• Blurry Lines — In the early days of Platform it was quite unclear who was going to be responsible for what. DAZN has always practiced “freedom and responsibility” but in order to do that that well you need ownership. These days its much clearer where those boundaries naturally lie but it would have been better to have laid that out up front and communicated if those lines changed.
• Frontend — My personal experience is much more with backend development and that naturally impacted the focus of platform engineering. This led to a few decisions that really only suited backend microservices and didn’t work well for our front end clients. If I were to go back to the early days I think ensuring that we always had at least one or two projects focused on improving the frontend tooling and observability would have helps us maintain a level of balance.

So Whats Next?

For the most part, more of the same I think. The scope of platform engineering makes a huge amount sense to me and there are loads of things we still have left to do. I think we’ll focus on standardisation to allow teams to focus on features and to reduce the cognitive load when switching context across a few different service. I’d also like to improve our approach to deprecations and modernising our stack, naturally any organisation builds up a certain amount of tech debt and i’d like to see if we can automate our way out of some of those challenges.

Finally, I would just like to say thanks to all of my engineers a lot of whom have been with me from the start, without the amazing skill and dedication everyone has shown we would never have achieved what we have.