Windows auf Wolke sieben

Mit der Azure-Plattform steigt Microsoft auf Basis etablierter Technologien wie Windows Server und .NET in den Cloud-Computing-Markt ein.

Artikel erschienen in Swiss IT Magazine 2008/21

     

Das Verschieben von Anwendungen aus der hauseigenen Infrastruktur «in die Cloud» verspricht einige Vorteile. Dazu gehören die niedrigeren Investitionskosten, die man beim Aufbau eines eigenen Data Center zu tätigen hätte, das Outsourcing von lästigen Notwendigkeiten wie Backup, Ausfallsicherheit oder Skalierbarkeit an den Serviceanbieter oder die universellen Nutzungsmöglichkeiten der ausgelagerten Dienste von verschiedenen Geräten und Anwendungen via Internet. Dementsprechend verwundert es nicht, dass gewichtige Anbieter wie Amazon, Google oder IBM damit angefangen haben, entsprechende Cloud-Services anzubieten und laufend damit beschäftigt sind, ihre Infrastrukturen auszubauen und Angebote zu formulieren, über die Firmen ihre Anwendungen in ein hochskalierbares Data Center auslagern können.



Punkto Cloud Computing blieb es um Microsoft lange Zeit ruhig und man musste befürchten, dass der Softwareriese erneut einen wichtigen Trend verschlafen könnte. Dass dem nicht so ist, haben die Redmonder Ende Oktober an ihrer Entwicklerkonferenz PDC 08 gezeigt und die Azure Services Platform angekündigt. Azure ist in zwei Schichten aufgegliedert. Auf der untersten Ebene befindet sich Windows Azure, das die eigentlichen Betriebssystemdienste zum Ausführen von Anwendungen und Speichern von Daten innerhalb eines hochverfügbaren und skalierbaren Rechenzentrums zur Verfügung stellt. Auf der zweiten Ebene befinden sich Anwendungsservices für Aufgaben wie Identity Management, Workflow, Datenmanagement oder Synchronisation. Die verschiedenen Azure-Dienste lassen sich sowohl von Anwendungen, welche in der Cloud ausgeführt werden, als auch von lokal betriebenen Applikationen nutzen.


Windows Azure

Die eigentliche Basis von Microsofts Cloud-Computing-Plattform bildet Windows Azure. Vereinfacht ausgedrückt, handelt es sich dabei um ein Cloud-Betriebssystem, auf dem sich Anwendungen direkt im Internet betreiben lassen. Der Betrieb von Windows Azure und den darauf aufsetzenden Diensten und Anwendungen werden über die Data Centers gewährleistet, die der Softwarekonzern derzeit rund um den Globus aufbaut.



Anwendungen die auf Windows Azure ausgeführt werden, werden typischerweise auf mehrere Betriebssystem-Instanzen aufgeteilt. Jede dieser Instanzen läuft in einer eigenen Virtual Machine, in der ein 64-Bit-Windows- Server 2008 zur Verfügung gestellt wird. Für die Virtualisierung kommt eine speziell für den Cloud-Dienst zugeschnittene Hypervisor-Technologie (nicht Hyper-V) zum Einsatz. Über einen sogenannten Fabric Controller wird unter anderem das Load Balancing zwischen einzelnen Instanzen, die Verfügbarkeit bei Ausfall von Komponenten oder das Management von Ressourcen sichergestellt.




Auf der aktuellen Vorabversion von Azure lassen sich nur Anwendungen ausführen, welche für ASP.NET oder das .NET Framework geschrieben wurden. Zu einem späteren Zeitpunkt sollen auch Applikationen in Native-Code und PHP-Anwendungen ausgeführt werden können.
Um den Lernaufwand für Azure-Entwickler möglichst gering zu halten, will Microsoft darauf achten, dass auf möglichst viele bekannte Technologien und Werkzeuge zurückgegriffen werden kann. So kommt als Entwicklungswerkzeug Visual Studio 2008 zum Einsatz, das sich mit dem derzeitig verfügbaren Azure-SDK um entsprechende Azure-Projekt-Vorlagen erweitern lässt. Bei den Programmiersprachen kann grundsätzlich jede .NET-Sprache zum Einsatz kommen. Empfohlen wird seitens Microsoft allerdings C#. .NET-Anwendungen für Azure können auf Basis von Technologien wie beispielsweise ASP.NET oder der Windows Communication Foundation (WCF) geschrieben werden.



Erwähnenswert ist, dass Windows Azure nicht nur für Umsetzung reiner Webanwendungen, sondern auch für Programme gedacht ist, welche als Hintergrundprozess ausgeführt werden können. Die Entwicklung einer Azure-Anwendung mit Visual Studio 2008 fühlt sich bereits heute sehr ähnlich an wie die Erstellung einer gewöhnlichen .NET-Applikation. Trotzdem wird man aufgrund einiger technischer Unterschiede in den seltensten Fällen eine bestehende .NET-Anwendung ohne Anpassungsaufwand direkt in die Azure-Cloud stellen können. So ist etwa die Art und Weise, wie auf Daten zugegriffen wird, in den beiden Welten unterschiedlich gelöst. Wie bei den unterstützten Sprachen gibt sich Microsoft auch bei den Werkzeugen offen. So steht beispielsweise einer Integration von Azure-Tools in die Eclipse-Umgebung gemäss Redmond nichts im Wege.



Neben einer Plattform zum Ausführen von Anwendungen stellt Windows Azure auch einen Storage-Service bereit, auf dem Anwendungen – unabhängig davon, ob sie in der Cloud oder lokal ausgeführt werden – Daten speichern können. Der Storage Service von Azure – nicht zu verwechseln mit den unten beschriebenen SQL Data Services – basiert nicht auf einer relationalen Datenbank und wird auch nicht über die Abfragesprache SQL angesteuert. Um eine möglichst hohe Performance und Skalierbarkeit zu erreichen, kommt hier statt dessen eine einfachere Storage-Technologie zum Einsatz, bei der Daten in Form von Blobs (Binary Large Objects), Queues (für die Kommunikation zwischen Azure-Applika­tionen) oder Tabellen (für einfach strukturierte Daten) gespeichert werden können. Der Zugriff auf die Daten geschieht via REST, eine Web-Service-Schnittstellentechnologie, die in vergangener Zeit rasant an Popularität gewonnen hat und das Ansteuern von Webdiensten über simple HTTP-Aufrufe ermöglicht.


.NET Services

Mit den.NET Services, welche bislang bereits unter der Bezeichnung BizTalk Services bekannt waren, sollen hauptsächlich Hürden adressiert werden, welche sich typischerweise in verteilten Anwendungen ergeben. Im Rahmen der .NET Services stellt Azure zunächst die folgenden drei Komponenten zur Verfügung:


- Access Control: Hinter Access Control verbirgt sich ein Claim-based-Authentication-Service, mit dessen Hilfe sich die Zugangskontrolle über die Grenzen von Anwendungen und Unternehmen hinweg regeln lässt. Kern dieses Systems bilden sogenannte Claims, durch die definiert wird, über welche Berechtigung ein Benutzer verfügt. Der Access-Control-Dienst erlaubt es, solche Claims in verschiedenen Anwendungen nutzbar zu machen.




- Service Bus: Der Service Bus soll die Lokalisierung und Nutzung von Service-Endpunkten aus anderen Anwendungen vereinfachen. Jedem Service wird ein URI (Unified Ressource Identifier) zugewiesen, welcher in der Registry des Service Bus hinterlegt werden kann. Dank dieses Verzeichnisses sind Clients in der Lage, Service-Endpunkte einfacher zu lokalisieren. Der Service Bus fungiert zudem als eine Art Vermittler und kann so beim Überwinden von Kommunikationshürden helfen, die durch Protokolle wie die Network Address Translation (NAT) oder durch Firewalls entstehen können.


- Workflow: Mit dem Workflow-Dienst bietet Microsoft eine Cloud-basierte Workflow-­Engine zum Ausführen von prozessorientierten Programmen, bei der meist verschiedene Anwendungen und manuelle User-Interaktionen einbezogen werden müssen. Der Service basiert auf der Windows Workflow Foundation (WF) von .NET 3.5 und unterstützt auch langlaufende Prozesse, bei denen beispielsweise über eine gewisse Zeit auf eine Benutzereingabe oder den Input eines anderen Systems gewartet werden muss.


SQL Services

Unter dem Überbegriff SQL Services plant Microsoft eine ganze Reihe von Diensten anzubieten, mit denen das Verarbeiten von Daten direkt in der Cloud möglich sein wird. Mittelfristig verspricht der Softwarekonzern auch Angebote aufzuschalten, mit denen sich auch Business-Intelligence-Aufgaben wie Reporting oder Datenanalyse erledigen lassen.


Zunächst wird es an Datenbankdiensten aber lediglich die SQL Data Services geben, die bislang in einer frühen Vorabversion unter der Bezeichnung SQL Server Data Services verfügbar waren. Die Data Services stellen Cloud-basierten und lokalen Anwendungen einen universellen Datenspeicher bereit, der allerdings nicht auf einem relationalen, sondern auf einem hierarchischen Modell basiert. Dabei werden Informationen in sogenannten Entities (z.B. Kunden) gespeichert, die sich wiederum aus unterschiedlichen Properties (Name, Adresse etc.) zusammensetzen. Entities entsprechen sozusagen einer Tabelle im relationalen Modell mit dem Unterschied allerdings, dass erstere nicht an ein festes Schema gebunden sind. Eine Entity lässt sich ad hoc um neue Properties erweitern, ohne dass erst das entsprechende Datenbankschema geändert werden muss.



Für die Datenabfrage können REST-Aufrufe via HTTP oder Microsofts universelle Datenabfragesprache LINQ zum Einsatz kommen. SQL wird nicht unterstützt. Dass Microsoft sich hier nicht einfach einen SQL Server mit klassischen relationalen Strukturen in einer Cloud-Variante anbietet, hat wie bereits beim oben erwähnten Datenspeicher von Windows Azure den Grund, dass mit dem hierarchischen Speichermodell eine höhere Skalier- und Verfügbarkeit erreicht werden kann. Allerdings schliessen Microsoft-Verantwortliche nicht aus, dass man in Zukunft auch ein relationales Datenbankangebot aufschalten wird.


Live Services

Microsoft bietet unter der Marke Windows Live bereits seit einigen Jahren eine ganze Palette von Internetservices. Dazu zählen Anwendungen wie Hotmail, Messenger, Contacts, Calendar, Search oder Maps. Ergänzend zu diesem Angebot stehen innerhalb der Azure-Plattform die Live Services zur Verfügung. Diese fungieren als Zugriffsschicht, über welche die Daten der Windows-Live-Diensten genutzt werden können.

Um den Entwickler den Umgang mit den Live Services aus ihren eigenen Applikationen zu erleichtern, stellen die Redmonder das Live Framework (siehe Diagramm «Microsofts Live Framework») zur Verfügung. Herzstück dieses Framework bildet das Live Operating Environment, das den Zugang auf die Live Services regelt und vereinheitlicht. So erhält man etwa über den Directory-Dienst der Live Services Zugang zu den in Windows Live Contacts gespeicherten Kontaktdaten eines Benutzers. Der Zugriff lässt sich via HTTP mit REST- oder AtomPub-basierten Aufrufen bewerkstelligen. Das Live Operating Environment kann nicht nur mit
.NET oder Silverlight, sondern auch Microsoft-fremden Umgebungen wie JavaScript, Java oder Ruby genutzt werden.





Ein interessanter Aspekt des Live Framework ist die Möglichkeit, verschiedene Geräte, auf denen das Live Operating Environment eingerichtet ist, zu einem sogenannten Mesh zu gruppieren. So kann man beispielsweise Geräte wie Desktop-PC, Notebook oder Smartphone in einem Mesh zusammenfassen. Innerhalb dieses Mesh sind die Geräte nun in der Lage, Daten untereinander zu synchronisieren. Dabei können Anwender und auch Applikationen exakt bestimmen, welche Daten abgeglichen werden müssen. Das Live Operating Environment ist dafür besorgt, dass alle Geräte des Mesh automatisch auf dem aktuellsten Stand gehalten werden.



Microsoft plant, das Live Operating Environment auf Desktop-Betriebssystemen wie Windows Vista, Windows XP oder Mac OS X sowie für mobile Geräte basierend auf Windows Mobile 6 zur Verfügung zu stellen. Ausserdem läuft das Live Operating Environment auch auf der Azure-Plattform, wodurch sich die Daten der verschiedenen Live-Dienste ebenfalls in einen Mesh einbeziehen lassen. Damit können zum Beispiel in Windows Live Hotmail erfasste Kontakte automatisch mit den Kontaktdaten auf dem Desktop-PC oder dem Mobilgerät auf dem aktuellsten Stand gehalten werden.
Für Entwickler interessant ist, dass sie mit Hilfe des Live Framework auch eigene Mesh-fähige Webanwendungen erstellen können. Diese basieren auf Silverlight 2 und greifen generell über das Live Operating Environment auf Daten zu. Dadurch können Mesh-Anwendungen auf jedem Gerät ausgeführt werden, das Teil des entsprechenden Mesh ist. Microsoft plant, einen Katalog mit Mesh-fähigen Anwendungen aufs Web zu stellen, aus dem Benutzer gewünschte Applikationen installieren können.



Microsofts Live Framework


Sharepoint und CRM Services

Im Rahmen der Azure-Plattform wurden an der PDC auch die Dienste Sharepoint Services und Dynamics CRM Services angekündigt. Derzeit ist allerdings noch sehr wenig darüber bekannt, was sich genau hinter den beiden Diensten verbirgt. Microsoft spricht lediglich davon, dass man künftig Sharepoint- und CRM-Funktionen als Bausteine für eigene Anwendungen wird nutzen können. Denkbar wäre zum Beispiel, dass man die in Sharepoint angebotenen Dokumentbibliotheken und Listenfunktionen als Dienst in eigene Anwendungen integrieren kann.


Wann kommt's?

Die Azure Platform Services (www.azure.com) stehen seit Ende Oktober in einer ersten Vorabversion (CTP) zur Verfügung. Entwickler sind damit in der Lage, mit der neuen Umgebung zu experimentieren. Dazu wurde ein Software Development Kit (SDK) veröffentlicht, das unter anderem Werkzeuge für Visual Studio, eine lokale Azure-Umgebung für Tests und einen Zugang zur Azure-Plattform enthält.



Ein definitives Release-Datum für den produktiven Start von Azure gibt es von Microsoft nicht. Allerdings erwartet man in Redmond, bereits 2009 den Betrieb aufnehmen zu können. Auch punkto Pricing und SLAs (Service Level Agreements) hält sich der Softwareriese noch sehr bedeckt. Klar ist nur, dass man wie bei der Konkurrenz auf nutzungsbasierte Tarifmodelle (CPU-Zeit, Storage, Datenübertragung etc.) setzen will. Bis zum Start sollen ausserdem sehr strikte SLA zur Verfügung stehen.




Artikel kommentieren
Kommentare werden vor der Freischaltung durch die Redaktion geprüft.

Anti-Spam-Frage: Vor wem mussten die sieben Geisslein aufpassen?
GOLD SPONSOREN
SPONSOREN & PARTNER