Microsofts Sicht auf die Cloud: Windows Azure im Praxistest

Bereits seit dem 1. Januar 2010 ist Windows Azure im Produktivbetrieb. Mit seinen Clouddiensten will Microsoft Amazon Konkurrenz machen. Doch bisher spielt Microsoft eine eher kleine Rolle beim Hosting von Cloudfarmen und ist weit davon entfernt, Amazons Dominanz ernsthaft zu gefährden.

Während man bei Amazon virtuelle Linux- und Windows-Server buchen kann, gibt es bei Microsoft Azure nur Windows-Server. Grundsätzlich ist der Markt für Windows-Hosting kleiner als der für Linux. Das belegen die neuesten Zahlen von Netcraft.

Seit September 2008 ist der Marktanteil von Microsofts Webserver IIS von etwa 20 Prozent auf 15,8 Prozent im Juni 2011 gefallen. Auch Apache musste in diesem Zeitraum ein bis zwei Prozentpunkte einbüßen, allerdings hauptsächlich auf Kosten von nginx (gesprochen Engine X), einem HTTP-Server, der für seine hohe Performance bekannt ist. Obwohl Apache und nginx auch auf Windows laufen, ist dieser Anteil verschwindend gering.

Für Windows-Hosting sprechen die ausgezeichneten Entwicklungswerkzeuge, die für die .NET-Sprachen, vor allem C# und Visual Basic, zur Verfügung stehen. Auch die Dokumentation ist ausgezeichnet. Mit der MSDN-Library können die meisten anderen Anbieter von Entwicklungswerkzeugen nicht mithalten.

Nicht zu verachten ist die Tatsache, dass die .NET-Sprachen, anders als etwa PHP, Ruby oder Pearl, letztendlich in nativen Code kompiliert werden. Das bringt Geschwindigkeit und spart Ressourcen. Trotzdem lässt sich Code notfalls einfach in Webseiten schreiben, was eigentlich nicht den Prinzipien sauberer Entwicklung entspricht, aber in der Praxis auf Test- und Staging-Servern oft genutzt wird.

Von Azure als Clouddienst wird oft angenommen, dass es nur dazu dient, .NET-Anwendungen mit einem Webfrontend laufen lassen, aber der Kunde keine volle Kontrolle über seine Serverinstanzen besitzt. Das ist allerdings so nicht richtig. Eine Azure-Instanz besteht aus einem vollständigen virtuellen Server, der unter Hyper-V betrieben wird. So ist es beispielsweise möglich, sich mittels Remote-Desktop-Client mit vollen Administratorrechten einzuloggen.

Allerdings handelt es bei einer Standard-Azure-Instanz um einen Virtual Managed Server, bei dem Betriebssystemupdates von Microsoft kommen. Unter Linux bekommt man in so einem Fall meist keinen SSH-Zugang mit Root-Rechten.

Wer an einer virtuellen Maschine selbst etwas konfiguriert, verliert seine Änderungen, sobald man auf eine neue Version des Gast-Betriebssystems wechselt. Dieser Wechsel muss zwar vom Kunden angestoßen werden, ist aber ab und zu notwendig: Zum einen, um aktuelle Sicherheitsupdates zu bekommen, zum anderen sind neue Azure-Features meist nur ab einer bestimmten Gastbestriebssystemversion möglich.

Das heißt, in der Praxis ist man auf eine Standard-Konfiguration von Microsoft angewiesen und kann keine Änderungen vornehmen, etwa an Performance-Tuning-Parametern. Es sei denn, man veranlasst das erneut nach jedem OS-Upgrade selbst, etwa via Scripts.

Aktuell ist ein Feature in Beta, mit dem man eigene Hyper-V-Images zu Azure hochladen kann. Das konnte ZDNet allerdings noch nicht testen. Einer Bitte um Aufnahme in das Beta-Programm wurde nicht entsprochen.

Die Namen der Gastbetriebssysteme sind gewöhnungsbedürftig: Microsoft unterscheidet zwischen Azure-Guest 1.x und 2.x, wobei man eigentlich nur wissen muss, dass es sich bei Version 1.x um Windows Server 2008 und bei 2.x um Windows Server 2008 R2 handelt, jeweils in der 64-Bit Enterprise Edition.

Aktuell sind die beiden Betriebssysteme 1.13 und 2.5. Beide sind auf April 2011 datiert, was nicht gerade darauf schließen lässt, dass Microsoft jeden Patchday in seine Azure-Gastbetriebssysteme einfließen lässt, obwohl es Firmenadmins geradezu beschwört, genau das zu tun.

Azure und Amazon AWS

Zwischen Azure und Amazon AWS gibt es auffällige Gemeinsamkeiten. So tragen die einzelnen Instanztypen dieselben Namen wie "Small", "Large" und "ExtraLarge". Sie sind vom Hauptspeicher und vom lokalen Plattenplatz her identisch ausgestattet. Zudem kosten sie auf den Cent genau denselben Preis.

Unterschiede gibt es allerdings in der CPU-Leistung: Amazon bietet bietet sogenannte EC2 Compute Units an, die etwa 1 GHz einer modernen CPU entsprechen. Bei Azure zeigt die Leistungsmessung von ZDNet, dass man eine gebuchte CPU allein für sich nutzen kann, obwohl Microsoft nur 1 GHz (ExtraSmall-Instanz) beziehungsweise 1,6 GHz (alle anderen Instanzen) verspricht. Derzeit setzt Microsoft den Opteron 2377 EE von AMD ein. Er entspricht von der Leistung etwa einer Core-2-CPU von Intel und ist mit 2,1 GHz getaktet.

Wer bei Azure eine ExtraLarge-Instanz bucht, bekommt eine virtuelle Maschine mit acht Cores zu 2,1 GHz. Bei Amazon gibt es bei der ExtraLarge-Instanz nur vier virtuelle Cores mit 2 EC2-Einheiten, was etwa 4×2 GHz entspricht. Amazon setzt Core-2-Xeon-CPUs der Reihe 54xx ein.

Azure in der Praxis

Azure zeichnet sich dadurch aus, dass man nicht nur einfach Instanzen mieten und starten kann, sondern in Verbindung mit Visual Studio 2010 kümmert sich Azure auch um die Verteilung der Anwendung auf die einzelnen Instanzen.

ZDNet macht dazu einen Test auf Praxistauglichkeit: Grundsätzlich reicht es aus, sich einen Azure Account zu beschaffen. Ein Einführungsangebot erlaubt die kostenlose Nutzung einer ExtraSmall-Instance für einen Monat (750 Stunden). Außerdem kann man eine Small-Instance einen Tag (25 Stunden) lang testen.

Grundsätzlich reicht es aus, Visual Studio 2010 und die kostenlosen Azure-Tools zu installieren. Wer bereits Visual Studio 2010 SP1 installiert hat, braucht nicht lange zu warten, bis sein Entwicklungssystem fertig ist. Ansonsten muss man sich auf eine längere Installation vorbereiten.

Mit den installierten Azure-Tools kann man Projekte in Visual Basic, C# und mit Einschränkungen auch in F# direkt für das Deployment in Azure konfigurieren. Andere Sprachen wie C++ werden nicht explizit unterstützt.

Die erste kleine Azure-App ist schnell geschrieben. Um sie lokal auszuprobieren, wird der sogenannte Azure-Emulator verwendet. Dazu muss man kein Serverbetriebssystem verwenden, es reicht Windows Vista oder Windows 7, wobei es durchaus sinnvoll ist, Windows 7 zu verwenden, wenn die Anwendung später auf einer Azure-2.x-Instanz (Windows Server 2008 R2) laufen soll.

Es lässt sich sogar ein 32-Bit-Windows als Entwicklungsumgebung nutzen. Das führt allerdings zu einer Warnung, dass es Kompatibilitätsprobleme geben könnte.

Den ersten Test der lokalen App führt ZDNet auf einem Core-2-Laptop mit 3 GByte Hauptspeicher aus. Diese Maschine ist dafür eindeutig zu schwach dimensioniert. Visual Studio, der Azure-Emulator mit SQL Server und IIS sowie ein Browser führen dazu, dass der PC in der Performance einbricht. ZDNet wechselt daher auf einen MacPro mit zwei Quad-Core-CPUs und 16 GByte Hauptspeicher. Damit gibt es keine Performance-Probleme.

Wenn man mit seiner App zufrieden ist, kann man sie zu Azure hochladen. Das geschieht mit ein paar Mausklicks aus Visual Studio heraus. Falls die notwendigen Instanzen nicht existieren, werden sie angelegt.

Azure unterscheidet zwischen "Production Instances" und "Staging Instances". Die Staging Instances sollen zum Test dienen, bevor man sie endgültig in den Produktivbetrieb nimmt. Das ist immer notwendig, denn zwischen dem Azure Emulator und der echten Hostingumgebung gibt es teilweise erhebliche Unterschiede. Das gilt für den Storage Emulator genauso wie für den Compute Emulator.

ZDNet eröffnet eine Instanz in der Staging-Umgebung. Das führt zu einer Warnung, dass mit nur einer laufenden Instanz das SLA von 99,95 Prozent Verfügbarkeit nicht eingehalten werden könne. Für einen Test ist das jedoch nicht problematisch. Das Anlegen der Instanz dauert verständlicherweise eine gewisse Zeit. Danach zeigt sich allerdings, dass die Webanwendung einwandfrei funktioniert.

Wenn man jedoch eine Kleinigkeit ändert und die App erneut hochlädt, erkennt man die Probleme von Azure. Nach dem Hochladen ins Rechenzentrum dauert es 4 Minuten und 33 Sekunden bis das Azure-System die Anwendung auf nur einer Instanz upgedatet hat.

Dabei handelt es sich nur um eine Mini-App mit drei HTML-Seiten, von denen zwei völlig statisch ohne jeden Code sind. Das ist einfach zu lange. Ab einem gewissen Entwicklungsstadium kann man nicht mehr lokal testen. Dann muss eine App gegen die echte Datenbank laufen und nicht gegen die Demo-Version auf dem lokalen Rechner. Ferner gilt es, Probleme zu beseitigen, die durch Inkompatibilitäten des Emulators verursacht werden.

Ein Entwickler, der jedes Mal über vier Minuten warten muss, bis seine Änderungen sichtbar sind, wird dieses System verfluchen. Man kann sich jedoch mit dem nachträglich eingebauten Feature Web Deploy behelfen. Dann lädt Visual Studio Änderungen direkt auf die Instanzen, anstatt das Azure zu überlassen. Allerdings gibt es dabei Sicherheitsprobleme. Sensible Daten dürfen so nicht übertragen werden, sagt eine Warnung in Visual Studio 2010.

ZDNet kann noch weitere Probleme feststellen: Falls eine Instanz ausfällt, bekommt Azure davon gar nichts mit. ZDNet fährt eine Instanz manuell mit einem sauberen Shutdown herunter. Auch eine halbe Stunde später wird im Control Panel noch "Ready" angezeigt. Ein gewisses Basismonitoring hätte man eigentlich erwarten sollen.

Limits

Eigentlich ist Azure vor allem für große Unternehmen gedacht, um Inter- und Intranet-Dienste in der Cloud zu betreiben. Doch wer sein Azure-Konto erstmalig benutzt, sieht sich mit engen Grenzen konfrontiert. Man kann maximal 20 Cores nutzen und höchsten sechs Apps deployen.

Vor allem die Cores sind ein Problem. Wer eine Anwendung auf Medium-Instanzen laufen lassen will, braucht bereits mindestens sechs Cores. Jede Medium-Instanz enthält zwei Cores. Da man realistisch gesehen mindestens zwei Produktiv-Instanzen und eine Staging-Instanz benötigt, sind bereits sechs von 20 Cores verbraucht. Viele Apps lassen sich so nicht in die Cloud bringen.

Wer seine Limits angehoben haben möchte, muss den Support anrufen und eine "Business Justification" nennen. Außerdem muss er seine Bonität nachweisen. ZDNet konnte allerdings in Erfahrung bringen, dass Microsoft die Limits nur ungern anhebt, weil man dem System noch nicht zutraut, hunderte von Instanzen einer einzigen App zu verwalten. Nach "Enterprise Ready" klingt das nun wirklich nicht.

Storage und Networking

Neben den virtuellen Compute-Instanzen bietet Microsoft zahlreiche Storage- und Netzwerkdienste an. Jede Compute-Instanz hat zunächst einen lokalen Store, der auch nach einem OS-Upgrade erhalten bleibt. Technisch gesehen ist das die C:-Partition, das OS ist bei Azure auf D: installiert. In einer Small-Instanz hat man 225 GByte zur Verfügung, die ExtraLarge-Instanz bietet knapp 2 TByte (2040 GByte).

Darüber hinaus gibt es den Blob-Storage, der in etwa Amazons S3-Speicher entspricht. Dort lassen sich auch Disk-Images anlegen, die man von einer Instanz als Drive-Storage mounten kann, allerdings kann ein Block-Device immer nur von einer Instanz gemountet werden.

Datenbanken werden in der Regel nicht in einer Instanz betrieben. Dafür nutzt man die Azure-Datenbank, bei der es sich technisch um Microsoft SQL Server handelt. Alle Instanzen können darauf zugreifen. Auch einige Spezialspeicher hat Microsoft implementiert, etwa den Queue Storage, der dazu dient, Nachrichten nach dem FIFO-Prinzip an alle Instanzen zu senden.

Wer möchte, kann ein Virtual Network einrichten, allerdings ist auch dieses Feature noch in der Beta-Phase. Mit dem virtuellen Netzwerk lassen sich nicht nur Instanzen untereinander verbinden, sondern über ein VPN auch mit dem Intranet. Das macht es leichter, Dienste von Intranet-Servern in die Cloud zu verlagern.

Gegen Aufpreis lassen sich Inhalte, wenn diese relativ statisch sind, auch einem Content Distribution Network (CDN) zur Verteilung übergeben. Für dynamischere Inhalte bieten sich die Cache-Dienste an, die fertig zusammengesetzte HTML-Seiten zwischenspeichern. Das entlastet die Datenbank erheblich, etwa wenn zahlreiche Nutzer eine Preisliste aus einem Webshop abrufen, die sich nur einmal am Tag ändert.

Fazit

Windows Azure erhebt den Anspruch, für große skalierbare .NET-Anwendungen bereit zu sein. Dafür stellt Microsoft in der Tat zahlreiche Werkzeuge und Services bereit, etwa Caching- und CDN-Dienste.

Auf der anderen Seite müssen die Redmonder noch viel tun. Viele Dienste wie virtuelle Netzwerke oder das Hochladen eigener Images sind nur in einer Beta-Version verfügbar. Die Verteilung von Anwendungen auf die Instanzen dauert viel zu lange. In der Praxis ist das völlig untauglich, denn oft muss auch an einem Live-System schnell etwas gefixt werden. Mit "Druck von oben" wird die Wartezeit für den Entwickler zur Qual.

Was auch nicht gerade für Skalierbarkeit spricht, sind die Limits, die in jedem Azure-Account implementiert sind. Gerade einmal 20 Cores kann man nutzen. Bei einer großen Anwendung kommt man damit nicht weit. Microsoft will diese Limits nur ungern anheben. Über die Gründe dafür kann man nur spekulieren: Möglicherweise spielt der Datenbankdienst nicht mit, wenn tatsächlich mehr als hundert Instanzen intensiv darauf zugreifen.

Derzeit eignet sich Azure nur für mittelgroße Anwendungen, das heißt für mittelständische Unternehmen und Abteilungsdienste großer Unternehmen. Amazon muss vorerst keine Konkurrenz durch Azure fürchten – zumindest nicht, was wirklich große Deployments angeht.

Wer mit den Beschränkungen keine Probleme hat und .NET-Anwendungen in der Cloud betreiben will, der bekommt allerdings ein gut abgestimmtes Entwicklungssystem. Anders als bei Amazon-Instanzen muss man sich nicht darum kümmern, dass die Anwendungen auf die Server kommen.

Als .NET-Entwickler arbeitet man mit Visual Studio wie gewohnt und schickt seine Anwendung in die Cloud, wenn sie fertig ist. Sich nicht um bestimmte Details kümmern zu müssen, bedeutet einen nicht zu unterschätzenden Zeitvorteil im Entwicklungszyklus.