Wir führen bei Sportradar regelmäßig Workshops durch, bei denen unsere interne Engineering-Community die Gelegenheit hat, sich über Herausforderungen und Erfahrungen auszutauschen. Diese Workshops haben sich als sehr hilfreich erwiesen und geben mir jedes Mal wieder viele Anstöße für Ideen, wie wir unsere Entwickler:innen noch besser unterstützen können. Eine Maßnahme, die wir beispielsweise umgesetzt haben, ist die Einführung eines teamübergreifenden Ansatzes zum Platform Engineering, sodass die Entwicklungsteams selbstständiger und über ihren eigenen Aufgabenbereich hinaus agieren können.
Als führendes Unternehmen für Sporttechnologie entwickelt Sportradar marktführende, hochmoderne Produkte und Services für Sportfans und Verbände weltweit. Wir kombinieren moderne Observability und Technologie mit einer Reihe produktorientierter Engineering-Grundsätze und helfen damit unseren Entwicklungsteams, kontinuierlich positive Resultate für unsere Kundschaft zu erzielen.
Meiner Meinung nach ist ein wesentlicher Faktor beim Platform Engineering die Fähigkeit herauszufinden, was Ihre Kund:innen und die Community brauchen und wünschen, und das dann auch zu liefern. Für unsere zentralen Plattform- und DevOps-Teams handelt es sich bei der Kundschaft um die Entwickler:innen bei Sportradar.
Wir implementieren Platform Engineering bei Sportradar auf vier verschiedene Arten.
1. Umstrukturierung von Teams für größere Selbstständigkeit
Wir orientieren uns bei Sportradar am Spotify-Modell, bei dem jedes sogenannte Squad (einschließlich DevOps) die notwendigen Fertigkeiten mitbringt, um Features und Apps für die jeweiligen Endbenutzer:innen zu entwickeln. Mitte 2019 begannen wir uns quasi als „Sportify“ neu zu organisieren, und der Prozess ist jetzt abgeschlossen. Wie so viele Unternehmen wächst auch Sportradar zum Teil durch Akquisitionen. Das bringt jedes Mal eine Übergangsperiode mit sich, in der die Prozesse der erworbenen Unternehmen mit unseren in Einklang gebracht werden. In unserem „Sportify“-Modell übernehmen Plattformteams eine zentrale Funktion, während die DevOps-Fachleute in die Squads eingebettet sind.
Unsere Squads übertreffen zwar diverse Ziele und machen sich unternehmensweit bezahlt, aber ganz ohne Probleme ging auch das nicht vonstatten. Jedes Team hat seine eigenen Ziele und Prinzipien, an denen sich die jeweiligen Strategien und Entscheidungen orientieren. Deshalb ist es manchmal nicht einfach, gemeinsame Ressourcen für Dinge wie Kubernetes oder Observability-Monitoring zu nutzen.
Um das Problem zu überwinden, richteten wir eine „Engineering-Enablement-Gruppe“ ein, die Best Practices in jedem Squad fördern sollte. So werden DevOps- und Plattform-Engineers auf gemeinsame Prinzipien, Zielsetzungen und auch zentralisierte Tools und Verfahren eingenordet. In diesem neuen Team gehen wir die großen Herausforderungen beim Engineering an und entwickeln Frameworks und Tools, um sie zu adressieren. Zusätzlich sorgen wir dafür, dass DevOps in den Squads und das Plattform-Kernteam am gleichen Strang ziehen.
2. „Paved-Roads“-Ansatz für gemeinsame Entwicklungsaufgaben
Die Engineering-Enablement-Gruppe nutzt den „Paved-Roads“-Ansatz bekannter Verfahren, um neue Projekte schneller durchzuführen und Entwickler:innen die Arbeit zu erleichtern. Aber ganz gleich, wie das Verfahren genannt wird, ob Paved Roads, Golden Standards oder Golden Paths – es sorgt dafür, dass Entwickler:innen schneller ans Ziel gelangen.
Entwickler:innen möchten, dass die Anwendungen, die sie erstellen, Leistung bringen, die Kundschaft begeistern und für Umsatz sorgen. Natürlich können Sie noch immer ans Ziel gelangen, auch wenn Sie von der gepflasterten Straße abkommen – aber die Reise dauert länger. Mit dem Paved-Road-Ansatz eliminieren Sie einen Großteil an Komplexität. Und hier macht sich die Kombination von Engineering Enablement, zentralisierter Plattform und DevOps-Teams bezahlt. Die Managed Services, die notwendig sind, damit Entwickler:innen einen Paved-Road-Ansatz umsetzen können, werden durch die zentralen Funktionen definiert. Dazu gehören ein gemeinsam genutzter Stack, der Observability erleichtert, Entscheidungen hinsichtlich des Software-Dev-Lifecycle, CI/CD-Pipelines sowie weitere Frameworks und Lösungen.
3. Schaffung eines Basispakets gemeinsamer Metriken
Mit der Paved-Roads-Strategie wird die von New Relic bereitgestellte Observability-Funktion im Unternehmen breiter verfügbar und standardisiert. Alle Squads nutzen die gleichen drei Hauptmetriken: Verfügbarkeit, Zuverlässigkeit und Performance. Zu Beginn eines neuen Projekts nutzen Entwickler:innen einen Paved-Roads-Stack, der New Relic und maßgeschneiderte New Relic Apps umfasst, um diese Hauptmetriken einzuführen. So können sie sich mit dem Programmieren ihrer App beschäftigen, anstatt eine App-Plattform aufbauen und pflegen zu müssen.
New Relic macht die Sache einfacher, denn es ist ein verwalteter Service, sodass sich die Entwickler:innen nicht um Serverprobleme kümmern müssen. Zudem bedeutet die automatische Instrumentierung, dass Devs den Agent einfach in ihre Apps einfügen können. Weitere bereits in einem Paved-Roads-Modell bestehende Frameworks können wir zum synthetischen Testen von Anwendungen in einer Nichtproduktionsumgebung nutzen. Und gemeinsame Metriken in diesem Modell erleichtern Ihnen die Zusammenführung all dieser Aspekte und ermöglichen damit eine drastische Verkürzung der Time-to-Market.
4. Veröffentlichung eines Managed-Services-Katalogs
Ein internes Entwicklungsportal bietet einen Maßstab für all unsere Anwendungen und Services. Ein Services-Katalog wird zum Bootstrapping des Projekts sowie zum Hinzufügen des Service zum Entwicklungsportal genutzt. Die Squad-Entwickler:innen wählen das Gewünschte aus, und der Katalog liefert einen „Opinionated Stack“ mit all den Komponenten der App oder des Service, den sie entwickeln möchten. So können sich die Entwickler:innen auf das Wesentliche konzentrieren, nämlich großartige Anwendungen zu schaffen. Das Plattformteam stellt alle Managed-Hosting-Lösungen und Kernservices sowie Namensauflösung, Networking usw. zur Verfügung. Das zentrale DevOps-Team wiederum liefert die automatisierten Pipeline- und Observability-Toolsets. Die Vorlage für dieses Paved-Roads-Modell wird per Bootstrapping bereitgestellt und die Entwickler:innen können sich ganz in die Anwendungsentwicklung vertiefen, anstatt sich um die dazugehörigen Komponenten zu sorgen.
Unsere Engineering-Enablement-Gruppe umfasst außerdem eine produktverantwortliche Person, deren Aufgabe es ist, all diese Plattform- und DevOps-Funktionen zu beobachten und sicherzustellen, dass die von uns entwickelten Produkte auch Sinn ergeben – und dass die Paved-Roads-Implementierungen miteinander harmonieren und den Entwickler:innen wirklich nutzen.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
