Gerade eben hat der IT-Leiter eine neue epochale IT-Strategie kommuniziert, die das Unternehmen in die digitale Zukunft katapultieren wird. „Public Cloud only“ hat ein Leuchten in die Gesichter der Anwesenden gezaubert, die manifestierte Aufbruchstimmung ist mit Händen greifbar. Da hebt sich in der letzten Reihe eine Hand: „Und was machen wir mit unserer Teradata?“ Die Temperatur im Raum kühlt sich spürbar ab.
Unternehmen mit Public-Cloud-First- oder Public-Cloud-only-Strategien sind heute keine Seltenheit mehr. Die Cloud wirkt nicht nur attraktiv, sondern ist in vielen Fällen auch tatsächlich eine Alternative zu traditionellen IT-Bezugs- und Liefermodellen, die handfeste Vorteile liefert – adaptierbare Kosten, schnelle Skalierbarkeit, Entlastung von Infrastrukturmanagement. Sie kennen das. Aber wenn ein Unternehmen schon ein paar Jahre (oder gar Jahrzehnte) am Markt ist, dann ist die Wahrscheinlichkeit hoch, dass in einer Ecke des (eigenen) Rechenzentrums irgendwo ein altehrwürdiges (Legacy-)System munter Daten vor sich hin prozessiert. Und zwar meist für unternehmenskritische Zwecke. Es ist eine dieser Better-don’t-touch-Situationen. Ich weiß, wovon ich rede: In unseren Rechenzentren steht eine ganz erhebliche Menge solcher Systeme – zumeist in caged areas.
Und nun? Bereits 2011 postulierte Gartner die 5-R-Strategie für die Migration von Applikationen in die Cloud. Und etwas später verfeinerte und erweiterte (auf 6 R) Stephen Orban von AWS diesen Ansatz. Er hält fest, dass neben Rehost, Replatform, Repurchase, Refactor/Rearchitect auch die Optionen Retire und Retain existieren. Sprich: Abschalten oder im bestehenden Zustand konservieren/erhalten.
Für ein business-kritisches System ist die Frage zwischen Abschalten und Konservieren schnell geklärt. Niemand wird allen Ernstes riskieren, sein zentrales Data Warehouse abzuschalten (obwohl das sicher eine interessante Erfahrung wäre). Also bleibt die Exadata, Teradata oder iSeries am Leben – wenn der Aufwand zu groß ist, sie neu zu bauen oder zu migrieren. Die gar nicht so abwegige Gesamtlösung in der realen Welt lautet: Alles, was sich betriebswirtschaftlich und technisch sinnvoll migrieren lässt, geht in die Cloud. Alles andere bleibt erstmal so, wie es ist.
Wenn man als Unternehmen aber einen radikalen und sehr grundlegenden Schwenk in Richtung Public Cloud gehen will (und möglicherweise das eigene Rechenzentrum schon abgemietet oder verkauft hat), dann wird es höchste Zeit, einen adäquaten Platz für die Altsysteme zu finden. Und das wird kaum unter dem Schreibtisch des Kollegen sein, der mit seiner Wortmeldung die Diskussion ausgelöst hatte.
Weil die Altsysteme im Sinne der Unternehmensprozesse häufig mit den neuen Cloud-Systemen kooperieren müssen, ist der Königsweg, die Legacy-Systeme einfach in das gleiche Rechenzentrum zu stellen, aus der die Cloud bezogen wird. Der Lohn werden unschlagbare Latenzen sein. Und damit bekommt das etwas angestaubte Konzept des Housing‘s (oder besser der Colocation) eine neue Bedeutung – als komplementärer Baustein für eine Public-Cloud-Strategie.
Damit realisiert das Unternehmen, das sich auf den Weg in die Cloud macht, auch für seine Altsysteme einen zentralen Vorteil der Cloud: Die Mitarbeiter werden von der wenig wertstiftenden Aufgabe des Infrastrukturmanagements entlastet und das Unternehmen profitiert von dem vermutlich höheren IT-Management- und -Sicherheitsniveau des Cloud-Anbieters, indem sie in ein Tier-3-Rechenzentrum umziehen (dieses Niveau sollte zumindest von einem Public-Cloud-Anbieter zu erwarten sein).
Zugegeben – eine komplette Cloud-Migration wäre spektakulärer. Aber mit einem kombinierten Public-Cloud-/ Housing-Ansatz kann zumindest ein alter Zopf abgeschnitten werden: Das Bereitstellen von Strom, Klima, Zugangs- und Ausfallsicherheit sind heute keine wettbewerbsdifferenzierenden Parameter mehr. Warum also eigene Kapazitäten darauf verschwenden?
Wenngleich Public Cloud plus Housing nicht durch Endgültigkeit überzeugt, so bietet das Konzept doch greifbare Mehrwerte, eine ganzheitliche Perspektive für den kompletten IT-Bestand und – nicht zu vergessen – Einfachheit. Ist keine Raketentechnologie, aber pragmatisch. Kann man ja mal drüber nachdenken.
