Viele Unternehmen wünschen sich die Vorteile der Cloud auch im eigenen Rechenzentrum, insbesondere wenn sie bestimmte Applikationen und Services nicht in die Public Cloud migrieren können. Damit Unternehmen im eigenen RZ dieselben Technologien nutzen können wie in der Cloud, bieten Microsoft mit Azure Stack und AWS mit Outposts zertifizierte Komplettlösungen an. LANline hat analysiert, für welche Einsatzzwecke sich die beiden Plattformen eignen und in welchen Punkten sie sich voneinander unterscheiden.

Es gibt verschiedene Gründe, warum ein Unternehmen Anwendungen nicht zu einem Cloud-Anbieter auslagern möchte. So darf das IT-Team besonders sensible Daten oft aus Sicherheitsgründen nicht in der Cloud speichern. Auch große Datenmengen, wie sie in Produktionsanlagen anfallen, verarbeitet man am schnellsten direkt vor Ort. Für Anwendungen, die eine sehr niedrige Latenz der Datenzugriffe benötigen, ist eine lokale Verarbeitung ebenfalls in vielen Fällen die einzige Option. Für derartige Anforderungen bietet Microsoft mit Azure Stack bereits seit mehr als zwei Jahren eine Lösung aus zertifizierter Hard- und Software an, mit der Unternehmen Azure-Cloud-Services im eigenen RZ betreiben können.

Amazon Web Services (AWS) hat vor einem Jahr mit Outposts eine Lösung angekündigt, die in eine ähnliche Richtung zielt. Sie stellt die für lokal laufende Anwendungen erforderlichen AWS-Services auf einer von AWS gelieferten Hardware im Unternehmens-RZ bereit. Outposts soll ab Ende 2019 allgemein verfügbar sein.

Der große Vorteil beider Plattformen ist die nahtlose Integration der Vor-Ort-Cloud-Systeme mit der Public Cloud des jeweiligen Anbieters, um eine Hybrid Cloud zu implementieren, das derzeit favorisierte Cloud-Modell. Unternehmen können ihre Cloud-Anwendungen so vor Ort im eigenen RZ laufen lassen. Public und Private Cloud nutzen dabei dieselben Entwicklungs-Tools, Services und Anwendungen. Der auf der lokalen Cloud-Plattform entwickelte Code lässt sich ohne Änderungen auf den Public-Cloud-Systemen ausführen. In umgekehrter Richtung funktioniert dies ebenso.

Dieser LANline-Artikel konzentriert sich auf die derzeit weltweit wie auch im deutschen Markt größten Cloud-Anbieter AWS und Microsoft Azure. Google baut sein Cloud-Angebot auch in Deutschland stark aus, liegt aber bei den Marktanteilen noch deutlich zurück. Auf die Hybrid-Cloud-Lösung Google Cloud Anthos geht der Text deshalb im Folgenden nicht näher ein.

Microsoft Azure Stack ist eine zertifizierte Hardwarelösung, die von OEM-Partnern wie HPE erhältlich ist. Bild: HPE

IaaS und PaaS

Bei der Festlegung einer Cloud-Strategie spielt es eine wichtige Rolle, ob die Cloud für Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder beides zum Einsatz kommen soll. Die reine Auslagerung von VM-Workloads in die Cloud per IaaS bringt oft keine signifikanten Kostenvorteile. Das volle Potenzial von Cloud-Services lässt sich nur ausschöpfen, wenn Anwendungen per PaaS bereitstehen. Dazu gilt es, die Unternehmensanwendungen anzupassen oder umzuschreiben, damit sie zum Beispiel als Micro-Services in Containern laufen können. Ein großer Vorteil von PaaS liegt in der sehr viel einfacheren Skalierbarkeit.

Eine IaaS-Architektur stellt zusätzlich benötigte Leistung durch Hinzufügen weiterer VMs bereit. Jede VM verfügt über ein Betriebssystem, das verwaltet und regelmäßig aktualisiert sein will. Bei PaaS dagegen erhält die Anwendungsplattform zusätzliche Hardwareressourcen durch Hinzufügen weiterer Bare-Metal-Hosts und lässt sich so sehr einfach und mit wenig Overhead skalieren. Die derzeit populärste Lösung ist hier die ursprünglich von Google entwickelte Open-Source-Plattform Kubernetes. Sie ermöglicht ein Serverless Computing, bei dem Anwendungen als Laufzeitumgebung kein Windows- oder Linux-Betriebssystem mehr benötigen, sondern in schlanken Containern laufen, die plattformübergreifend einsetzbar sind.

Bei beiden Konzepten ist Infrastructure as Code (IaC) wichtig für eine effiziente Bereitstellung der Cloud-Services. Denn mit IaC lassen sich komplexe Infrastrukturen automatisiert bereitstellen und aktualisieren. Die Grundlage für IaC stellt eine leistungsfähige Software-Pipeline mit Dev-Ops-Methoden für eine schnelle, agile Anwendungsentwicklung bereit. Mit Outposts und Azure Stack können Unternehmen IaaS wie auch PaaS nutzen. So ist auch eine sanfte Migration von IaaS zu PaaS möglich. Für die im eigenen RZ laufenden Workloads kommen dieselbe Infrastrukturplattform, dieselben Entwicklungs- und Management-Tools sowie dieselben Services zum Einsatz wie für die Workloads in der Public Cloud.

Durch diese enge Integration lässt sich im Idealfall von außen gar nicht feststellen, ob eine Workload in der Cloud oder im eigenen RZ läuft. AWS und Microsoft stellen bislang nur eine Teilmenge der in ihren Clouds verfügbaren Services für die Vor-Ort-Nutzung bereit. Dies wird sich wohl auch in Zukunft nicht ändern, weil Cloud-Provider das Interesse haben, so viele Workloads wie möglich in ihre eigene Cloud zu transferieren. Die lokale Cloud-Plattform kommt nur dann zum Einsatz, wenn Anwendungen sich nicht für die Public Cloud eignen.

AWS Outposts verwendet die gleiche Nitro-Hardware wie die AWS-Cloud-Systeme. Die Server liefert AWS selbst. Bild: AWS

Einsatzszenarien

Ein wichtiger Unterschied zwischen Outposts und Azure Stack besteht darin, dass Outposts immer eine Extension einer AWS-Region ist und permanent mit der AWS-Cloud verbunden sein muss. Für eine Offline-Nutzung von AWS-Services bietet AWS die Lösung Snowball Edge an. Azure Stack dagegen lässt sich mit und ohne Azure-Anbindung nutzen und kann zum Beispiel auf Schiffen oder U-Booten, bei Forschungseinsätzen in entlegenen Regionen oder für militärische Zwecke zum Einsatz kommen. Auch eine reine Private-Cloud-Nutzung, zum Beispiel für ein abgeschottetes Unternehmens-Intranet oder für Anwendungen mit sensiblen Daten, die das Unternehmen nicht verlassen dürfen, ist mit Azure Stack im Disconnected Mode möglich.

Der Betrieb nativer Cloud-Services im eigenen RZ kann für Unternehmen unterschiedlicher Branchen sinnvoll sein, etwa für Produktionsbetriebe, Energieversorgung, Handel, Gesundheit, Wissenschaft oder die öffentliche Hand. Einer der wichtigsten Treiber für den Vor-Ort-Betrieb sind Programme, die eine sehr niedrige Latenz der Datenzugriffe erfordern. Dies können zum Beispiel Produktionssysteme sein, deren Daten in Echtzeit zu verarbeiten sind. Auch mit grafikintensiven Anwendungen, die auf sehr große Datenmengen zugreifen, können die Benutzer direkt vor Ort am besten arbeiten.

Für Standorte mit einer geringen WAN-Bandbreite kann ein lokales Cloud-System ebenfalls die passende Lösung sein. Beide Hersteller bieten zudem Lösungen für Edge- und IoT-Szenarien (Internet of Things) an, die Gerätedaten vor Ort verarbeiten und in die Cloud übertragen. Microsoft hat hierfür den Azure IoT Hub und die Azure Data Box Edge im Portfolio, AWS deckt derartige Szenarien mit der erwähnten Lösung Snowball Edge und mit IoT Greengrass ab.

Ein weiterer Grund, Cloud-Anwendungen im eigenen RZ laufen zu lassen, sind Sicherheitsanforderungen oder regulatorische Vorgaben, die etwa im Finanzsektor sehr weitreichend sind. So kann ein weltweit agierendes Unternehmen, das an allen Standorten dieselbe Cloud-Anwendung einsetzen möchte, für Standorte ohne strenge Vorschriften die Public Cloud als Plattform nutzen. In Ländern mit speziellen Datenhaltungsregularien kann dieselbe Anwendung auf einem Azure-Stack- oder Outposts-System laufen, das die Kundendaten lokal speichert. Auf allen Anwendungssystemen wird genau derselbe Code ausgeführt, was zusätzlichen Entwicklungsaufwand vermeidet.

Ergänzung gefragt: AWS-Outposts-Systeme müssen als Extension einer AWS-Region an die AWS-Cloud angebunden sein. Bild: AWS

Lokal verfügbare Cloud-Services

Wie erwähnt, unterstützen beide Plattformen im eigenen RZ nur einen Teil der Public-Cloud-typischen Services. Dazu zählt die Bereitstellung virtueller Server-Instanzen, die sich auf lokalem Storage speichern lassen. Der Private-Cloud-Stack enthält auch die komplette Netzwerkinfrastruktur mit virtuellen und physischen Netzen sowie Gateways zur Verbindung mit der Außenwelt. AWS Outposts umfasst zunächst die Dienste RDS (Relational Database Services), ECS (Elastic Container Service), EKS (Elastic Kubernetes Service) und EMR (Elastic Map Reduce) für Big-Data-Analysen.

In naher Zukunft sollen zudem SageMaker (Machine Learning), MSK (Managed Streaming for Apache Kafka) und ELB (Elastic Load Balancing) für Outposts nutzbar sein. Für die Verwaltung stehen die Management- und Automatisierungs-Tools EC2 Auto Scaling Groups, AWS Cloud Formation sowie Elastic Beanstalk zur Verfügung. Das Monitoring ist mit Cloud Watch und Cloud Trail möglich.

Neben der nativen Cloud-Variante bietet AWS die Lösung auch als VMware Cloud on AWS Outposts an. Damit lassen sich Outposts-Systeme mit denselben Steuerungswerkzeugen und APIs verwalten wie die seit 2017 verfügbare Lösung VMware Cloud on AWS, mit der Unternehmen ihre eigene vSphere-Umgebung in die AWS-Cloud erweitern oder komplett in der Cloud betreiben können. Das Angebot umfasst ein VMware SDDC (Software-Defined Datacenter) mit vSphere, NSX, vSAN, und vCenter. Die Outposts-Systeme verwaltet man remote per vCenter, das auf der VMware Cloud on AWS läuft und sich über den vCenter Hybrid Linked Mode mit privaten vSphere-Cloud-Umgebungen verbinden lässt. Bei der VMware-Outposts-Variante ist AWS nur für die Hardware zuständig, die VMware-Cloud-Lösung betreibt VMware selbst.

Auch Microsoft bietet in der Azure Cloud eine Lösung für VMware vSphere an, damit Unternehmen die in den eigenen RZ auf einer VMware-Plattform laufenden VMs einfach zu Azure migrieren können. Mit Azure Stack lässt sich bereits ein großer Teil der im Azure Marketplace vorhandenen Services nutzen. Zum Funktionsumfang zählen Datenbanken, Container-Services, Azure Functions, Service Fabric, Key Vault und der Azure App Service. Demnächst sollen zudem Kubernetes, SQL Server 2019, Event Hubs, IoT Hub, Azure Stream Analytics, Cognitive Services und ein Blockchain Template auch für Azure Stack verfügbar sein.

Mit den neuen nativen Hybrid-Cloud-Lösungen ändert sich die Art der Integration zwischen Public- und Private-Cloud-Systemen. Ging es bislang darum, die im eigenen RZ betriebene Virtualisierungsplattform über Schnittstellen mit den in die Cloud ausgelagerten Systemen zu verbinden, lassen sich nun von der Management-Konsole der Public Cloud aus Workloads auf den Private-Cloud-Systemen ausrollen und verwalten. Eine Integration der Hybrid Cloud mit anderen Cloud-Anbietern, wie sie bei Google Cloud Anthos möglich ist, unterstützen AWS und Microsoft bislang nicht.

Azure Stack stellt dieselben Werkzeuge und Services wie Azure bereit, sodass Anwendungen auf beiden Plattformen unverändert lauffähig sind. Bild: Microsoft

AWS Outposts

AWS verwendet für Outposts die gleichen Nitro-Hardwaresysteme, die auch in der Public Cloud zum Einsatz kommen. AWS überwacht und verwaltet die Outposts-Infrastruktur komplett selbst, inklusive System- und Software-Updates. Outposts-Systeme müssen deshalb immer mit einer AWS-Region verbunden sein. Ein Nitro-System besteht aus zwei voneinander getrennten physischen Servern. Der kleinere Server läuft auf einer Spezialhardware, die alle Netzwerk-, Storage-, Management-, Monitoring- und Security-Funktionen steuert. Darüber erfolgen auch die Zugriffe der AWS-Betriebseinheiten auf die Outposts-Infrastruktur.

Der größere Server enthält einen schlanken Nitro-Hypervisor, der die Hardwareressourcen für die Kunden-Workloads bereitstellt. Der Nitro-Hypervisor ersetzt den früher noch erforderlichen Xen-Hypervisor. In der VMware-Cloud-Variante von Outposts laufen die Server mit dem ESXi-Hypervisor. Die Kundenanwendungen können die in der jeweiligen AWS-Region verfügbaren Services und Schnittstellen nutzen. Für den Kunden stellt sich Outposts in der AWS-Konsole wie ein normales AWS-Subnetz dar.

AWS liefert die Outposts-Hardware und baut sie auf. Künftig ist auch eine Zusammenarbeit mit AWS-Partnern denkbar. Die Ausbaustufen reichen von einem Viertel-Rack über ein halbes und ein ganzes Rack bis zu mehreren Racks. Technisch gibt es bei der Skalierbarkeit keine Obergrenze. Zum Lieferumfang gehören auch ToR-Switches (Top of the Rack). Die Hardware ist modular und redundant aufgebaut, um defekte Teile schnell ersetzen zu können. Für den Hardware- und Software-Support sowie die Migration auf neuere Hardwaregenerationen und EC2-Instanzen ist AWS zuständig. Die Inbetriebnahme von Outposts ist relativ einfach.

Die von AWS gelieferten Server werden mit der Stromversorgung und dem Netzwerk verbunden. Beim ersten Hochfahren holen sich die Nitro-Server automatisch ihre Konfiguration aus der AWS-Region, für die das Outposts-System bestellt und konfiguriert ist. Die Verbindung mit der Public Cloud erfolgt über AWS Direct Connect oder über das öffentliche Internet per VPN. Fällt die WAN-Verbindung des Outposts-Systems zur AWS-Cloud vorübergehend aus, funktioniert die Control Plane nicht mehr. Die lokalen Workloads laufen aber ohne Unterbrechung weiter. Um die auf dem Outposts-System gespeicherten Daten zu sichern, stehen die Standarddienste von AWS sowie Lösungen von Drittanbietern zur Verfügung. Gleiches gilt für das Notfall-Management, das zum Beispiel durch eine Replikation von Instanzen in die AWS-Cloud möglich ist.

Azure Stack

Die „Cloud in a Box“-Lösung Azure Stack ist ausschließlich als zertifiziertes Hardwaresystem über Microsoft-OEM-Partner wie HPE, Dell EMC, Cisco, Lenovo oder Fujitsu erhältlich. Der Kunde kann die Lösung selbst betreiben oder als Managed Service von einem Provider bereitstellen lassen. Vor der Installation der Azure-Stack-Infrastruktur muss er entscheiden, ob das Azure AD (Active Directory) oder ADFS (Active Directory Federated Services) zum Einsatz kommen soll. Will man ein Azure-Stack-System mit mehreren Mandanten nutzen, muss man Azure AD wählen – ein nachträglicher Wechsel des Directory-Diensts ist nicht möglich.

Die Einstiegslösung von Azure Stack besteht aus vier Servern, maximal werden derzeit 16 Nodes pro Stack unterstützt. Idealerweise sollte man die Umgebung nicht mit einzelnen Nodes, sondern in Viererschritten erweitern, damit Lastverteilung und Datenspeicherung im S2D-Cluster (Storage Spaces Direct) optimal funktionieren. Die Azure Cloud verwendet aus technischen Gründen andere Storage- und Hochverfügbarkeitslösungen als die für Azure Stack genutzten Server.

Um die Sicherheit des Azure-Stack-Systems zu erhöhen, hat der Kunde keinen Zugriff auf die internen Administratorkonten. Auch die Konsolen für die Hyper-V- und Cluster-Verwaltung stehen nicht zur Verfügung. Die im Stack aktiven Netzwerk-Switches blockieren unautorisierte Zugriffe mittels ACLs (Access Control Lists). Es ist zudem unmöglich, eigene Agenten zum Beispiel für das Monitoring zu installieren. Die Kommunikation mit Azure-Stack-Systemen erfolgt nur via PowerShell und REST-API. Der Azure Stack Operator verwaltet das System per Azure Administrator Portal oder Azure Resource Manager.

Überwachung per HLH

Der OEM-Lieferant stellt für Azure Stack einen externen Hardware Lifecycle Host (HLH) bereit, der die Hardware überwacht. HLH lässt sich mit den im Unternehmen vorhandenen agentenlosen Management-Lösungen integrieren. Das HLH-System stellt auch die Deployment-VM bereit, um die Azure-Stack-Infrastruktursysteme zu installieren. Auf Azure-Stack-Systemen laufen mehr als 40 VMs, die unter anderen Domain Controller, Load Balancer und Gateways bereitstellen. Die Verbindung mit der Azure Public Cloud kann per Express Route über eine nicht-öffentliche WAN-Strecke erfolgen oder via Internet-VPN. Bei der Internetanbindung ist zu beachten, dass Azure Stack bisher nur transparente Internet-Proxy-Server mit direkter Authentifizierung unterstützt.

Microsoft stellt für Azure Stack monatliche Updates zur Verfügung, die das Administratorportal anzeigt. Die Aktualisierung führt das System automatisch durch. Für die Sicherung der auf dem Azure-Stack-System gespeicherten Daten und virtuellen Instanzen dienen Microsoft-Tools oder Produkte anderer Hersteller. Eine Replikation wird bislang nur von Azure Stack zu Azure unterstützt. Falls Probleme auftreten, die sich nicht ohne den Microsoft-Support lösen lassen, erhält der Support-Mitarbeiter vom Kunden einen Schlüssel für den Remote-Zugriff mit vollen administrativen Rechten, der vier Stunden gültig ist.

Mit Azure Stack HCI (Hyper-Converged Infrastructure) bietet Microsoft eine weitere Hardwarelösung an, die von zertifizierten OEM-Partnern erhältlich ist. Sie basiert ebenfalls auf Windows Server 2019, Hyper-V und S2D, stellt aber keine nativen Azure-Services bereit. Die Azure-Integration erfolgt bei dieser Plattform über das Windows Admin Center und die in Windows Server 2019 integrierten Azure-Schnittstellen.

Fazit

Mit AWS Outposts und Microsoft Azure Stack können Unternehmen die Cloud ins eigene RZ holen. Beide Lösungen ermöglichen den Aufbau einer Hybrid Cloud, die durchgängig dieselben Werkzeuge für Entwicklung, Automatisierung und Management nutzt. Damit lassen sich Anwendungen ohne Code-Änderungen sowohl in der Public Cloud als auch in der Private Cloud einsetzen. Die Vor-Ort-Variante ermöglicht es zudem, latenzsensitive und datenhungrige Anwendungen auf Cloud-Systemen zu betreiben. Ihr volles Potenzial entfalten Cloud-Lösungen, wenn die Anwendungen als PaaS laufen und von der damit verbundenen Flexibilität und Skalierbarkeit profitieren.

Um das Budget der IT-Abteilungen zu schonen, ist Microsoft Azure Stack auch im „Pay per Use“-Modell erhältlich: Zum Beispiel bietet HPE mit Greenlake eine entsprechende Lösung an. Für den Disconnected Mode von Azure Stack ist das kapazitätsabhängige Kaufmodell obligatorisch. Amazon Web Services hält sich zu den Preisen für Outposts bislang noch bedeckt. Es ist davon auszugehen, dass AWS mit der für Ende 2019 angekündigten allgemeinen Verfügbarkeit Abrechnungsmodelle und Preise veröffentlicht. 

Christoph Lange.