BroadcastOps: DevOps für die Medien
Wie Broadcaster mit DevOps den Wandel für sich nutzen können
Früher bestanden die Tech Stacks von TV-Sendern vor allem aus kundenspezifischer Hardware, die oft eine monolithische Architektur aufwies. Doch das hat sich geändert: Leistungsfähige COTS-Hardware und die Konvergenz auf IP für den Medientransfer haben dazu geführt, dass sich viele Services durch die verwendete Software statt spezialisierter Hardware definieren.
Mit dem Einsatz agiler Methoden und von DevOps-Praktiken verkürzen sich die Release-Zyklen der Software zusehends. Indem sich Broadcaster auf diese veränderten Rahmenbedingungen einlassen, nutzen sie den tiefgreifenden technologischen Wandel für sich.
I. Der Bedarf
Die Broadcasting-Branche ist durch lange Lebenszyklen und geringe Ausfallzeiten gekennzeichnet. Viele Sender arbeiten 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 ist es eine Herausforderung, der Entwicklung immer einen Schritt voraus zu sein – schließlich geht es um Integrationen in jahrzehntealte Systeme in streng regulierten Bereichen.
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 vorgegeben 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“ zu ersetzen.
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.
Änderungen müssen 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
![[Translate to Deutsch:]](/fileadmin/_processed_/6/2/csm_Header_Whitepaper_IAM_a06af4b0ab.jpg "[Translate to Deutsch:]")
