BroadcastOps: DevOps für Medien

Jannik Altgen
Jannik Altgen
Business Consultant
Tags
Broadcaster
DevOps
Agile Entwicklung
Consulting
Wandel
Veröffentlicht 2. Dezember 2022

Wie Broadcaster mit DevOps den Wandel für sich nutzen können – statt gegen ihn zu arbeiten

Früher bestanden die Tech Stacks von TV-Sendern vor allem aus kundenspezifischer Hardware, die oft eine monolithische Architektur aufwies und von einigen wenigen marktbeherrschenden Anbietern geliefert wurde. Doch das hat sich geändert: Leistungsfähige COTS-Hardware und der Wechsel auf IP für den Medientransfer haben dazu geführt, dass viele Services sich durch die verwendete Software statt spezialisierter Hardware definiert.

Mit dem Einsatz agiler Methoden und DevOps-Prinzipien haben sich die Software-Release-Zyklen drastisch verkürzt. Da immer mehr Aufgaben softwarebasiert sind und sich die Release-Zyklen durch den Einsatz agiler Methoden und DevOps-Praktiken verkürzen, stehen Sender unter großem Druck: Wer mit den großen Veränderungen Schritt halten will, muss lernen, den Wandel für sich zu nutzen statt gegen ihn zu arbeiten. 

I. Der Bedarf

Die Broadcasting-Branche ist durch lange Lebenszyklen und geringe Ausfallzeiten gekennzeichnet. Viele Sender sind öffentliche Einrichtungen, die von langjährigen Mitarbeitern geleitet werden. Die Branche arbeitet häufig mit monolithischen, eng gekoppelten Architekturen, die größtenteils On-Premises betrieben werden. Neben der Betriebssicherheit sind auch die Anforderungen an Datensicherheit hoch – ein Leak etwa bei gespeicherten persönlichen Daten von Whistleblowern könnte sich als lebensbedrohlich erweisen. In diesem Umfeld Systeme zu entwickeln, ist eine Herausforderung.

Wenn der technologische Wandel eine Welle ist, dann versuchen Broadcaster, auf ihr zu reiten – aber vorsichtig. Es ist eben eine Herausforderung, der Entwicklung immer einen Schritt voraus zu sein, wenn Integrationen in jahrzehntealte Systeme in streng regulierten Bereichen gewartet werden müssen. Die Sender stehen unter einem starken Druck, mit der zunehmenden Geschwindigkeit der Software-Lebenszyklen Schritt zu halten, die von den Herstellern durch die Umstellung auf DevOps-Methoden erzwungen wird – d. h. den kollaborativen oder gemeinsamen Ansatz für die Aufgaben, die von den Teams für Anwendungsentwicklung (Dev) und IT-Betrieb (Ops) des Unternehmens ausgeführt werden. In seiner engsten Auslegung beschreibt DevOps die Einführung von iterativer Softwareentwicklung, Automatisierung und programmierbarer Infrastrukturbereitstellung und -wartung.

Dank der Leistungssteigerung bei COTS-Hardware und einer zunehmenden Reife von Software-Implementierungen ist eine Reihe "softwaredefinierter" Produkte verfügbar, die Probleme lösen, für die früher teure kundenspezifische Hardware erforderlich war. Bildmischung, Audiomischung, Video-Routing, Grafik- und Channel-Playout – das alles kann Software leisten. Broadcaster müssen also nicht nur bereits vorhandene Software schneller einführen, sondern sie stehen auch vor der Herausforderung, herkömmliche Hardware durch "COTS plus softwaredefinierte" Lösungen“ ersetzen zu müssen.

Sender müssen sich schnell an den Wandel in ihrem Umfeld anpassen – andernfalls werden sie verpassten Chancen nachtrauern und mit zu umfangreichen Änderungsprozessen konfrontiert.

DevOps integriert traditionell voneinander getrennte Teams: Softwareentwicklung, Qualitätssicherung und IT Operations.

II. Definition von BroadcastOps

Lassen Sie uns definieren, was wir als BroadcastOps bezeichnen. Die Idee besteht darin, die gegebenen Methoden des Agile-Frameworks sowie die bewährten DevOps-Praktiken durchzugehen und zu überlegen, wie sie in einer Broadcast-Umgebung angewandt werden können, um sich der zunehmenden Geschwindigkeit der Software-Landschaft anzupassen.

1. Kontinuierliche Integration und Entwicklung 

Kontinuierliche Integration und kontinuierliche Bereitstellung (Continuous Integration and Continuous Deployment oder CI und CD) – also das ständige, weitgehend automatische Testen von Design-Änderungen und deren Bereitstellung in Produktionsumgebungen –, ist etwas, das bei der sendertypischen Top-down-Entwicklung von Systemen fast nie vorkommt. Strenges Requirements Engineering ist die Norm, wobei die Unzulänglichkeiten dieses Modells außer Acht gelassen werden. Das gilt insbesondere in Organisationen wie Medienunternehmen mit ihren zahlreichen unterschiedlichen Stakeholdern.

Statt Anforderungen zu übersehen, jahrelang Gantt-Charts zu planen und viele Change-Requests zu schreiben, müssen Änderungen kontinuierlich in die Broadcast-Produktionskette integriert werden. Dabei geht es nicht mehr darum, am Ende einen großen Schalter umzulegen, sondern Komponenten auf einer kleineren Ebene zu ersetzen und zu integrieren. Man denke an "Microservices auf der Ebene der Infrastruktur".

Damit das praktikabel ist, müssen die Systeme natürlich so weit automatisiert werden, dass Versions-Up-and-Downs zumindest über Nacht durchgeführt werden können – um die zeitaufwändigen, teils jahrelangen Projekte für Versionsänderungen zu ersetzen.

Hier einige konkrete Ideen, wo sich diese Vorgehensweise bei Broadcastern anwenden lässt:

  • Automatisierte Tests für Netzkonfigurationen – möglicherweise unter Verwendung eines digitalen Zwillings wie GNS-3 oder EVE-NG (Netzsimulatoren)
  • Automatisierte Routenprüfung, um zu testen, ob Videoströme ihr Ziel erreichen können – wiederum mit Hilfe eines digitalen Zwillings für das Video-Routing
  • Im Wesentlichen die Durchführung einer Netzwerksimulation und das Testen von Änderungen anhand dieser Simulation, nachdem festgelegt wurde, welcher Endpunkt mit wem kommunizieren muss – wie ein digitaler Zwilling

2. Infrastruktur als Code

Systeme werden fast nie in maschinenlesbarer Form definiert. CADZeichnungen werden manuell erstellt, Excel- Tabellen manuell gepflegt. Vielleicht gibt es einige Konfigurationsdatenbanken, aber die Daten werden nur selten operativ genutzt. Diese Daten müssen für die Orchestrierung nutzbar gemacht werden.

  • Automatische Dokumentationsdiagramme mit deklarativen Methoden, die sich aus Infrastructure-as-Code-(IaC)-Definitionen ergeben können (z. B. Mermaid.js- Diagramme)
  • Verwaltung und Nutzung maschinenlesbarer Daten über Endpunkte zur On-Demand-Bereitstellung und -Konfiguration von Cloud-Ressourcen auf der Grundlage von IaC-Best-Practice
Jetzt gesamtes Whitepaper anfordern
Möchten Sie mehr zu dem Thema wissen?
Füllen Sie das Formular aus und klicken Sie auf "Download". Im Anschluss erhalten Sie einen Link per E-Mail zum Download des Whitepapers. Bitte beachten Sie, dass die Zustellung der E-Mail einige Minuten dauern kann.
Jetzt kostenlosen Download anfordern
BroadcastOps – DevOps für die Medien
Datenschutz*