Das disruptive Potenzial von Azure Local

Die wichtigste Herausforderung für RZ-Betreiber

In den letzten Monaten und Jahren habe ich mehr als einmal und auch an dieser Stelle auf ein Problem hingewiesen, das sich nun nach meiner Wahrnehmung zur wichtigsten Herausforderung für RZ-Betreiber entwickelt hat. Ich meine den Fachkräftemangel. Während durch den anhaltenden Digitalisierungstrend einerseits und die immer höheren Anforderungen der Cyber Security andererseits der Aufwand für den Betrieb von Rechenzentren weiter steigt, sorgt der unaufhaltsame demografische Wandel für die Ausdünnung des Personals, das für die Aufrechterhaltung von Rechenzentren samt ihrer Compute-, Storage-, Netz- und Sicherheitskomponenten erforderlich ist.

Es gibt keine Aussicht, dass sich die von den Weather Girls mit „It’s Raining Men“ besungenen, vom Himmel fallenden Männer bewahrheiten, nicht für IT-Männer und noch weniger für IT-Frauen. Auch hat sich die Hoffnung, Cloud Computing löse das Problem, in den letzten zehn Jahren als trügerisch erwiesen. Genauso aussichtslos oder unzureichend ist das Setzen auf Migrationsströme und die Umschulung von Personal, das die im Niedergang befindlichen Wirtschaftszweige freisetzen.

Deshalb gilt: Die Unternehmen müssen in den kommenden Jahren mit weniger Personal ihre Rechenzentren betreiben, die in den meisten Fällen weder an Komplexität noch an Größe abnehmen.

Weniger ist mehr

Der sich verschärfende Fachkräftemangel im IT-Bereich ist längst bekannt. Deshalb gibt es auch seit Jahren das Versprechen vieler Hersteller, durch Automatisierung den Aufwand für den RZ-Betrieb zu reduzieren. Ein in diesem Zusammenhang immer wieder benutzter Begriff ist Software-Defined Data Center (SDDC). Die Idee dahinter besteht darin, dass die Einrichtung und der Betrieb aller RZ-Ressourcen (Compute, Storage, Netz, Security) mittels einer übergreifenden Software erfolgen.

Erste Schritte in diese Richtung wurden bereits mit der Server-Virtualisierung unternommen. Auch die Virtualisierung von Speicher und Netz wurde von Herstellern ermöglicht. In den meisten Fällen blieben jedoch die sogenannten Silos im RZ-Betrieb bestehen. Die Inbetriebnahme einer Applikation erfordert in der Regel einen Workflow durch die arbeitsteilig zuständigen Silos für Server, Storage, Netz und Security. Virtuelle Maschinen müssen konfiguriert, virtueller Storage muss angelegt, virtuelle Netze gebildet und Firewall-Regeln definiert werden.

Dieser Zustand ist für viele „Kunden“ der Rechenzentren unbefriedigend, da er einerseits mit längeren Wartezeiten auf die Realisierung von Anforderungen einhergeht und andererseits im Kontrast zu den mittlerweile allgemein bekannten Abläufen bei der Nutzung von Public Clouds steht. Die Betreiber der Public Clouds befähigen ihre Kunden zur Selbstbedienung. In wenigen Schritten können Cloud-basierende Ressourcen für Compute, Storage und Netz in Betrieb genommen werden, ohne dass man auf fremde Hilfe warten muss. Auch Mikrosegmentierung als wichtiges Sicherheitswerkzeug ist in den Clouds die Regel und nicht die Ausnahme.
In den letzten zehn Jahren gaben viele Hersteller das Versprechen, mit ihren Lösungen für OnPrem-Rechenzentren den Komfort und Automatisierungsgrad wie von den Clouds bekannt zu realisieren. In den meisten Fällen blieb es jedoch bei bloßen Versprechungen. Die Automatisierungsszenarien blieben meistens Stückwerk. Eine umfassende Lösung für Compute, Storage, Netz und Security gab es von kaum einem Hersteller.

Die VMware-Story

Zu den wenigen Beispielen für ein vollständiges SDDC gehört VMware mit den Software-basierenden Lösungen vSphere (virtuelle Maschinen), vSAN (virtueller Storage) und NSX (Software-Defined-Netz und -Sicherheit). Die VMware-Story geht auch nach der Akquisition des Herstellers durch Broadcom weiter, allerdings nur für den Teil der VMware-Kunden, die sich auf die Preiserhöhungen seit der VMware-Übernahme durch Broadcom einlassen. Broadcom hat sich bei der Wahl zwischen mehr Umsatz durch mehr Kunden einerseits und mehr Umsatz durch höhere Preise andererseits eindeutig für das Letztere entschieden. Vielleicht noch verstörender als die aktuellen hohen Preise ist der Vertrauensverlust. Viele VMware-Kunden nehmen die Preispolitik von Broadcom als Erpressung wahr und trauen dem Hersteller in Zukunft noch mehr Erpressung zu.

Macht es Microsoft anders?

Mag es Zufall sein oder Absicht: Viele bisherige VMware-Kunden sind Adressaten der Vermarktung von Azure Local durch Microsoft.

Azure Local ist nichts Neues. Schon seit Jahren bietet Microsoft mit Azure Stack für OnPrem-Rechenzentren eine Technologie an, mit der Organisationen ihre RZ-Ressourcen wie die von Azure bekannte Infrastruktur betreiben können. Damit ist Microsoft nicht allein. Auch Amazon Web Services (AWS) gibt es als OnPrem-Variante, genannt AWS Outposts. Das Pendent bei Google heißt Anthos.

Die meisten Organisationen haben jedoch Bedenken gegen eine RZ-Lösung unter der Verwaltung eines Hyperscalers. Denn eine Managed-Service-Lösung eines Cloud-Betreibers bedeutet, dass dieser auf alle Daten und Ressourcen im RZ Zugriff bekommt. Hinzu kommt, dass Amazon bei AWS Outposts dem Kunden keinerlei Mitsprache in der Auswahl von Hardware und Planung der Infrastruktur gewährt.

Microsoft macht es zumindest bei der Hardware-Auswahl und dem RZ-Betrieb anders. Wer Azure Local im eigenen RZ realisieren will, muss die Hardware ohnehin von Hardware-Herstellern beziehen. Die führenden Hersteller von x86-Servern gehören zu den Hardware-Partnern von Microsoft. Der zweite Unterschied zu AWS Outposts: Azure Local kann weitgehend vom Kunden betrieben werden. Die Netz-Verbindung zu Microsoft kann der Kunde darauf beschränken, dass monatlich die Lizenzen verifiziert werden. Die Lizenzverifizierung ist erforderlich, weil Azure-Local-Lizenzen nur auf Subscription-Basis erhältlich sind.

Ansonsten kann man mit Azure Local ein autarkes SDDC aufbauen, das die Microsoft-Lösung für virtuelle Maschinen, Container, Storage-Virtualisierung und virtuelle, segmentierte Netze nutzt. Die Lösung kann mit Werkzeugen wie Azure Arc betrieben werden, die Azure-Kunden bekannt sind.

Risiko der Abhängigkeit von einem Hersteller

Eingangs habe ich auf meine Bedenken gegen proprietäre Lösungen hingewiesen. Wenn es einer Bestätigung solcher Bedenken bedurfte, gibt es sie spätestens seit der neuen Preispolitik von Broadcom/VMware. So stellt sich die Frage, ob eine Abhängigkeit von Microsoft nicht genauso riskant ist wie die Abhängigkeit von einem beliebigen anderen Hersteller.

Die Antwort auf diese Frage kann nicht anders ausfallen als die Antwort auf die entsprechende Frage bei jedem anderen proprietären Szenario. Die Kunden, die sich auf Azure Local einlassen, müssen das Risiko der Abhängigkeit von Microsoft berücksichtigen und bewerten. Microsoft kann genauso wie Broadcom jederzeit an der Preisschraube drehen oder Lösungen abkündigen. Viele Microsoft-Kunden werden jedoch bei ihrer Bewertung dem Umstand Rechnung tragen, dass es die Abhängigkeit von Microsoft ohnehin schon gibt.

Es empfiehlt sich, bei jeder Entscheidung für ein proprietäres Szenario die Frage nach der Exit-Strategie zu beantworten. Die Beendigung der Nutzung von Azure Local (aus welchem Grund auch immer, zum Beispiel wegen denkbarer Preiserhöhungen) kann mit folgenden Maßnahmen einhergehen:

• Planung von Ersatzlösungen für Compute, Storage, Netz und Security
• Reduzierung der Hardware-Basis von Azure Local und schrittweise Umwidmung der x86-Hardware
• Schrittweise Reduzierung des lizenzierten Umfangs
• Schrittweise anderweitige Nutzung der Netz-Hardware

Fazit

Aus meiner Sicht ist das Risiko der zusätzlichen Abhängigkeit von Microsoft im Falle von Azure Local beherrschbar. Microsoft hat die Schwelle für die Entscheidung zugunsten dieser Lösung gesenkt, weshalb ich bei Azure Local von einem disruptiven Potenzial ausgehe. Dieses Potenzial kann Realität werden – oder auch nicht.