Virtualisierung und flexible Lizenzierung treiben die umfassende Modernisierung von CSG voran

Die meisten Unternehmen sind dabei, ihren IT-Betrieb zu transformieren – von lokalen Systemen in die Cloud und von physischen zu virtuellen Umgebungen. Seit Beginn der COVID-19-Pandemie beschleunigt nahezu jedes Unternehmen seine Modernisierung.

Dies trifft auch auf CSG zu, einen seit 35 Jahren bestehenden Anbieter von Kundeninteraktionsdiensten für die Telekommunikations- und Kabelbranche. Das Unternehmen stellt den größten Kabelnetzbetreibern Nordamerikas digitale Lösungen zur Verfügung, mit denen sie Kundenbeziehungen, Abrechnung und Betriebsabläufe effizienter verwalten können.

Vor einigen Jahren litt CSG unter den Einschränkungen veralteter Prozesse, die durch das mangelnde Engagement neuer Anwendungsverantwortlicher noch verschärft wurden. So wie CSG seine Kunden bei der Modernisierung unterstützt, war es nun an der Zeit, auch die eigenen Abläufe weiterzuentwickeln.

Erica Morrison, Vice President of Software Engineering bei CSG, wurde damit beauftragt, das Operational-Engineering-Team von CSG beim Aufbau einer DevOps-Organisation und -Kultur zu unterstützen – obwohl sie zuvor ausschließlich im Softwarebereich tätig gewesen war.

„Für einen Entwickler ist es ein echter Schock, plötzlich in die Welt des IT-Betriebs versetzt zu werden und unmittelbar zu erleben, vor welchen Herausforderungen die Teams dort stehen“, sagt sie. „Dadurch weiß ich die Arbeit all unserer Betriebsteams definitiv mehr zu schätzen.“

Durch die Einführung bewährter Entwicklungspraktiken in ein Team, das traditionell ausschließlich für den Betrieb zuständig war, konnte CSG eine Vielzahl von Herausforderungen angehen: bisher ungenutzte Funktionen von F5 einsetzen, neue Tools integrieren und eine unternehmensweite Lizenzvereinbarung abschließen, die die erforderliche Flexibilität bot.

Eine Vielzahl von Herausforderungen

Erin Garrigan war damals Scrum Master des Teams. Heute ist sie als Führungskraft tätig und berichtet von mehreren Initiativen, die zusammengenommen dem entsprachen, was CSG 2016 als Fünf- oder sogar Zehnjahresplan ins Auge gefasst hatte.

„Aus technischer Sicht gab es bei Änderungen zu viele manuelle Prozesse, und es war nicht transparent genug, wer was tat“, sagt sie. „Viele verschiedene Teams hatten Zugriff auf unsere Geräte, und uns fehlten die dafür erforderlichen robusten Kontrollmechanismen.“

Das waren nicht die einzigen Probleme. Die Infrastruktur war instabil, und da es an einer allgemeinen Zustandsüberwachung und entsprechenden Warnmeldungen mangelte, bemerkte das Team häufig erst durch Hinweise von Kunden, dass sich Geräte in einem kritischen Zustand befanden. Auch die Modernisierung der Hardware war ein wichtiges Anliegen.

Transformation durch Infrastructure as Code

Das erste und größte Projekt des Teams bestand darin, mithilfe von F5 iApps alles in Quellcode zu überführen. Da die Prozesse bei CSG zuvor manuell abliefen, führte das Team zunächst einen nächtlichen Export der Gerätekonfigurationen ein und erhielt so Einblick in die Konfigurationen. Schließlich vollzog es den Übergang zu einem neuen Paradigma, bei dem nun der Quellcode bestimmt, was auf den Geräten ausgeführt wird.

„Innerhalb eines Jahres haben wir ausgehend von manuellen Änderungen und dem Infrastructure-as-Code-Konzept über 100 iApps erstellt“, so Garrigan. „Der Aufwand, jede manuelle Konfiguration in iApps abzubilden, war enorm. Doch wir entwickelten einige Tools und bewältigten die Aufgabe nach und nach.“

Da die Infrastruktur nun als Code definiert war, konnte das Team die Funktionen seiner Anwendungen voneinander trennen. Operational Engineering unterstützt Dutzende von Anwendungsteams in einer dynamischen Serverumgebung, in der täglich mehrere Änderungsanfragen eingehen. Durch die Einführung eines Self-Service-Prozesses konnten interne Nutzer aus den Anwendungsteams von CSG Änderungen auf einem BIG-IP-Sandbox-Gerät konfigurieren, überprüfen und zur Validierung und Codeüberprüfung durch eine Pipeline leiten. Außerdem entwickelte das Team ein weiteres Tool, mit dem diese Nutzer die Änderungen selbst in die Produktionsumgebung übertragen können.

„Zu diesem Zeitpunkt boten wir Load Balancing und Anwendungsbereitstellung praktisch als Service an“, sagt Phil Todd, Director of Software Development bei CSG. „Wir nutzen Jenkins für die meisten unserer automatisierten Self-Service-Funktionen sowie für unsere Berichtsfunktionen. Außerdem haben wir eigenen C#-Code geschrieben, um diese Funktionalität im Hintergrund zu implementieren.“

Transparenz und Änderungsmanagement mit BIG-IQ

Transparenz über diese Änderungen zu schaffen, war angesichts der großen und vielfältigen Anwendungslandschaft von CSG ein weiteres wichtiges Anliegen. In der zuvor von manuellen Prozessen geprägten Umgebung konnten sich die Anwendungsteams durch sich überschneidende Änderungen gegenseitig in die Quere kommen. Fehlerhaften Code zu finden, war dadurch unnötig kompliziert.

„In der Umgebung stimmte dann einfach irgendetwas nicht“, sagt Garrigan. „Wir wussten nicht, warum sie sich so merkwürdig verhielt, sondern nur, dass irgendjemand etwas getan haben musste.“

Die manuellen Prozesse führten außerdem dazu, dass das Team nach der Identifizierung eines Problems häufig die Person ausfindig machen musste, die die Änderung vorgenommen hatte, um sie vollständig nachvollziehen zu können.

Um das Problem zu lösen, implementierte das Team F5 BIG-IQ und begann, den Änderungsprozess selbst neu zu gestalten. Dazu führte es automatisierte Berichte zum Systemzustand und zu den Gesamtauswirkungen von Änderungen ein. Außerdem erstellte es ein Grafana-Dashboard zur Überwachung von mehr als tausend Endpunkten, um die Validierung von Änderungen zu unterstützen. Da die Konfiguration nun als Code vorlag und die Bereitstellungen automatisiert waren, erhielt CSG einen umfassenden Einblick in alle vorgenommenen Änderungen.

Todd zufolge hat dies zu einem der größten Unterschiede zwischen der heutigen Umgebung von CSG und den früheren manuellen Prozessen geführt: Wenn eine Änderung einen Fehler verursacht, kann die mittlere Reparaturzeit heute nur wenige Minuten betragen, während es früher Stunden dauern konnte, bis das Team das Problem untersucht und behoben hatte.

„Bei der Anmeldung bei Kibana werden alle Änderungen protokolliert – welche Version bereitgestellt wurde und welche Version zuvor verwendet wurde“, sagt er. „Anstatt lange zu überlegen, warum etwas nicht funktioniert, stellen wir einfach die vorherige Version des Codes wieder bereit, indem wir in Jenkins auf die entsprechende Schaltfläche klicken.“

Virtualisierung ist der Schlüssel

Der nächste Entwicklungsschritt bestand darin, die Skalierbarkeit, Flexibilität und Stabilität der Infrastruktur zu verbessern. Obwohl Dutzende physische Hardwaregeräte, darunter F5 VIPRION-Systeme, im Einsatz waren, lief der Großteil der Anwendungen über lediglich zwei davon: eines für externen Datenverkehr aus dem Internet und ein weiteres für internen Datenverkehr.

Dies führte zu großen Gruppen, die im Falle eines Ausfalls ein höheres Risiko für das Unternehmen darstellten. „Wenn eines dieser Geräte ausfiel, waren im Grunde alle Produkte und alle Kunden davon betroffen“, so Todd.

Gleichzeitig wurden die Anwendungen von CSG zunehmend in die Private Cloud des Unternehmens sowie in öffentliche Clouds verlagert. Das System bot jedoch nur begrenzte Möglichkeiten zur Erweiterung auf diese Umgebungen und unterstützte keine Migration zu AWS.

Auch bei der Bewältigung dieser Herausforderungen spielte die Virtualisierung eine entscheidende Rolle. Infrastructure-as-Code in iApps bot die nötige Flexibilität, um die Gesamtgröße der Ausfallgruppen zu reduzieren und dadurch ein stärker anwendungsspezifisches Load Balancing zu ermöglichen. Zudem schuf dies die Voraussetzungen für einen späteren Wechsel in die Public Cloud, falls erforderlich.

„Vor Kurzem hatten wir einen Ausfall, der sich auf ein Produkt auswirkte“, sagt Morrison. „Vor etwas mehr als einem Jahr wären noch alle Produkte davon betroffen gewesen. Da nun mehr Instanzen in kleinere Gruppen aufgeteilt sind, können wir bei Bedarf außerdem auf andere Systeme ausweichen, und der Auswirkungsradius ist sehr klein. Die Investition in Stabilität hat sich für unsere internen und externen Kunden also bereits positiv bemerkbar gemacht.“

Unternehmenslizenzen bieten die nötige Flexibilität

Durch den Wechsel von F5 BIG-IP Virtual Editions zu einer neuen unternehmensweiten Lizenzvereinbarung (ELA) von F5 gewann CSG zusätzliche betriebliche Flexibilität und konnte Kosten einsparen. Zuvor war die Gruppe hauptsächlich in einem einzigen Rechenzentrum am Unternehmenshauptsitz in Omaha tätig. Die Disaster-Recovery-Lösung bestand darin, die Dienste bei Bedarf einfach in einem Rechenzentrum eines Drittanbieters bereitzustellen.

Als das Team vor einigen Jahren ein zweites Rechenzentrum aufbaute, konnte es die Möglichkeiten für Hochverfügbarkeit über beide Rechenzentren hinweg ausloten. Der bisherige Lizenzvertrag und die physische Hardware schränkten die Optionen jedoch ein. Aufgrund der fest installierten Hardware stand das Unternehmen vor Herausforderungen hinsichtlich Skalierbarkeit, Verfügbarkeit und der Möglichkeit, in die Public Cloud zu expandieren.

„Der Wechsel zu einem F5 Enterprise License Agreement und zur virtuellen Lösung gab uns die Freiheit, jederzeit die gewünschten Systeme bereitzustellen und das zweite Rechenzentrum hinzuzufügen“, sagt Todd. „Außerdem können wir dadurch neue Möglichkeiten ausloten und sehr flexibel auf die Anforderungen unserer internen Kunden reagieren.“

Heute verfügt das Team über mehr Flexibilität, um sich weiterzuentwickeln und eine hohe Verfügbarkeit verschiedener Dienste zu gewährleisten.

Ausblick: Anwendungsbereitstellung in der Cloud

Nach der Modernisierung seiner Umgebung hat das Operations-Engineering-Team von CSG nun den nötigen Freiraum, um für die Zukunft zu planen. Das Team möchte die Sicherheitsfunktionen von F5 noch umfassender nutzen, Referenzarchitekturen für den Einsatz von BIG-IP und Amazon Web Services (AWS) erstellen und mit NGINX neue Funktionen einführen. Dank eines ELA konnte das Unternehmen zudem bestehende Budgets auf neue Architekturen und Funktionspakete verlagern.

Morrison arbeitet außerdem gemeinsam mit den Product Ownern von CSG an einer neuen Roadmap, um auf den bisherigen Erfolgen aufzubauen, die Systemüberwachung und Alarmierung zu verbessern, neue Überwachungsfunktionen hinzuzufügen und ein Kompetenzzentrumsmodell für die Anwendungsbereitstellung zu entwickeln.

Aus übergeordneter Perspektive, sagt sie, sei das eine erfreuliche Ausgangslage. Inzwischen hat das Team nahezu jedes Projekt aus seiner ursprünglichen Fünfjahresvision umgesetzt. Dank der aufgebauten Partnerschaften, Self-Service-Funktionen und Konfigurationen bleibt nur noch, den Anwendungsteams selbst mehr Verantwortung für die Apps zu übertragen.

„Zum ersten Mal fragen wir uns: Was machen wir als Nächstes?“, sagt sie. „Wir haben so große Fortschritte gemacht, dass wir nicht mehr nur damit beschäftigt sind, uns aus Schwierigkeiten herauszuarbeiten. Jetzt geht es darum, proaktiv zu handeln und auf dem soliden Fundament aufzubauen, das wir geschaffen haben.“