BroadcastOps: DevOps für die Medien

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.