Windows Azure

Verschieben von Anwendungen nach Windows Azure

Alex Homer

Experten für modernen Lebensstil bestätigen, dass der Umzug in ein neues Zuhause eines der anstrengendsten Ereignisse im ganzen Leben ist. Aber vor die Wahl gestellt, umzuziehen oder Anwendungen auf eine neue Plattform zu verschieben, würden viele von uns trotzdem sofort anfangen, das Geschirr einzupacken. Glücklicherweise ist jedoch das Migrieren von Anwendungen zu Windows Azure ein Kinderspiel.

Über viele Jahre hinweg hat Microsoft in Rechenzentren auf der ganzen Welt äußerst skalierbare Anwendungen erstellt – hoch verfügbare Anwendungen mit globaler Reichweite, die den Benutzern eine hervorragende Funktionalität bieten. Mit Windows Azure können Sie dieselbe Infrastruktur nutzen, um Ihre eigenen Anwendungen bereitzustellen, mit den entsprechenden Funktionen, die Ihre Wartungsanforderungen reduzieren, die Leistung maximieren und die Kosten minimieren.

Natürlich findet seit vielen Jahren ein Outsourcing von Anwendungen an Drittanbieter von Hosting statt. Das kann bedeuten, Rackplatz oder einen Server in einem Remoterechenzentrum zu mieten, um Anwendungen zu installieren und auszuführen, oder einfach Platz auf einem Webserver und in einer Datenbank von einem Hostingunternehmen zu mieten. In beiden Fällen ist allerdings die Anzahl verfügbarer Features normalerweise begrenzt. In der Regel fehlen ein Authentifizierungsmechanismus, Nachrichtenwarteschlangen, eine Datenverkehrsverwaltung, Datensynchronisierung und andere periphere Dienste, die in Windows Azure standardmäßig integriert sind.

Nun könnte der Eindruck entstehen, dass es durch all diese Funktionen recht kompliziert wird, Anwendungen zu Windows Azure zu migrieren. Aber wenn Sie Ihre Anforderungen berücksichtigen und die verfügbaren Features ausloten, kann der Schritt zu Windows Azure ein schneller und relativ einfacher Prozess sein. Damit Sie sich über die Optionen informieren können und die richtigen Entscheidungen treffen, hat das patterns & practices-Team bei Microsoft vor Kurzem eine aktualisierte Version des Migrationshandbuchs für Windows Azure veröffentlicht: „Verschieben von Anwendungen in die Cloud unter Windows Azure“ (msdn.microsoft.com/library/ff728592).

Im Handbuch wird eine Reihe von Szenarios für die Migration von Anwendungen zu Windows Azure behandelt. Im restlichen Teil dieses Artikels ergründe ich diese Szenarios, beleuchte die Entscheidungen, die Sie treffen müssen, und gehe auf die praktischen, nützlichen Ratschläge des Handbuchs ein, mit deren Hilfe Sie die jeweils geeignete Auswahl treffen. Während das Handbuch einen etwas künstlichen mehrschrittigen Migrationsprozess verfolgt, der wahrscheinlich in der Praxis meistens nicht vollständig eingehalten wird, demonstriert dieser Ansatz die meisten Optionen und zeigt die Funktionen von Windows Azure, die in Ihren eigenen Anwendungen hilfreich sein können. Abbildung 1 stammt aus dem Handbuch und zeigt eine konzeptionelle Karte der Migrationspfade, denen Sie folgen können, wenn Sie eine Anwendung aus einem Rechenzentrum vor Ort nach Windows Azure verschieben.

Abbildung 1: Konzeptionelle Karte einiger möglicher Migrationspfade zu Windows Azure

Infrastruktur oder Plattformhosting?

Wie auf der Karte zu sehen, betrifft die erste Entscheidung bei der Migration zu Windows Azure die Route, der Sie folgen möchten: IaaS (Infrastructure as a Service) oder PaaS (Platform as a Service).

Wie der Name besagt, stellt IaaS die Laufzeitinfrastruktur bereit, wie einen virtuellen Server und Netzwerkkonnektivität, damit Sie das gewünschte Betriebssystem sowie die Dienste und Anwendungen Ihrer Wahl installieren können. Effektiv übernehmen Sie einfach Ihren Server und führen ihn in Microsoft-Rechenzentren aus. Windows Azure bietet eine Anzahl von vorinstallierten Betriebssystemen (beispielsweise Windows Server und Linux), aus denen Sie auswählen und trotzdem weiterhin periphere Dienste nutzen können, wie die Authentifizierung über Windows Azure Active Directory, Messaging mit Windows Azure-Speicherwarteschlangen oder -Servicebus, globales Routing zu Ihrer Anwendung über Traffic Manager und mehr.

Alternativ können Sie Betriebssystem und Laufzeitplattform von Microsoft verwalten lassen, indem Sie PaaS auswählen. Web Sites in Windows Azure stellt eine benutzerfreundliche Hostingplattform für Webanwendungen und Websites mit einfachen Verwaltungs- und Bereitstellungsfunktionen bereit, die direkt in viele Quellcodeverwaltungssysteme integriert werden kann und eine Reihe von Programmiersprachen unterstützt. Wenn Sie mehr Kontrolle über die Plattform anstreben, einschließlich die Fähigkeit, eine Kombination von verschiedenen Typen von Rollen auszuführen und die Zwischenspeicherung direkt zu integrieren, können Sie den Cloud Services-Ansatz auswählen. Dadurch können Sie getrennte Web- und Workerrollen bereitstellen, erhalten eine breitere Palette an Konfigurationsoptionen, und der Ansatz ist zudem gut für eine Umgebung mit gestaffelter Bereitstellung und Versionsangabe geeignet.

Wie Sie später im Artikel sehen werden, ist die Auswahl zwischen IaaS und PaaS nicht auf den Anwendungscode begrenzt. Wenn Sie die IaaS-Route nehmen, können Sie einen virtuellen Windows Azure-Computer (Virtual Machine, VM) bereitstellen, auf dem eine Datenbank wie SQL Server oder MySQL vorinstalliert ist. Auf der PaaS-Route hingegen bietet Windows Azure auch einen gehosteten Datenbankmechanismus namens Windows Azure SQL-Datenbank an, der eigentlich eine gehostete SQL Server-Instanz ist, die Sie fast genauso wie SQL Server vor Ort verwenden können.

Der Weg in die Cloud mit IaaS

Es hat mehrere deutliche Vorteile, die Anwendungen mit IaaS zu hosten. Sie können zum Beispiel möglicherweise den Schritt auf einen virtuellen Computer in der Cloud machen, ohne Änderungen an Ihrem Anwendungscode vornehmen zu müssen. Sie verbinden die VM über ein virtuelles Netzwerk mit Ihrem internen Netzwerk und der Domäne, und all Ihre Systeme zum Testen, Bereitstellen, Verwalten und Überwachen funktionieren weitgehend so wie zuvor.

Effektiv haben Sie nur das Ethernetkabel in Ihrem Rechenzentrum durch eine Internetverbindung mit Windows Azure ersetzt. Ein virtuelles Windows Azure-Netzwerk kann Ihr lokales Netzwerk über einen standardmäßigen VPN-Router mit einem Netzwerk verbinden, das Sie in der Cloud konfigurieren, und Sie können dadurch interne Netzwerk-IP-Adressen genauso wie vor Ort verwenden. Über die Verbindung gibt es zwar etwas zusätzliche Latenz, und Sie müssen überlegen, wie Sie mit gelegentlich auftretenden, vorübergehenden Verbindungsausfällen umgehen, aber Sie sind von der Verwaltung und Aktualisierung der Hardware, der Infrastruktur und des Betriebssystems befreit. (Prüfen Sie, ob Sie zur Verarbeitung vorübergehender Verbindungsausfälle für viele unterschiedliche Vorgänge den Microsoft-Anwendungsblock für die Behandlung transienter Fehler verwenden können. Weitere Informationen finden Sie unter msdn.microsoft.com/library/hh680934(PandP.50).)  

Der IaaS-Ansatz mit Windows Azure-VMs ist ideal, wenn Sie Software oder Dienste ausführen, bei denen Sie nicht auf den Quellcode zugreifen können oder die Anwendung nicht ändern können, zum Beispiel bei einer Abhängigkeit von einer Drittanbieteranwendung. Dieser Weg funktioniert auch gut, wenn Sie eine nicht dem Standard entsprechende Konfiguration des Betriebssystems oder der üblichen Dienste benötigen oder bestimmte Berechtigungen für Dateien und Ressourcen festlegen möchten.

Was das Testen und die Bereitstellung betrifft, werden Ihre Entwicklungsteams keinen Unterschied zu vorhandenen Prozessen bemerken. Sie können die Bereitstelllung auf den Test- und Produktionsumgebungen in Windows Azure von den lokalen Entwicklungscomputern und dem Buildserver aus vornehmen oder die Test- und Buildserver in der Cloud ermitteln. Abbildung 2, nach einer Abbildung im Handbuch, zeigt ein Beispiel für eine Test- und Bereitstellungskonfiguration, die sowohl lokale als auch in der Cloud gehostete Testumgebungen umfasst. Dazu werden zwei getrennte Windows Azure-Abonnements verwendet, eines zum Testen und eines für die Liveanwendung.

Abbildung 2: Überblick über einen möglichen Mechanismus zum Entwickeln, Testen und Bereitstellen

Wenn Sie den Windows Azure-IaaS-Ansatz auswählen, ist also der einzige wirkliche Unterschied, dass die Anwendung nicht mehr in Ihrem eigenen, teuren, klimatisierten Serverraum ausgeführt wird, Ressourcen verbraucht und Bandbreite Ihrer Internetverbindung beansprucht. Stattdessen wird die Anwendung in einem Microsoft-Rechenzentrum Ihrer Wahl ausgeführt, wo Änderungen an der VM im Sicherungsspeicher des Originalabbilds beibehalten werden, jederzeit zuverlässige Konnektivität bereitgestellt wird und die Laufzeitplattform die ständige Verfügbarkeit gewährleistet.

Sie können außerdem aus einer Reihe von Größen die passende für Ihre VM auswählen, die ausgeführten Instanzen bei Bedarf aktualisieren, das Betriebssystem und dessen Dienste im Hinblick auf die spezifischen Anforderungen der Anwendung konfigurieren, zusätzliche Instanzen bereitstellen, um Auslastungsänderungen zu entsprechen, und sogar automatisches Routing an Bereitstellungen in verschiedenen Rechenzentren einrichten, um die Verfügbarkeit zu maximieren und weltweit die Antwortzeiten für Benutzer zu minimieren.

Vereinfachen der Verwaltung mit PaaS

Wenn Sie das Betriebssystem lieber nicht selbst verwalten möchten, können Sie den PaaS-Ansatz auswählen. Dadurch geben Sie zwar einige Möglichkeiten zur Konfiguration der Laufzeitplattform auf, reduzieren aber administrative Aufgaben und Verwaltungskosten, da Microsoft für die Verwaltung der Server, die Aktualisierung des Betriebssystems und die Anwendung von Patches verantwortlich ist. Sie konzentrieren sich einfach auf den Anwendungscode und dessen Interaktion mit peripheren Diensten.    

Wenn Sie eine Website oder Webanwendung nach Windows Azure verschieben möchten, ist es am einfachsten, sie auf Web Sites in Windows Azure bereitzustellen. Dabei muss die Anwendung nur sehr wenig, wenn überhaupt, geändert werden. Sie können die Anwendung aus Microsoft Team Foundation Server (TFS) oder anderen Quellcoderepository-Systemen, z. B. GitHub, bereitstellen. Je nach Ihren Anforderungen und dem Hostingbudget hosten Sie die Anwendung auf einem freigegebenen Webserver oder auf einer reservierten Instanz, wo Sie die Leistung garantieren und die Anzahl der Instanzen verwalten können, um der Nachfrage zu entsprechen.

Wenn Sie einen integrierten Mechanismus für die Versionskontrolle von Bereitstellungen und die Bereitstellung von Anwendungen benötigen und außerdem die Möglichkeit haben möchten, Teile der Anwendung separat zu skalieren, können Sie alternativ die Web- und Workerrollen in Windows Azure Cloud Services verwenden, um Ihre Anwendung zu hosten. Durch die Verschiebung von Hintergrundaufgaben in Workerrollen und die Platzierung der Benutzeroberfläche in Webrollen verteilen Sie die Last für die Anwendung, führen eine asynchrone Hintergrundverarbeitung aus und skalieren jeden Rollentyp separat, indem Sie die geeignete Anzahl der Instanzen von jedem ausführen.

(Wenn Sie eine automatische Skalierung für Rollen in einer Cloud Services-Bereitstellung implementieren möchten – gemäß einem vorher festgelegten Plan oder als Reaktion auf Laufzeitereignisse wie Änderungen der Serverlast – können Sie dazu den Microsoft-Anwendungsblock für die automatische Skalierung in Betracht ziehen. Weitere Informationen finden Sie unter msdn.microsoft.com/library/hh680892(PandP.50).)  

Normalerweise verbinden Sie Web- und Workerrollen, indem Sie Daten zwischen ihnen mithilfe von Windows Azure-Speicherwarteschlangen oder Windows Azure-Servicebus-Warteschlangen als Nachrichten übermitteln. (Servicebus-Warteschlangen unterstützen größere Nachrichten und verfügen über integrierte Authentifizierungs- und Zugriffssteuerungsmechanismen.) Die Verwendung von Messaging eröffnet auch die Möglichkeit, standardmäßige Messaging- und Speichermuster wie Anforderung/Antwort, Fire-and-Forget, verzögerter Schreibvorgang und andere einzusetzen. Wenn Ihre Anwendung in Form von Komponenten erstellt wird und einer diensteorientierten Architektur (Service Oriented Architecture, SOA) folgt, ist es relativ einfach, sie in Windows Azure Cloud Services zu verschieben. 

Die Verwendung von Web- und Workerrollen kann natürlich bedeuten, dass die Anwendung ein wenig umgestaltet werden muss. Das ist in vielen Fällen aber nicht sonderlich aufwendig und betrifft nicht die Kerngeschäftslogik oder den Präsentationscode. Zu Windows Azure migrierte ASP.NET MVC-Anwendungen funktionieren zum Beispiel problemlos, und sie können auf genau dieselbe Weise auf Datenspeicher wie SQL Server zugreifen wie bei ihrer Ausführung vor Ort oder wenn sie mithilfe des IaaS-Ansatzes auf VMs bereitgestellt werden.

Der Schritt zu Windows Azure Cloud Services kann auch eine Gelegenheit sein, Ihre Authentifizierungs- und Autorisierungsmechanismen zu aktualisieren, insbesondere wenn Sie den Code teilweise umgestalten müssen. Moderne Anwendungen nutzen immer häufiger einen anspruchsbasierten Authentifizierungsmechanismus, einschließlich Verbundidentität und einmaliges Anmelden (Single Sign-on, SSO).

Dieser Typ Mechanismus ermöglicht Benutzern, sich mithilfe einer Reihe von vorhandenen Anmeldeinformationen anzumelden, anstatt bestimmte Informationen ausschließlich für Ihre Anwendung zu fordern, und sich nur einmal anzumelden, wenn sie auf mehrere Anwendungen oder Websites zugreifen. Durch das Zugriffssteuerungsfeature von Windows Azure Active Directory in Kombination mit Windows Identity Framework (WIF) können die anspruchsbasierte Authentifizierung und die Verbundidentität einfach implementiert werden. Abbildung 3, nach einer Abbildung im Handbuch, zeigt ein Beispiel für die Anwendung a-Expense des fiktionalen Unternehmens Adatum. Die Benutzer werden durch ihr eigenes Active Directory authentifiziert und erhalten ein Token, das sie an die Anwendung übermitteln, um Zugriff zu erhalten.

Abbildung 3: Anwenden eines anspruchsbasierten Authentifizierungssystems

Weitere Informationen zur anspruchsbasierten Authentifizierung erhalten Sie in der verwandten patterns & practices-Veröffentlichung „Ein Leitfaden zu anspruchsbasierter Identität und Zugriffssteuerung“ unter msdn.microsoft.com/library/ff423674. 

Wo werden die Daten gespeichert?

Fast alle Unternehmensanwendungen verwenden Daten, und diese werden häufig in einer Datenbank wie SQL Server oder einem relationalen Datenbankverwaltungssystem (Relational Database Management System, RDBMS) eines anderen Anbieters gespeichert. Ein typisches Szenario bei der Migration einer Anwendung, die eine relationale Datenbank verwendet, ist die Bereitstellung einer Windows Azure-VM, die den Datenbankserver hostet (Windows Azure bietet vorkonfigurierte VMs, die entweder SQL Server oder MySQL enthalten). Alternativ können Sie fast jede andere Art von Datenspeicher installieren, der unter Windows oder Linux in einer Windows Azure-VM ausgeführt wird.

Die Verbindung von Ihrer in der Cloud gehosteten Anwendung zu einer in der Cloud gehosteten Datenbank stellen Sie genauso her, als ob die Datenbank und die Anwendung sich in Ihrem eigenen Rechenzentrum befinden würden. Das ist allerdings nur eine der in Windows Azure verfügbaren Optionen. In der Regel müssen Sie entscheiden, ob Sie die Daten für Ihre Anwendungen in der Cloud bereitstellen oder vor Ort speichern und über ein virtuelles Netzwerk oder Messaging mit dem Datenbankserver kommunizieren. Wenn Sie sich für die Cloud entscheiden, müssen Sie einem der Pfade folgen; IaaS oder PaaS (SQL-Datenbank).

Das Command Query Responsibility Segregation(CQRS)-Muster nutzt normalerweise Messaging, um Datenaktualisierungen und Abfrageergebnisse zwischen Anwendungskomponenten zu kommunizieren, und Windows Azure bietet zwei Warteschlangenmechanismen, die Ihre Anwendung zu diesem Zweck verwenden kann. Bei einem Standarddatenzugriff kann es allerdings zu Verzögerungen und nachfolgend zu schlechter Leistung führen, zwischen der Anwendung und der Datenbank ein Netzwerk wie das Internet einzusetzen. Wenn die Umstände oder gesetzliche Bestimmungen eine Datenbank vor Ort erforderlich machen, kann Windows Azure Caching diese Verzögerungen reduzieren. (Weitere Informationen zum CQRS-Muster erhalten Sie im verwandten patterns & practices-Handbuch „CQRS-Reise“ unter msdn.microsoft.com/library/jj554200.) 

Windows Azure SQL-Datenbank ist eine ideale Lösung für die allgemeine Datenspeicherung bei der Migration einer vorhandenen Anwendung, die SQL Server verwendet. Wenn der Code keine der etwas ausgefalleneren Features von SQL Server erfordert – wie Freitextsuche, XML-Verarbeitungsfunktionen, Prozeduren, die CLR-Programmierbarkeit benötigen oder verteilte Abfragen, die SQL Server Service Broker nutzen – funktioniert die vorhandene Anwendung ohne Änderungen.

Windows Azure SQL-Datenbank ist auch sehr kostengünstig, wenn Sie nur normale Mengen von Daten speichern müssen. Wenn Sie aber sehr große Datenmengen speichern oder viele Datenbanken bereitstellen müssen, ist es eine attraktive Lösung, einen Datenbankserver zu verwenden, der in einer VM gehostet wird. Sie können die geeignete Größe der VM auswählen und sogar mehrere VMs nutzen, um einen Datenbankfailover oder einen freigegebenen Datenspeicher zu implementieren.

In einigen Fällen gehen die Anforderungen an die Datenspeicherung und die Abfrage über die Funktionen von relationalen Datenbanksystemen hinaus. Unternehmen haben häufig Petabyte an Daten in Webserverprotokollen, Finanztransaktionsdateien, Informationen aus sozialen Medien, medizinischen Daten und anderen Typen von Daten, die nicht regelmäßig verarbeitet werden, aber für gelegentliche oder zukünftige Abfragen nützlich sein können. Windows Azure bietet für genau dieses Szenario den HDInsight-Dienst (basierend auf Open-Source-Hadoop-Technologien). Weitere Informationen finden Sie unter https://azure.microsoft.com/en-us/services/hdinsight/.

Tabellen, Blobs, Warteschlangen und Laufwerke

Windows Azure bietet auch einen anderen Speichertyp, der nicht auf dem relationalen SQL-Paradigma basiert. Verwenden Sie Windows Azure-Speichertabellen und -Blobs, um Anwendungsdaten zu speichern. Sie können Speicherwarteschlangen nutzen, um Nachrichten zwischen Anwendungskomponenten zu übermitteln, und Speicherlaufwerke verwenden, die sich fast wie ein herkömmliches festplattenbasiertes Ablagesystem verhalten.

Windows Azure-Speichertabellen sind weniger schemabasiert, das bedeutet, jede Zeile ist eine Entität, die einen Eigenschaftsbehälter mit Werten enthält, und eine Tabelle kann verschiedene Typen von Entitäten in allen Zeilen aufweisen. Das ist ideal für strukturierte (Spalten und Zeilen) und teilstrukturierte Daten. Demgegenüber sind Windows Azure-Speicherblobs besser geeignet, um unstrukturierte Daten wie Dokumente, Binärdaten, XML-Dateien und Bilder zu speichern.  

Windows Azure-Speicher ist außerdem im Vergleich zu einem VM-gehosteten Datenbankserver oder einer SQL-Datenbank sehr günstig. Allerdings muss vorhandener Datenzugriffscode neu geschrieben werden. In der Regel sind Windows Azure-Tabellen und -Blobs vorteilhafter, wenn Sie die Anwendungen von vornherein für die Ausführung in Windows Azure konzipieren. Sie können aber relativ einfach von einer relationalen Datenbank zu Windows Azure-Speicher übergehen, wenn Ihre Anwendung eine klar abgegrenzte Datenzugriffsebene hat, die Sie durch eine ersetzen können, die Windows Azure-Tabellen und -Blobs nutzt.    

Wie bei allen cloudbasierten Diensten kann es vorkommen, dass eine erste Verbindungsanforderung aufgrund von vorübergehenden Netzwerkproblemen oder intermittierenden und temporären Ressourcenbeschränkungen fehlschlägt. Mithilfe des bereits erwähnten Anwendungsblocks für die Behandlung transienter Fehler können Sie automatisch Ausfälle ermitteln und alle Speichervorgänge erneut ausführen, relationale Datenbanken und Windows Azure-Speicher eingeschlossen. Das ist ein bewährtes Verfahren für alle cloudbasierten Anwendungen, das Sie mit dem Anwendungsblock für die Behandlung transienter Fehler einfach implementieren können.

Workerrollen und Hintergrundaufgaben

Eine der Stärken von Windows Azure Cloud Services ist die Bereitstellung eines bestimmten Rollentyps, der für die Hintergrundverarbeitung bestimmt ist. Die Workerrolle ist nicht darauf begrenzt, als ergänzender Teil einer Anwendung verwendet zu werden. Sie ist vielmehr eine Webrolle ohne installierten Webserver (IIS). Das typische Szenario ist allerdings, kontinuierliche Aufgaben in der Workerrolle auszuführen, die in Windows Azure-Warteschlangen (oder Servicebus-Warteschlangen) auf Nachrichten warten, die die Rolle anweisen, eine bestimmte Aktion im Hintergrund auszuführen, wie in Abbildung 4 gezeigt.

Abbildung 4: Übergeben von Nachrichten von einer Webrolle an eine Workerrolle

Asynchrone Aufgaben und Hintergrundaufgaben auf diese Weise herauszunehmen unterstützt Sie bei der Implementierung von vielen grundlegenden Prinzipien für das Entwerfen von Anwendungen, zum Beispiel die Trennung von Bereichen und die einzige Verantwortung. Durch die Übergabe von Informationen und Befehlen als Nachrichten zwischen Rollen fördern Sie die Kapselung der einzelnen Rollen und reduzieren Abhängigkeiten, vielfach auf die gleiche Weise wie bei der Anwendung der SOA-Prinzipien.

Im Handbuch wird beispielsweise untersucht, wie Adatum Workerrollen verwendet, um von den Benutzern hochgeladene Bilder von Quittungen zu komprimieren und zu speichern. Das Ziel ist, Speicherplatz zu sparen, und die Ausgabendaten für die Adatum-Gehaltabrechnungsanwendung zu exportieren. Beide Aufgaben werden durch eine Nachricht in einer Warteschlange initiiert. Die Nachricht enthält die Daten, die für die einzelne Aufgabe relevant sind.    

Beim Umgestalten Ihrer Anwendung für die Bereitstellung in Windows Azure Cloud Services-Rollen ist normalerweise offensichtlich, welche Aufgaben für die Ausführung in einer Workerrolle geeignet sind. Hintergrundaufgaben können auch mithilfe eines Zeitplans initiiert werden, und Sie können die Hostingkosten minimieren, indem Sie mehr als eine Aufgabe in einer Workerrolle ausführen, solange Sie Code hinzufügen, um eventuell fehlgeschlagene oder stehen gebliebene Aufgaben neu zu starten. Windows Azure erkennt, wenn eine Rolle fehlschlägt, und versucht diese neu zu starten. Ein Fehler bei einer einzelnen Aufgabe in einer Rolle kann von Windows Azure nicht entdeckt werden.

Sie müssen ferner überlegen, wie Sie Feedback oder Ausgaben der Hintergrundaufgabe verarbeiten möchten. Sie könnten sich beispielsweise entscheiden, das verzögerte Schreibvorgangsmuster zu nutzen, um von den Benutzern übermittelte Bestelldetails zu speichern, die in einer Nachricht verpackt werden, welche die Benutzeroberfläche an eine Hintergrundaufgabe einer Workerrolle sendet. Die Workerrolle liest die Nachricht aus der Warteschlange und speichert die Details in der Datenbank. Wenn allerdings die Bestellnummer nur zum Zeitpunkt der Speicherung generiert wird, wird es komplizierter für die Workerrolle, diese Bestellnummer an die Webrolle zur Anzeige in der Benutzeroberfläche zurückzugeben.

Kann ich mir Windows Azure leisten?

Wie Sie gesehen haben, umfasst Windows Azure eine große Bandbreite an Features und Diensten, um allen Anwendungsanforderungen zu entsprechen, sogar wenn Sie im Moment noch nicht alle genau kennen. Sie können Ihre Anwendung auf einem der in der ganzen Welt vorhandenen Rechenzentren bereitstellen und die umfangreichen Funktionen für die Speicherung und Skalierung nutzen. Aber können Sie es sich wirklich leisten, Ihre Anwendungen live in Windows Azure auszuführen? 

Das sechste Kapitel des Handbuchs widmet sich der Evaluierung der Kosten, die das Hosten in der Cloud verursacht. In dem Kapitel werden verschiedene Berechnungen für Adatum durchgeführt, um zu schätzen, wie viel die Ausführung der a-Expense-Anwendung in Windows Azure das Unternehmen kosten wird. Die Anwendung soll eine einzelne Webrolle und eine einzelne Workerrolle verwenden und muss ungefähr 20 GB Daten in einer relationalen Datenbank sowie 120 GB Bilddaten in Windows Azure-Speicher speichern. Mit aktuellen Preisen berechnet, ergibt dies für Adatum voraussichtlich Kosten von ungefähr 2.300 Euro pro Jahr. Obwohl Adatum die Kosten der Ausführung dieser Anwendung im unternehmenseigenen Rechenzentrum nicht genau beziffern kann, da viele der Ressourcen mit anderen Anwendungen vor Ort gemeinsam genutzt werden, fällt der Vergleich der geschätzten Kosten für Windows Azure sehr positiv aus.

Und noch besser, durch die Einführung einer automatischen Skalierungslösung wie dem Enterprise Library Autoscaling-Anwendungsblock kalkuliert Adatum, dass es die Anwendung nur während der Geschäftszeiten ausführen, aber durch Hinzufügen von zusätzlichen Rolleninstanzen am Monatsende, wenn die meisten Ausgaben erfasst werden, die Kapazität verdoppeln kann und somit die Gesamtkosten auf ungefähr 1.500 Euro pro Jahr reduziert werden. Adatum rechnet ferner damit, dass das Unternehmen zusätzlich fast 600 Euro sparen kann, wenn es die Anwendung anpasst, um Windows Azure-Tabellen und -Blobs anstelle der SQL-Datenbank oder SQL Server zu nutzen.

Natürlich stellt Ihre eigene Anwendung hinsichtlich der Kapazität und des Zeitplans für die Ausführung andere Anforderungen, und diese hängen davon ab, welche Last von den Anwendungen verarbeitet werden muss und wie viel Speicherplatz sie beanspruchen. Aber es ist klar, dass Sie sich Windows Azure als neues Zuhause leisten können und die Migration viel weniger Stress mit sich bringt als ein Umzug mit der Familie in neue vier Wände!

Weitere Informationen

Das patterns & practices-Handbuch „Verschieben von Anwendungen in die Cloud unter Windows Azure“ ist unter msdn.microsoft.com/library/ff728592 verfügbar. Sie können das Handbuch im PDF-Format unter microsoft.com/download/details.aspx?id=29252 herunterladen.

Die folgenden zugehörigen Handbücher und Frameworks von patterns & practices sind verfügbar:

• Entwickeln mehrinstanzenfähiger Anwendungen für die Cloud: msdn.microsoft.com/library/ff966499
• Entwickeln von Hybrid-Anwendungen in der Cloud mit Windows Azure: msdn.microsoft.com/library/hh871440
• Ein Leitfaden zu anspruchsbasierter Identität und Zugriffssteuerung: msdn.microsoft.com/library/ff423674
• Anwendungsblock für die Behandlung transienter Fehler: msdn.microsoft.com/library/hh680934(PandP.50)
• Anwendungsblock zur automatischen Skalierung: msdn.microsoft.com/library/hh680892(PandP.50)

Die Windows Azure-Homepage finden Sie unter windowsazure.com und das Windows Azure Developer Center unter windowsazure.com/en-us/develop/overview.

Alex Homergehört als technischer Redakteur zur patterns & practices-Abteilung von Microsoft in Redmond, Washington (USA). Bisher hat er allerdings nicht den Wunsch verspürt, das vermeintlich gute Wetter in Seattle zu genießen, sondern arbeitet lieber bei sich zu Hause im idyllischen Derbyshire Dales in England. Seine mehr oder weniger zusammenhängenden Gedanken zur IT-Branche und zum Leben im Allgemeinen finden Sie in seinem Blog unter blogs.msdn.com/alexhomer.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Masashi Narumoto
Masashi Narumoto ist Senior Program Manager im patterns & practices-Team. Er hat an einer Reihe von Windows Azure-Leitfäden gearbeitet und konzentriert sich jetzt auf Big Data. Narumoto hat zuvor mehr als 20 Jahre lang eine Vielzahl an Lösungen entwickelt und Beratungen durchgeführt, und zwar vor allem im Einzelhandels- und Fertigungsbereich. Sie finden seinen Blog unter https://blogs.msdn.com/masashi_narumoto und erreichen ihn über Twitter unter @dragon119.