Azure Stack

Die Public Cloud im eigenen Rechenzentrum

von - 17.02.2017
Server-Cloud
Foto: Scanrail1 / Shutterstock.com
Microsoft bietet Unternehmen mit Azure Stack die Möglichkeit, die Public Cloud im eigenen Rechenzentrum zu betreiben. Im Vergleich zur klassischen Hybrid Cloud ergeben sich hierdurch viele strategische Vorteile.
Jeder redet von der Hybrid Cloud: Ein bisschen hiervon, ein bisschen davon, schon ist eine schöne Lösung fertig. Hy­brid ist „historisch gewachsen“, zusammengebaut aus einzelnen Angeboten, selten eine große Lösung. Wie sähe es aus, wenn dem nicht so wäre? Etwa durch Azure Stack von Microsoft?
„Azure for your datacenter“ – da ist Microsoft ein starker Slogan eingefallen, über den es aber derzeit noch nicht allzu laut spricht, weil Azure Stack wahrscheinlich erst im Juni verfügbar sein wird. Das ist schade, denn strategisch betrachtet ändert sich einiges.

Wozu Azure Stack?

Azure
Azure: Über 60 Produkte von Virtual Machines bis Backup bietet Microsoft auf seiner Cloud-Plattform an.
Die Chance von Azure Stack liegt in dem Segment, das aktuell nur Microsoft selbst besetzt. Kein anderer Anbieter verfügt über eine Marktrelevanz sowohl im On-Premise-Rechenzentrum als auch in der Public Cloud. Während Amazon und Google nur in der Geschmacksrichtung Public vertreten sind, hat es VMware nicht recht aus der Umgebung beim Kunden herausgeschafft – vCloud Air hat immer noch sehr bescheidene Marktanteile. Alle deutschen Unternehmen arbeiten heute bereits hybrid – freiwillig oder unfreiwillig. Dabei haben sie das Problem, dass „hier“ und „da“ nicht so richtig zusammenspielen wollen. Das geht vom Identity- und Access-Management über das konvertierungsfreie Verschieben von Workloads bis hin zur Vereinheit­lichung von Automatisierungslösungen. Die Komplexität hat so weit zugenommen, dass sich auch die Hauptanforderung an Managed Services gedreht hat: War die Herausgabe von Betriebsdiensten früher den einfachen Regeltätigkeiten vorbehalten, bedeutet Managed (Public) Cloud heute meist die Vergabe von Komplexität an einen externen Dienstleister.

Cloud-Konsistenz

Nichts lag also näher, als eine Lösung zu schaffen, bei der die eigene Umgebung genauso betrieben wird wie die Public Cloud. Voraussetzung ist, dass die gleichen Schnittstellen (APIs) verwendet werden, das Portal zur Bedienung identisch ist und die Funktionen fast deckungsgleich sind. Fast deckungsgleich, da es einiger Teilbereiche von Azure nicht bedarf, etwa einer Express Route ins eigene Rechenzentrum oder einem Azure AD im Keller des Hauses.
Dabei steht fest, dass die kleinste Azure-Stack-Umgebung aus nur vier Knoten besteht. Das ist ein Bruchteil der Ausstattung, die ein Standard-Microsoft-Rechenzentrum umfasst. Diese Konsistenz sorgt dafür, dass im Kleinen möglich ist, was auch Azure im Großen kann: sehr schnell und standardisiert Services bereitstellen, zuweisen und abrechnen. Auf Basis von Vorlagen, Containern und Scripts lassen sich Umgebungen im Handumdrehen erstellen, mit Power­Shell in einen „Selbstheilungsmodus“ bringen und  wieder beenden, je nachdem welche Leistung gerade benötigt wird.
Jörg Mecke
Axians IT Solutions
Foto: Axians IT Solutions
„Mit dem Einsatz von Azure Stack ver­schwimmen Grenzen in jeglicher Hinsicht.“
Diese Cloud-Konsistenz zum großen Azure bedeutet aber auch, dass es eben nur dieses Fabric-Management ist. Azure Stack beinhaltet keinerlei Systems-Management-Komponenten für Monitoring, Patchen der Gastsysteme oder Software-Verteilung in die virtuellen Computer. Ebenso wie in der Public Cloud muss das mit separaten Werkzeugen erledigt werden. Das hört sich ernüchternd an, so wie einige Kunden heute noch glauben, dass mit dem Verschieben einer Maschine in die Public Cloud auch der Betrieb verschoben wird.
Mitnichten kümmert sich Microsoft (genauso wenig wie Amazon, Google und alle anderen) um das „Leben in der Maschine“, sondern sorgt nur bis zur Oberkante des Hypervisors für die beste Methode der Bereitstellung.
Aus Sicht von Microsoft System Center – Marktführer im Bereich Systems Management – heißt es somit: Nur auf den Virtual Machine Manager und den Orchestrator kann verzichtet werden. SCCM und SCOM werden weiterhin benötigt. Insofern ist die Konsistenz in jeder Hinsicht – positiv wie negativ – gelungen.
Verwandte Themen