Re-Factoring

Bei Netflix begann die „Cloudifizierung“ der unternehmenseigenen IT mit einem regelrechten Daten-GAU. Der Streaming-Dienst hatte die Cloud noch gar nicht auf dem Radar, als ein Zusammenbruch der relationalen Datenbank im August 2008 den Betrieb für drei Tage lahmlegte. „Zu diesem Zeitpunkt hatten wir gerade die Notwendigkeit erkannt“, erinnert sich Yury Izrailevsky, Vice President Cloud und Platform Engineering bei Netflix, „weg von ausfallanfälligen Architekturen vertikal skalierbarer Systeme wie unserer relationalen Datenbank hin zu robusten (...) verteilten Anwendungen der Cloud-Ära zu migrieren.“ Also kein Lift and Shift, sondern Re-Factoring und Re-Architecting. Anfang 2015, nach sechs Jahren Umstellung, war dann zunächst die Mehrheit der kundenzentrischen Workloads in der AWS-Cloud untergebracht. Ein weiteres Jahr später, im Januar 2016, konnte Netflix endlich das letzte seiner eigenen Rechenzentren vom Netz nehmen.

Der Aufwand hat sich gelohnt: In der Zeit der Cloud-Mi­gration zwischen 2008 und 2015 erlebte das Unternehmen, gemessen an der Anzahl der bereitgestellten Streaming-Stunden, ein beispielloses Wachstum um den Faktor tausend. Als Resultat der Modernisierung der eigenen Software-Plattform konnte Netflix im Januar 2016 die eigenen Dienste quasi im Vorbeigehen auf weitere 130 Länder ausweiten.

Cloud-native Anwendungen als containerisierte Microservices stellen im Hinblick auf die betriebliche Effizienz, die horizontale Skalierbarkeit und die selbstheilende Robustheit bei unternehmenskritischen Workloads klar das Nonplusultra dar. In vielen Fällen kommt es im ersten Anlauf jedoch da­rauf an, in der Cloud überhaupt Fuß zu fassen.

Wer sich nicht etliche Jahre mit dem Re-Factoring befassen möchte, für den führt der Lift-and-Shift-Ansatz zweifelsohne schneller ans Ziel. Beim Re-Factoring geht vielen Unternehmen schon mal die Puste aus.

Der Wettbewerb um die besten Köpfe der Software-Entwicklung spitzt sich zu. Der Mittelstand zieht dabei oft den Kürzeren. So bescheinigt McKinsey deutschen Unternehmen Schwierigkeiten, Fachkräfte wie Datenanalysten, Software-Entwickler und Designer an Standorte mit weniger als 300.000 Einwohnern zu locken. Für die Umsetzung von Digitalisierungsinitiativen wie Re-Factoring von Altlasten-Anwendungen bedeutet das: Stillstand.

Es geht jedoch auch ohne den Sprung ins kalte Wasser der Entwicklung containerisierter Microservices für verteilte cloud-native Workloads. Lösungen wie die Apprenda Cloud Platform stellen einen dritten Weg dar: Apprenda verwandelt eine beliebige IT-Infrastruktur in eine richtliniengesteuerte hybride Cloud-Anwendungsplattform auf der Basis von Google Kubernetes. Zu seinen Nutzern zählt das US-amerikanische Start-up Apprenda Namen wie JP Morgan Chase und Boeing.

„Das ultimative Alleinstellungsmerkmal unseres Ansatzes besteht in der Unterstützung beliebiger Infrastrukturen und eines breit gefächerten Portfolios von Anwendungsarchitekturen“, sagt Erik Lustgarten, Senior Sales Engineer von Apprenda. Die Lösung sei die einzige, die sowohl containerisierte, native Cloud-Work­loads unterstützen als auch vorhandene Anwendungen modernisieren könne. Andere Plattformen unterstützten lediglich bereits containerisierte Workloads.

Ein gewisses Maß an Vendor-Lock-in sei beim Einsatz von Technologieprodukten wie Apprenda in der Praxis „schlicht unvermeidbar“, räumt Lustgarten ein. Entweder bestehe eine Abhängigkeit von einer technischen Architektur oder aber aus der operativen oder geschäftlichen Perspektive. Dabei sei wichtig zu wissen, wo genau Abhängigkeiten bestehen und aus welchem Grund man diese eingegangen ist. In jedem Fall sollte man sich Gedanken darüber machen, wie eine mögliche Fallback-Strategie zum Wechsel des Anbieters aussehen könne.

Mit Hilfe einer einheitlichen Entwicklungssprache soll die Apprenda-Plattform die Dev- und die Ops-Abteilungen in Unternehmen auf einen gemeinsamen Nenner bringen. Die IT würde ihre Richtlinien, Kontrollen und andere Funktionen konfigurieren, während die Entwickler die ihnen bereitgestellten Dienste zeitsparend im Selbstbedienungsverfahren in Anspruch nehmen. So könnten Unternehmen Zeit für die „Cloudifizierung“ ihrer kritischen Workloads gewinnen, ohne den laufenden Betrieb zu gefährden. „Wir möchten, dass unsere Kunden ihre erste App innerhalb von 30 bis spätestens 60 Tagen im Produktivbetrieb am Laufen haben“, so Lustgarten. Unternehmen könnten dann die gewonnenen Erkenntnisse „auf die nächsten 100 oder 1000 Apps anwenden“.