Integrieren von Windows Azure

Windows Azure-Plattform für Unternehmen

Hanu Kommalapati

Cloud Computing hat sowohl bei renommierten Unternehmen als auch bei neu gegründeten Firmen Beachtung gefunden. Die meisten Firmen beschäftigen sich nicht nur aus purer Neugier mit dem Cloud Computing. Zum Zeitpunkt des Verfassens dieses Artikels legt die IT-Marktforschung nahe, dass die meisten IT-Manager in Unternehmen über ausreichend Ressourcen verfügen, um Cloud Computing in Kombination mit firmeninternen IT-Funktionen zu übernehmen.

Natürlich gibt es Leute, die bezweifeln, dass Cloud Computing das halten kann, was es verspricht. Diese neue Lösung zeigt Parallelen zur Entwicklung von ARPANET (dem Internet-Vorläufer). Viele skeptische Forschungsinstitute wollten diesem ersten Netzwerk nicht beitreten, weil sie den Verlust vertraulicher Daten befürchteten. Sobald die Wissenschaftler sahen, welche Vorteile der Datenaustausch und die dadurch mögliche Zusammenarbeit boten, waren sie nicht mehr aufzuhalten, und der Rest ist bekannt. Wie die ARPANET-Skeptiker machen sich die heutigen großen Unternehmen gerade mit dem Paradigmenwechsel vertraut, der in Bezug auf Akquisition und Betrieb von IT-Leistungen derzeit auftritt.

Da Microsoft Branchentrends und Kundenanforderungen erkennt, hat das Unternehmen auf Cloud Computing gesetzt und die Windows Azure-Plattform sowie die notwendigen unterstützenden Dienste veröffentlicht, die es ermöglichen, professionelle Dienstleistungen in der Cloud zu entwickeln und auszuführen. In diesem Artikel wird die Windows Azure-Plattform auf der Architekturebene besprochen und den Anforderungen von Unternehmenslösungen gegenübergestellt.

Cloud Computing

Es gibt sicherlich mehrere Definitionen des Begriffs Cloud Computing, aber mir gefällt die Folgende am besten: IT-Dienstleistungen, die über Internetstandards und –protokolle als Versorgungsleistung bereitgestellt werden. Diese Definition eröffnet die Möglichkeiten für die Konzepte der "öffentlichen Cloud" und der "privaten Cloud". Wie aus dem Namen hervorgeht, sind öffentliche Clouds für jeden verfügbar, der mit einer Kreditkarte ausgerüstet ist. Private Clouds sind für die exklusive Nutzung durch ein Unternehmen oder ein Konsortium von Unternehmen vorgehen, die im Leitsatz der privaten Cloud beschrieben wird.

Die Windows Azure-Plattform, Amazon Web Services, Google App Engine und Force.com sind nur einige Beispiele für öffentliche Clouds. Jedes private Datencenter, das von einem großen Unternehmen betrieben wird, kann als private Cloud bezeichnet werden, wenn es das vereinheitlichte Ressourcenmodell nutzt, das durch eine breitere Virtualisierung ermöglicht wird, bei der Rechenleistung, Speicherkapazität und Netzwerkbetrieb als homogener Ressourcenpool behandelt und stark automatisierte Prozesse zum Betrieb des Systems genutzt werden.

Soweit ich mich erinnern kann, träumen Visionäre im Feld der Computerautomatisierung von Utility Computing. Die Dynamic Systems Initiative (DSI) von Microsoft und ähnliche Initiativen von anderen Herstellern versuchten dreist, die Betreiber von Datenzentren darin zu unterstützen, einer Versorgungsleistung ähnliche Charakteristika bereitzustellen: stark automatisierte, selbstverwaltete, sich selbst optimierende und messbare Speicher-, Netzwerk- und Rechenzyklen. Die Vision war zwar lobenswert, aber nur teilweise von Erfolg gekrönt. Mit dem Aufkommen der Virtualisierung wurde das Utility Computing Wirklichkeit. Die Virtualisierung trug zur Trennung von Betriebssystem und Anwendungen von der physischen Hardware bei. Sie werden als Daten behandelt, und daher können automatisierte Prozesse für die bedarfsgesteuerte Übertragung von Betriebssystemressourcen und anderen Ressourcen auf die Zielhardware entwickelt werden.

Um die besten Voraussetzungen für eine Diskussion der Windows Azure-Plattform zu schaffen, sehen wir uns kurz die in der Branche übliche Terminologie im Feld Cloud Computing an und ordnen die Windows Azure-Plattform diesen Begriffen zu, damit sie schnell verständlich ist. Abbildung 1 enthält ein Sandwich-Diagramm mit der Branchenterminologie und der Zuordnung der Windows Azure-Plattform. In den folgenden Abschnitten werden die verschiedenen Cloud-Diensttypen eingehender betrachtet, und beschrieben, worin sich diese voneinander unterscheiden.

Abbildung 1 Windows Azure-Plattform ist ein PaaS-Angebot

Software als Dienst (Software as a Service, SaaS)

Software als Dienst (SaaS) ist ein Geschäftsmodell für die Softwarebereitstellung, bei dem ein Anbieter oder ein Drittanbieter eine Anwendung hostet und Kunden im Rahmen eines Abonnements zur Verfügung stellt. SaaS-Kunden nutzen die Software, die in der Infrastruktur des Anbieters ausgeführt wird, nur bei Bedarf und zahlen für die Nutzung je nach Gebrauch. Es sind keine Vorleistungen erforderlich, und daher muss der Kunde auch keine langfristigen Verträge eingehen.

Je nach Vertragsbedingungen, steht es dem Kunden frei, jederzeit auf die Nutzung der Software zu verzichten. Die zugrunde liegende Infrastruktur und die Softwarekonfiguration sind für die Benutzer nicht sichtbar, und folglich müssen sich die Kunden mit der Funktionalität zufrieden geben, die für sie pauschal bereitgestellt wird. SaaS zeichnet sich durch eine Mehrinstanzenarchitektur aus. Die Benutzerkontexte werden sowohl zur Laufzeit als auch in Ruhezeiten logisch voneinander getrennt.

Da diese Mehrinstanzenfähigkeit für einige Firmen wegen der Art ihrer Geschäftstätigkeit unter Umständen nicht akzeptabel ist, können Anbieter diesen Kunden eine physisch isolierte Infrastruktur anbieten und die mit der Pflege der Software und Hardware verbundenen Zusatzkosten diesen Kunden in Rechnung stellen. Microsoft Business Productivity Online Suite (BPOS) und CRM Online sind gute Beispiele für SaaS. Microsoft bietet gegen Zusatzgebühren auch ein dediziertes Hosting für diese Dienste an.

Im SaaS-Feld sind Anwendungen für die Zusammenarbeit, die ein Problem für viele Unternehmen lösen, sehr erfolgreich. Weil die Hardware- und Softwarekonfiguration für die Endanwender transparent ist, müssen die Kunden in diesem Bereich kaum, wenn überhaupt, IT-Experten beschäftigen. Einige SaaS-Anwendungen lassen sich über die Konfiguration von Endanwendern anpassen, die meisten können jedoch nicht angepasst werden. Daher wird der Bedarf an Entwicklern im Kontext der SaaS-Anwendung reduziert.

SaaS kann zu einer frühren Marktreife der Anwendungen beitragen und die häufig beklagten Probleme hinsichtlich der Abstimmung von IT- und Geschäftsinteressen lösen. In frühen Phasen der SaaS-Einführung in einem Unternehmen kann "Shadow-IT" (z. B. ein kleines Team von Programmierern, die einzelnen Geschäftsbereichen zugeordnet sind und gut mit Tabellenkalkulationen umgehen können) von den unternehmensweiten Initiativen ablenken und Unternehmensarchitekten schlaflose Nächte bescheren. Der Grund hierfür ist, dass SaaS Geschäftsbereiche in die Lage versetzt, die IT-Beschaffungsverfahren zu umgehen. Unternehmensarchitekten müssen sich dessen bewusst sein und die Geschäftsbereiche über die Bedeutung der zentralen Kontrolle aufklären. Sie sollten auch neue Kontrollverfahren entwerfen oder die vorhandenen Verfahren verändern, um SaaS Raum zu bieten. 

Aktuelle IT-Umgebungen hindern kleine und mittlere Unternehmen unter Umständen daran, ihre Geschäftstätigkeit unter optimalen Bedingungen auszuführen, weil sie wegen der Last der enormen IT-Investitionen nicht die hierfür notwendigen Mittel beschaffen können. SaaS kann jeder Firma dieselbe Art von IT-Mitteln bieten, die derzeit nur für große Unternehmen erschwinglich sind. Da SaaS keine große IT-Investitionen erfordert, trägt SaaS zur Chancengleichheit zwischen Unternehmen bei, indem IT-Dienstleistungen, die früher großen Unternehmen vorbehalten waren, für kleine Unternehmen finanziell tragbar werden.

Auf der Seite der Dienstanbieter kann jede kleine Firma SaaS-Anbieter werden und mit großen Softwarehäusern konkurrieren. Diese Firmen können sich jetzt auf ihre Stärken in ihrem Kernbereich konzentrieren, statt knappe Finanzmittel für den Kauf und die Verwaltung der Hardware- und Softwareinfrastruktur aufzubringen. 

Plattform als Dienst (PaaS, Platform as a Service)

Mit SaaS lassen sich anscheinend alle Softwareanforderungen einer Firma erfüllen. Jede Firma hat jedoch eine spezielle IT-Persönlichkeit, die sich aus der vorhandenen älteren Technologie sowie dem speziellen Geschäftsfeld ergibt. Da es oft unmöglich ist, für jedes Geschäftsfeld einen SaaS-Dienst zu finden, müssen Firmen weiterhin Anwendungen entwickeln. Plattform als Dienst (PaaS) erfüllt die Anforderungen derjenigen, die benutzerdefinierte Anwendungen als Dienste erstellen und ausführen möchten. Es könnte sich dabei um Internetdienstanbieter, Mehrwertdiensteanbieter, IT-Shops von Unternehmen oder jeden Anderen handeln, der benutzerdefinierte Anwendungen benötigt. PaaS bietet gehostete Anwendungsserver, die über eine fast unbegrenzte Skalierbarkeit verfügen, die sich aus den großen Ressourcenpools ergibt, auf die sie sich stützen. PaaS stellt auch die notwendigen unterstützenden Dienste bereit, wie Speicherkapazität, Sicherheit, Integrationsinfrastruktur und Entwicklungswerkzeuge für eine komplette Plattform.

Ein Dienstanbieter bietet eine vorkonfigurierte, virtualisierte Anwendungsserverumgebung an, auf der Entwickler Anwendungen bereitstellen können. Da die Serviceanbieter sowohl die Hardware (Patches, Upgrades usw. durchführen) als auch die Betriebszeit des Anwendungsserver verwalten, wird der Bedarf an IT-Experten minimiert. Entwickler erstellen Anwendungen und versehen die Anwendungen mit Ressourcenbeschreibungen. Nach der Entwicklung bindet das Bereitstellungsmodul die notwendigen Infrastrukturfunktionen, die in den Deskriptoren deklariert wurden, an die Anwendung. Zu diesen Ressourcen können Netzwerkendpunkte, Lastenausgleichsmodule, CPU-Kerne, Arbeitsspeicher und Softwareabhängigkeiten zählen. Die Kombination von bedarfsgesteuerter Skalierbarkeit sowie Hardware- und Anwendungsserververwaltung befreit die Entwickler von Infrastrukturfragen und ermöglicht es ihnen, sich auf die Anwendungsentwicklung zu konzentrieren. PaaS eignet sich allgemein für ganz neue Anwendungen, da ältere Anwendungen häufig stark überarbeitet werden müssen, damit sie den Sandbox-Regeln entsprechen.

Infrastruktur als Dienst (IaaS, Infrastructure as a Service)

Infrastruktur als Dienst (IaaS) ähnelt dem traditionellen Hosting, bei dem Unternehmen die Hostumgebung als logische Erweiterung des firmeninternen Datencenters nutzen. Die Server (physisch und virtuell) werden bei Bedarf gemietet, und die IT-Experten, die die Infrastruktur verwalten, haben uneingeschränkte Kontrolle über die Softwarekonfiguration. Einige Provider lassen möglicherweise sogar eine flexible Hardwarekonfiguration zu, wodurch der Dienst teurer wird als ein entsprechendes PaaS-Angebot.

Die Softwarezusammenstellung kann Betriebssysteme, Anwendungsplattformen, Middleware, Datenbankserver, ESBs (Enterprise Service Busses), Komponenten und Frameworks von Drittanbietern sowie Verwaltungs- und Überwachungssoftware umfassen. Die Freiheit, den Anwendungsserver zu wählen, bedeutet auch Flexibilität in der Wahl der Entwicklungswerkzeuge. Diese Art von Flexibilität erhöht die Komplexität der IT-Umgebung, da die It-Experten des Kunden die Server genauso warten müssen, als handelte es sich um firmeninterne Server. Zu den Wartungsaufgaben können Patches und Aktualisierungen des Betriebssystems und des Anwendungsservers, Lastenausgleich, Failover-Clustering von Datenbankserver, Sicherung und Wiederherstellung und viele anderen Aktivitäten gehören, durch die die Risiken von Hardware- und Softwareausfällen gemindert werden.

Das Entwicklungsteam erstellt, testet und installiert Anwendungen unter Berücksichtigung der Hardware- und Softwarekonfiguration der Server. Häufig ist der Kunde für die Notfallwiederherstellung und die Kontinuität des Geschäftsbetriebs verantwortlich. Ein wichtiger Vorteil von IaaS besteht darin, dass die Migration von älteren Anwendungen in die Cloud möglich ist. Da die Flexibilität von IaaS die Bildung jeder beliebigen Konfiguration zulässt, ist es schwierig, Anwendungen zwischen Cloud-Anbietern zu portieren. Die Migration älterer Anwendungen ist das Argument für IaaS, da sich damit die Unternehmensinfrastruktur in der Cloud nachbilden lässt. Die Flexibilität von IaaS ermöglicht auch neue Anwendungen, die ein signifikantes Maß an Kontrolle über die Softwarekonfiguration erfordern. Manche Anwendungen erfordern beispielsweise die Installation von Bibliotheken oder Diensten von Drittanbietern, und IaaS lässt eine solche Installation ohne Einschränkungen zu.  

Die Windows Azure-Plattform bietet alle Vorteile von PaaS und verspricht gleichzeitig die gleiche Flexibilität wie IaaS. Dies wird in Abbildung 1 dargestellt. Die Windows Azure-Plattform vereint einen großen Pool von Rechen- (herkömmliche Server), Netzwerk- und Speicherressourcen in einer Utility Computing-Umgebung, aus der Kunden bei Bedarf Ressourcen abrufen können und nur für deren Nutzung zahlen müssen. Wie für Cloud-Umgebungen typisch, hilft die Windows Azure-Plattform den Kunden, im Vorhinein fällige Kapitalaufwendungen zu vermeiden, und sie erlaubt es, die IT-Ressourcen je nach Bedarf zu erweitern.

Windows Azure-Plattform

Die Windows Azure-Plattform stellt einen gehosteten Anwendungsserver und die für die Erstellung und Ausführung von Windows-Anwendungen notwendige Speicher-, Netzwerk- und Integrationsinfrastruktur zur Verfügung. Die Windows Azure-Plattform stützt sich auf einen großen Pool herkömmlicher Hardware und bildet daraus die Utility Computing-Umgebung. In Abbildung 2 ist das Ressourcenmodell der Windows Azure-Plattform dargestellt, wobei virtualisierte Speicher-, Netzwerk- und Rechenressourcen bei Bedarf jeweils nach den für die betreffende Bereitstellung aktuell festgelegten Richtlinien bereitgestellt werden. Der Fabric Controller ist das Gehirn des gesamten Ökosystems und verfügt über einen Satz dedizierter Ressource, die nicht Bestandteil des Anwendungsressourcenpools sind. Da der Fabric Controller nicht ausfallen kann, stellt er eine äußerst redundante Hardware- und Softwareumgebung bereit.

Abbildung 2 Konzeptionelle Ansicht der Recheninfrastruktur (die Windows Azure-Konfiguration kann sich davon unterscheiden)

Der Rechenressourcenpool umfasst herkömmliche Ressourcen, die durch den Fabric Controller mit Fehlertoleranz ausgestattet wurden. Der Fabric Controller ist auf die Früherkennung von Anwendungsfehlern ausgelegt und startet weitere Instanzen, um vertragliche Vereinbarungen zum Servicelevel einzuhalten. Da die Windows Azure-Umgebung eine vollständige Plattform für das Hosten von Anwendungen ist, stellt sie systemische Qualitäten der Anwendung sicher, indem sie durch die bedarfsgesteuerte Bereitstellung nahezu unbegrenzte Ressourcen bietet. Ungenutzte Ressourcen werden wieder in den Pool zurückgeführt, sodass die Ressourcen besser genutzt werden. Zu den Ressourcen gehören Rechenzyklen, virtualisierte Speicherkapazitäten für Persistenz und virtualisierte Netzwerkressourcen für ein dynamische Neukonfiguration von privaten und öffentlichen Netzwerkrouten. Die physischen Konfigurationen dieser Ressourcen sind definitionsgemäß für die Anwendungsarchitekten und Entwickler nicht sichtbar.

Wie stellen die Anwendungsbesitzer diese Ressourcen dann bereit? Zum Telefonhörer zu greifen und einen IT-Experten anzurufen, wie wir es in traditionellen standortgebundenen Umgebungen tun, kommt hier nicht in Frage, da die riesigen Datencenter der Windows Azure-Plattform von einer Handvoll Experten verwaltet werden, die sich stark auf die Automatisierung stützen. Im normalen täglichen Betrieb des Datencenters ist kein Eingreifen eines Menschen erforderlich. Die Windows Azure-Plattform ermöglicht es Anwendungsbesitzern, die notwendigen Ressourcen mithilfe von maschinenlesbaren Modellen, die Ressourcenbeschreibungen enthalten, bereitzustellen. Im Kontext der Windows Azure-Plattform werden die Ressourcenbeschreibungen Dienstmodelle genannt. Diese Dienstmodelle legen die Anwendungsressourcen und deren Abhängigkeiten ausreichend fest, sodass die komplette Laufzeitinfrastruktur ohne Beteiligung von Mitarbeitern bereitgestellt werden kann. Wegen dieser Automatisierung hat die Anwendungsinfrastruktur eine Bereitstellungszeit, die oft unter fünf Minuten liegt. Wenn Sie dies mit dem Beschaffen-und-Bereitstellen-Ansatz der typischen standortgebundenen Umgebungen vergleichen, dann begreifen Sie die Stärke von Cloud Computing.

Rechenkapazitäten

Die Rechenkapazität der Windows-Azure-Plattform ist für die Bereitstellung von CPU-Zyklen zum Ausführen von Anwendungen verantwortlich. Die Anwendungen werden in virtualisierten Umgebungen gehostet, um physische Abhängigkeiten von der zugrundeliegenden Hardware und vom Betriebssystem zu verhindern. Eine lockere Kopplung von Anwendungen wird über virtualisierte Ressourcen erreichen, zu denen lokale Dateien, persistenter Speicher (strukturiert und unstrukturiert) sowie Diagnose- und Instrumentierungsressourcen gehören. Die Hostumgebung wird als virtueller Computer implementiert, damit sich Anwendungsfehler nicht auf andere Anwendungen auswirken, die auf derselben physischen Hardware ausgeführt werden.

Anwendungen werden in der Windows Azure-Plattform als Pakete bereitgestellt, die Rollen und den zugehörigen ausführbaren Code sowie Ressourcen enthalten. Eine Azure-Rolle ist eine deklarative Beschreibung der Merkmale der Hostumgebung. Wenn eine bereitgestellte Anwendung aktiviert wird, analysiert die Azure-Bereitstellungsumgebung das Dienstmodell, wählt anhand des Rollentyps das vorkonfigurierte VM (Virtual Machine)-Abbild aus, kopiert die Anwendungsbits auf den virtuellen Computer, fährt den Computer hoch und startet die notwendigen Anwendungsdienste. Die in Abbildung 3 gezeigte Dienstdefinition stellt die Anwendung "Shopping List" dar, auf die in diesem Artikel immer wieder verwiesen wird.

Abbildung 3 Dienstmodell für die Rollen WebRole und WorkerRole

ShoppingListService-Definition

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="ShoppingList">
<WebRole name="ShoppingList_WebRole">
<LocalResources>
<LocalStorage name="ShoppoingList_ImageCache" sizeInMB="100" 
cleanOnRoleRecycle="false"/>
</LocalResources>
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistOut"/>
</ConfigurationSettings>
</ WebRole>
< WorkerRole name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistIn"/>
</ConfigurationSettings>
< WorkerRole />
</ServiceDefinition>

ShoppingListService-Konfiguration

<?xml version="1.0"?>
<ServiceConfiguration serviceName="ShoppingList">
</Role>
<Role name="ShoppingList_WebRole">
<Instances count="3" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the following two lines for application 
storage needs on  local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistOut" value="shoppinglistq"/>
</ConfigurationSettings>
</Role>
<Role name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the followign two lines for local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistIn" value="shoppinglistq"/>
</ConfigurationSettings>
</Role></ServiceConfiguration>

Die in Abbildung 3 beschriebene Anwendung "Shopping List" repräsentiert drei Instanzen von WebRole und zwei Instanzen von WorkerRole. Für den Webdatenverkehr zu den verschiedenen WebRole-Instanzen wird automatisch ein Lastenausgleich durchgeführt, und alle drei Instanzen werden mit SSL- sowie HTTP-Endpunkten pro Dienstmodellbeschreibung bereitgestellt. Um ein komplettes Versagen der Anwendung zu vermeiden, verteilt der Fabric Controller die Zuweisungen über viele Fehlerdomänen. Die Fehlerdomäne Organisation ist viel komplexer als die vereinfachte Darstellung in Abbildung 2. Der Einfachheit halber wollen wir jedes Serverregal mit dem zugehörigen Netzwerkswitch und Netzteil als eine Fehlerdomäne betrachten.

Wie Abbildung 2 zeigt, hat der Fabric Controller anfangs eine WebRole-Instanz aus jedem Fehlerdomänen-Regal Nr. 1, 3 bis n zugewiesen. Ich untersuche die Zuverlässigkeit der gesamten Rechenebene von Windows Azure auf dem Hintergrund einiger hypothetischer Ereignisse. Während Ereignis Nr 1 auftrat, reagierten WebRole Nr. 1 und WorkerRole Nr. 1 infolge eines Stromausfalls nicht mehr. Der Fabric Controller beginnt mit der Bereitstellung von WebRole Nr. 1 und WorkerRole Nr. 1 in den noch verfügbaren Serverregalen Nr. 2 und Nr. 3. Kurze Zeit später tritt Ereignis Nr. 2 auf, in dessen Verlauf eine Systemintegritätsprüfung bei der neu zugewiesenen WebRole-Instanz Nr. 1 wegen eines Anwendungsfehlers fehlschlägt. Jetzt beginnt der Fabric Controller, WebRole Nr. 1 auf einem der anderen verfügbaren Serverregale bereitzustellen.

Die Verfügbarkeit der Anwendung wird im Verlauf dieser Ereignisse nicht beeinträchtigt. Die Webseitenanforderungen werden weiterhin von mindestens zwei WebRole-Instanzen bedient, während mindestens eine WorkerRole-Instanz Transaktionselemente aus Warteschlangen abruft und in den Windows Azure-Speicher schreibt. Der Fabric Controller versucht, die drei funktionstüchtigen WebRole-Instanzen und die beiden WorkerRole-Instanzen zu jedem gegebenen Zeitpunkt im Gleichgewicht zu halten. In der Praxis sind die Serverregale möglicherweise mit redundanten Netzteilen und Netzwerkswitches ausgestattet, sodass Rollen häufig neu zugeordnet werden. weil Anwendungsfehler auftreten oder weil aufwärtsskaliert werden muss, um Skalierbarkeitsziele zu erreichen.

Das Dienstmodell "Shopping List" erfordert zwei WorkerRole-Instanzen, um eine einzelne Fehlerquelle zu vermeiden. Obwohl die Webebene und die Batchebene durch die Windows Azure-Warteschlangen voneinander abgekoppelt werden, ist es empfehlenswert, mindestens zwei WorkerRole-Instanzen zum Hosten zeitkritischer und erfolgsentscheidender Batchdienste anzufordern. Eine WorkerRole-Instanz genügt möglicherweise, wenn der gehostete Dienst nicht zeitkritisch ist.

Abbildung 1 zeigt, dass die Windows Azure-Plattform alle Vorteile von PaaS besitzen und gleichzeitig die gleiche Flexibilität wie IaaS bieten soll. Dies wird durch das richtlinienbasierte Bereitstellungsmodell ermöglicht, das sich in Webrollen, Workerrollen, CGI-Rollen und einer Vielzahl anderer, in der Zukunft zu erwartenden Rollen manifestiert. Die Liste der unterstützten Rollen wird weiter wachsen, um den unterschiedlichen Anwendungs- und Bereitstellungsanforderungen der Kunden gerecht zu werden.

Kostenorientierte Architektur für die Cloud

Architekturentscheidungen haben tief greifende Auswirkungen auf die Wirtschaftlichkeit kleiner und großer Unternehmen. Auch wenn es beim Cloud Computing um die IT-Agilität geht, müssen Überlegungen hinsichtlich der Betriebsausgaben von Unternehmen während des architektonischen Entwurfs der Lösung berücksichtigt werden. Die Architektur einer Cloud-Anwendung muss Funktionalität und systemische Qualitäten (Skalierbarkeit, Verfügbarkeit, Zuverlässigkeit und Leistung) und gleichzeitig eine Optimierung der Betriebsausgaben bieten. Anwendungsarchitekten beachten in firmeninternen Situationen kaum die Kosten der Speicherkapazität, die Netzwerkbandbreite oder die Kosten von Rechenzyklen, da es sich hierbei um Ausgaben auf der Organisationsebene handelt.

Beispielsweise gehört die Optimierung des Anwendungsspeichers meist nicht zu den wichtigsten Aufgaben eines Architekten, da die mit dem Speicher verbundenen Kosten nicht zu den Betriebskosten zählen. Bei standortinternen Systemen besteht die oberste Priorität darin, systemische Qualitäten bereitzustellen, ohne den dafür vorgesehen Budgetrahmen zu überschreiten. Im Kontext des Cloud Computing wird eine auf die Optimierung der Betriebsausgaben abzielende Architektur von Systemen zu einem wichtigen Element der Softwareentwicklung.

Ich untersuche das Kostenmodell der Windows Azure-Plattform auf dem Hintergrund der in Abbildung 4 dargestellten Anwendung "Shopping List". Das Diagramm zeigt die logische Architektur der Anwendung "Shopping List", wobei Pfeile die Datenbewegung angeben. Die gestrichelten Pfeile stehen für Bandbreitennutzung innerhalb des Datencenters, die durchgezogenen Linien zeigen die Datenbewegungen in das und aus dem Cloud-Datencenter.

Abbildung 4 Abrechnungsmodell für Anwendungen auf der Windows Azure-Plattform

Bei der Windows Azure-Plattform werden nur Eingangs- und Ausgangsgebühren für Datenübertragungen berücksichtigt, die Übertragung von Daten innerhalb eines Datencenters wird ignoriert. Für alle Daten, die in Windows Azure-Warteschlangen geschrieben werden, werden keine Bandbreite- oder Speichergebühren berechnet, da die Speichernutzung von Warteschlangen äußerst kurzlebig ist. Bei den Warteschlangen werden jedoch Gebühren pro Transaktion in Rechnung gestellt. Als Transaktion gilt das Suchen, Lesen und Schreiben von Warteschlangeneinträgen.

Die Gebühren für die Servernutzung in der Windows Azure-Plattform basieren auf der Anzahl von Rollen und der Zeitdauer, für die eine Anwendung bereitgestellt wird. Das bedeutet, dass das Abrechnungssystem von Windows Azure-Plattform selbst dann Gebühren pro Stunde pro Instanz für die Rollenzustände "angehalten" und "gestartet" in Rechnung stellt, wenn der Anwendung keine Anforderungen von Endanwendern vorliegen. Daher ist es ratsam, unter Berücksichtigung der Anwendungserfordernisse im Vorhinein die Anzahl von aktivieren Rollen zu reduzieren. Derzeit ist dies ein manueller Vorgang. Möglicherweise können Sie die Anwendung jedoch auf der Grundlage der Anwendungsskalierbarkeitsmuster automatisch skalieren, indem Sie die Diagnosedaten und die Dienstverwaltungs-API nutzen. Die Nutzung von Windows Azure-Tabellen, -Warteschlangen und –Blobs zieht Speicherkosten nach sich, die monatlich pro verzeichnetem GB abgerechnet werden. Die Preiskalkulation von Windows Azure, die zu dem Zeitpunkt, zu dem dieser Artikel verfasst wurde, öffentlich angekündigt wurde, finden Sie in Abbildung 5.

Abbildung 5 Windows Azure-Preiskalkulation

Windows Azure-Funktion	Gebühr	Anmerkungen
Servernutzung	Klein: $0,12 /Dienststunde Mittel: $0,24 /Dienststunde Groß: $0,48 /Dienststunde Extragroß: $0,96 /Dienststunde	Die Gebühren werden durch die aktiven Anwendungen zugewiesenen Rollen bestimmt. Klein: (1,6 Ghz), 1,75 GB Arbeitsspeicher (mittlere EA-Kapazität) Mittel: (1,6 Ghz), 3,5 GB Arbeitsspeicher Groß: (1,6 Ghz), 7,0 GB Arbeitsspeicher Extragroß: (1,6 Ghz), 14,0 GB Arbeitsspeicher
Windows Azure-Blobs und Tabellen	$0,15/GB	In jedem Abrechnungszyklus gemessenes Tagesmittel. Nähere Angaben dazu, wie diese Gebühren berechnet werden, finden Sie unten, da dies ausführlicher erläutert werden muss.
Transaktionen	$0,01/10.000 Transaktionen	Das Erstellen, Lesen, Aktualisieren und Löschen von Einträgen in Windows Azure-Warteschlangen, -Blobs und –Tabellen wird als Transaktion betrachtet.
SQL Azure: Web Edition	$9,99/Monat (1 GB RDBMS)	Metadaten einer großen Anwendung oder ein Produktkatalog einer kleinen E-Commerce-Website, auf der einige Hundert Artikel angeboten werden.
SQL Azure: Business Edition	$99,99/Monat (10 GB RDBMS)	Nützlich für Unternehmen mittlerer Größe. Durch die gemeinsame Nutzung von Daten ist es auch möglich, Anwendungen mit großen Datenspeicheranforderungen zu erstellen.
AppFabric	$0,15/100.000 Nachrichtenvorgängen	Unter Nachrichtenvorgängen werden Dienstbusnachrichten, Anforderungen von Zugriffssteuerungstoken oder API-Aufrufe zur Dienstverwaltung verstanden.
Eingehende GB	$0,10/GB ($0,30 in Asien)	Es werden nur die Daten in Rechnung gestellt, die in das und aus dem Datencenter übermittelt werden.
Ausgehende GB	$0,15/GB ($0,45 in Asien)	Es werden nur die Daten in Rechnung gestellt, die in das und aus dem Datencenter übermittelt werden.

Die Preiskalkulation der Windows Azure-Plattform ist bis auf eine Ausnahme einfach, und diese Ausnahme besteht in der Abrechnung der von Blobs und Tabellen verwendeten Speicherkapazität. Der Windows Azure-Speicherverbrauch eines Benutzerkontos wird jeden Tag innerhalb eines Abrechnungszyklus gemessen, und daraus wird das Tagesmittel berechnet. Zur Berechnung der Gebühr wird dieses Tagesmittel mit $0,15/GB multipliziert. Wenn beispielsweise an Tag 1 20 GB Daten gespeichert, an Tag 2 weitere 10 GB hinzugefügt, an Tag 3 noch einmal 5 GB hinzugefügt, an Tag 4 dann 5 GB gelöscht werden und im restlichen Abrechnungszyklus keine weiteren Aktivitäten ausgeführt werden, dann wird der Preis für die Speichernutzung nach der unten dargestellten Formel berechnet:

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

Hier wird ein Abrechnungszyklus von 30 Tagen vorausgesetzt. Durch die tägliche Messung der Speichernutzung wird sichergestellt, dass auch Anwendungen mit sehr kurzlebigen Speicheranforderungen für die Speichernutzung bezahlen, anders als bei Systemen, bei denen die Speichernutzung nur am Ende des Abrechnungszyklus gemessen wird.

Wie bereits oben erwähnt, ist die Architektur ein wichtiger Faktor in Bezug auf die monatlichen Betriebskosten einer Anwendung. Wenn eine Anwendung beispielsweise viele Daten generiert und nur die aktuellsten Daten (z. B. die letzten beiden Wochen) für die Funktionalität der Anwendung benötigt werden, kann die Architektur so angelegt werden, dass die unnötigen Daten gelöscht oder regelmäßig auf firmeninterne Systeme übertragen werden. Es kann günstiger sein, eine einmalige Bandbreitengebühr zu zahlen als fortwährend Speicherkosten zu verursachen. Dasselbe kann für Referenzdaten gelten, die nicht mehr Bestandteil des aktiven Datensatzes sind. Dieser Ansatz ist für Firmen geeignet, die bereits in Datenarchivierungskapazitäten investiert haben.

Das Anwendungsszenario

Die verschiedenen Aspekte der Windows Azure-Plattform werden hier im Kontext eines branchenüblichen E-Commerce-Szenarios betrachtet: der Anwendung "Shopping List". Ich konzentriere mich auf die Erstellung einer Einkaufsliste und das Speichern dieser Liste für die spätere Verwendung beim Einkaufen im Geschäft. Die Webbenutzeroberfläche stellt die Einkaufsliste zusammen und nutzt Webdienste, um die Liste im Windows Azure-Speicher zu speichern. Aus Gründen der Skalierbarkeit schreibt die Webebene die Einkaufslisten in eine Windows Azure-Warteschlange. In regelmäßigen Abständen ruft ein Batchprozess die Listen aus den Warteschlangen ab und speichert sie in Windows Azure-Tabellen. Ich verwende die auf Windows Azure basierende Authentifizierung und rollenbasierte Sicherheit, um praxisbezogene Lösungsaspekte zu demonstrieren.

Abbildung 6 Anwendung "Shopping List" auf der Windows Azure-Plattform

Im Kontext der kostenorientierten Architektur, die zuvor besprochen wurde, wirken sich verschiedene Entscheidungen auf die monatlichen Betriebskosten aus. Im Folgenden werden einige Aspekte aufgeführt, die beim Architekturentwurf zu berücksichtigen sind:

1. Wachstumsrate der Referenzdaten
2. Wachstumsrate der Transaktionsdaten
3. Erfassungsfrequenz von Daten zur Erstellung von Verhaltensprofilen
4. Wachstumsrate der Geschäftsereignisdaten
5. Erfassungsfrequenz der Systemereignisdaten
6. Produktbezogene Medieninhalte
7. Verwendung von Warteschlangen oder direkte Interaktion mit persistentem Speicher

Da mein Anwendungsszenario nicht viele Multimediadaten enthielt, war dies kein großer Faktor in der Kostengleichung, bei Websites, die Videos, Bilder oder Audiostreams anbieten, kann es jedoch ein sehr wichtiger Faktor sein. Abbildung 7 zeigt die monatlichen Betriebskosten für eine typische Anwendung auf der Windows Azure-Plattform. In der Tabelle sind die Personalkosten für Entwicklung, operative Unterstützung und Endanwenderunterstützung nicht enthalten.

Abbildung 7 Windows Azure-Betriebskostenrechner für eine E-Commerce-Anwendung

Da in einer Cloud Computing-Umgebung weniger Mitarbeiter zur operativen Unterstützung erforderlich sind, sollte dies beim Vergleich der Rendite von firmeninternen Systemen und der Cloud berücksichtigt werden. Außerdem ist es wichtig, die Energiekosten und die abgeschriebenen Kapitalaufwendungen in die Renditeberechnung aufzunehmen. Aktuelle Kostenmodelle für firmeninterne Anwendungen enthalten diese Kosten oft nicht, da es sehr schwierig ist, den Energieverbrauch pro Anwendung aufzuschlüsseln. Das Gleiche gilt für Kühlung und Aufstellungsfläche. Renditerechner können wohlbegründete Vermutungen anstellen, wenn keine objektive Aufschlüsselung der Kosten gegeben ist.

Der einfache Kostenrechner, der in Abbildung 7 dargestellt ist, schätzt die Betriebskosten von Anwendungen, die auf der Windows Azure-Plattform gehostet werden. Dieses auf Microsoft Excel basierende Tool lässt verschiedene Eingabeparameter für eine typische E-Commerce-Anwendung zu, und es berechnet die monatlichen Betriebskosten anhand der in Abbildung 5 gezeigten Preistabelle der Windows Azure-Plattform. Denken Sie daran, dass die hier verwendeten Standardparameter fiktiv sind. Sie müssen Ihr eigenes System betrachten, bevor Sie auf der Grundlage der Toolausgabe Entscheidungen treffen. Dieser Kostenrechner berücksichtigt die Anzahl monatlicher Besucher und setzt voraus, dass jeder Besucher eine bestimmte Anzahl von Seiten anzeigt und Transaktions- und Ereignisdaten erzeugt. Das Windows Azure-Plattformteam erstellte ein etwas umfassenderes Tool, das die monatlichen Kosten einer Anwendung berechnet und auch die Gesamtbetriebskosten (TCO) von firmeninternen Anwendungen mit den Windows Azure-Kosten vergleicht. Sie finden das TCO-Tool für Windows Azure unter microsoft.com/windowsazure/tco.

Wie in Abbildung 7 gezeigt, generiert unsere fiktive Anwendung in einem Monat 9000 GB Daten, was ca. $1.350 pro Monat kosten würde, wenn diese Daten in Windows Azure-Tabellen gespeichert würden. Beachten Sie, dass in Abbildung 7 nur der Speicherbedarf zu einem gegebenen Zeitpunkt dargestellt wird. Im weiteren Anwendungsbetrieb können Gebühren für Ereignisdaten auflaufen. Diese Kostenn können optimiert werden, indem die Menge der erfassten Ereignisdaten anhand von Erfahrungswerten aus dem Anwendungsbetrieb angepasst wird. Dieser Kostenrechner berücksichtigt die Anzahl monatlicher Besucher und arbeitet mit einer hypothetischen Anzahl von 10 Webrollen und 3 Workerrollen. Die monatliche Gesamtrechnung beläuft sich auf $3.571.

Stattdessen könnte die Anwendung auch so angelegt werden, dass die Ereignisdaten durch Zahlung einmaliger Bandbreitekosten ($0,10/GB ausgehender Daten) an ein bereits abgeschriebenes Speichersystem in der Firma, sofern vorhanden, übermittelt werden. Eine ähnliche Strategie könnte bei den Transaktionsdaten und den Daten zur Erstellung eines Verhaltensprofils verfolgt werden, um kumulative Speichergebühren zu vermeiden.

Gebühren für die Rechenkapazität sind naturgemäß nicht kumulativ und wirken sich daher weniger stark auf die allgemeinen Betriebskosten einer Anwendung aus. Es besteht jedoch die Möglichkeit, die Anzahl aktiver Web- und Batchrolleninstanzen auf der Grundlage des beobachteten Skalierbarkeitsprofils der Anwendung zu optimieren, um die Betriebsausgaben leicht zu senken. Die Nutzung der Rechenkapazität kann im Gegensatz zur Nutzung der Speicherkapazität jederzeit gesteuert werden. Die Speicherkosten hängen von architektonischen Entscheidungen ab, die sich nach Fertigstellung der Anwendung nicht so leicht revidieren lassen. Ich rate daher dazu, die Persistenzarchitektur gleich richtig zu planen.

Neben dem Kostenmodell der Anwendung ist für große Unternehmen die Anwendungssicherheit von Bedeutung, auf die nachfolgend eingegangen wird.

Sicherheit des Rechenmoduls.

Unternehmen sind heikel in Bezug auf die Anwendungs- und Datensicherheit in der Cloud. Während sich Microsoft um die Sicherheit der Datencenter, der Infrastruktur und des Betriebssystems kümmert, liegt die Anwendungssicherheit noch in der Verantwortung der Anwendungsbesitzer. Ich untersuche die Anwendungssicherheit auf dem Hintergrund meiner Webanwendung "Shopping List". Die Sicherung einer Anwendung auf der Windows Azure-Plattform ähnelt der Sicherung firmeninterner Anwendungen. Die Windows Azure-Plattform stellt verschiedene Systemkomponenten bereit, die Entwickler bei der Integration von Sicherheitsfunktionen in Anwendungen unterstützen. Diese Systemkomponenten ermöglichen eine grundlegende, abgeschlossene Authentifizierung und Autorisierung gegenüber Verbundszenarien, die für große Unternehmen geeignet sind.  

Basic Identity

Wie der Name suggeriert, wird bei einem Basic Identity-Modell eine in sich geschlossene Identitätsarchitektur implementiert, um die Anforderungen einer Anwendung oder einer gemeinsam untergebrachten Gruppe von Anwendungen zu erfüllen, die die gleiche Gruppe von Benutzern aufweisen und auf der Implementierungsebene eng an dasselbe Identitätssystem gebunden sind. Die Windows Azure-Plattformbeispiele enthalten einen Satz von ASP.NET-Anbietern (Mitgliedschaft, Rolle, Profil und Sitzung), die zur Implementierung einer Basic Identity-Lösung verwendet werden können. Die Windows Azure-ASP.NET-Anbieter werden im Windows Azure-Speicher implementiert, der Windows Azure-Tabellen und –Blobs umfasst. Diese Provider implementieren die ASP.NET-Anbieterverträge und nutzen die StorageClient-APIs, die im Windows Azure-Plattform-SDK enthalten sind. In Abbildung 8 werden die Anbieter schematisch dargestellt.

Abbildung 8 Windows Azure-ASP.NET-Anbieter

Damit die Anwendungen Windows Azure-ASP.NET-Anbieter nutzen können, muss die Web.config-Datei abgeändert werden. Die Standardanbieter müssen aus dieser Datei entfernt und die neuen Anbieter müssen eingefügt werden. Die in Abbildung 9 dargestellten Konfigurationsänderungen ähneln den Änderungen, die in firmeninternen Anwendungen für benutzerdefinierte ASP.NET-Anbieter vorgenommen werden müssen.

Abbildung 9 Web.config-Änderungen für Windows Azure-ASP.NET-Anbieter

<system.web>
  ... ... ... ...
<authentication mode="Forms" />
<!-- Membership Provider Configuration -->
<membership defaultProvider="TableStorageMembershipProvider"
userIsOnlineTimeWindow="20">
<providers>
<clear/>
<add name="TableStorageMembershipProvider"
type="Microsoft...AspProviders.TableStorageMembershipProvider"
description="Membership provider using Azure storage"
applicationName="ShoppingList"
... ... ... ... ...
minRequiredNonalphanumericCharacters="0"
requiresUniqueEmail="true"
passwordFormat="Hashed"/>
</providers>
</membership>
<sessionState mode="Custom"
customProvider="TableStorageSessionStateProvider">
<providers>
<clear />
<add name="TableStorageSessionStateProvider"
type="Microsoft...AspProviders.TableStorageSessionStateProvider"
applicationName="ShoppingList"/>
</providers>
</sessionState>
<roleManager enabled="true"
defaultProvider="TableStorageRoleProvider"
cacheRolesInCookie="true"
cookieName=".ASPXROLES"
cookieTimeout="30"
... ... ... ... ...
cookieProtection="All">
<providers>
<clear/>
<add name="TableStorageRoleProvider"
type="Microsoft....AspProviders.TableStorageRoleProvider"
description="Role provider using table storage"
applicationName="ShoppingList" />
</providers>
</roleManager>
... ... ... ...
</system.web>

Nachdem die ASP.NET-Anbieter konfiguriert wurden, können Authentifizierung, Autorisierung und Benutzerprofile ähnlich wie bei herkömmlichen ASP.NET-Anwendungen implementiert werden. Beachten Sie, dass die in Abbildung 9 dargestellte Konfiguration einen speicherbasierten Windows Azure-Sitzungsanbieter umfasst, der das Speichern der Sitzungszustände auf einem dauerhaften Speichermedium zulässt. Da die Lastenausgleichsmodule von Windows Azure nicht dafür sorgen, dass ein bestimmter Benutzer immer zum selben Server zurückgeleitet wird, auf dem sich die Sitzungsdaten befinden, ist das Speichern der Sitzungsdaten auf Windows Azure-Speicher benutzerfreundlicher hinsichtlich der sitzungsbasierten Personalisierung. Das Basic Identity-Modell eignet sich für Anwendungen mit Benutzeridentitätslebenszyklen (Erstellung, Nutzung und Löschung eines Benutzerkontos), die in derselben Anwendung beginnen und enden. Für eine Basic Identity-Implementierung können beispielsweise folgende Gründe sprechen:

• Eine Anwendung möchte im Vollbesitz der Benutzeridentitätsdaten bleiben.
• Es fehlt die Infrastruktur, die für die Implementierung eines Verbundidentitätsspeichers und den unterstützten Diensten erforderlich ist.
• Anwendungen mit einer kurzen Lebensdauer (z. B. Marketingwettbewerbe und Werbeaktionen), die eine Benutzerregistrierung erfordern.

Windows Azure-ASP.NET-Anbieter können auch zur Authentifizierung der Benutzer von AJAX- sowie Silverlight-Anwendungen verwendet werden. Die aus AJAX aufrufbaren Klassen AuthenticationService, ProfileService und RoleService, die in System.Web.Extensions.dll enthalten sind, können über die Windows Azure-Webrolle als SVC-Endpunkte veröffentlicht werden. Vergessen Sie nicht, dass diese Dienste ASP.NET-Kompatibilität für den Zugriff auf HTTP-kontextspezifische Daten erfordern. Der Artikel mit dem Titel "Erstellen von Branchenanwendungen für Unternehmen mit Silverlight, Teil 2" (msdn.microsoft.com/magazine/dd434653) enthält ausführliche Informationen zur Einrichtung der oben beschriebenen Dienste, sodass sie von Silverlight oder AJAX aufgerufen werden können.

Verbundidentitätsmodell

Verbundidentität ist notwendig für Anwendungen, die eine Versorgungskette, Wertschöpfungskette, Zusammenarbeit und soziale Netzwerke umfassen, sowie für Anwendungen, die populäre Identitätsspeicher im Internet integrieren. Der Windows Azure ASP.NET-Stapel kann mit WIF (Windows Identity Foundation) kombiniert werden, um die Zusammenarbeit mit einem oder mehreren Sicherheitstokendienstanbieter(n) zu ermöglichen. WIF funktioniert in Verbindung mit den vorab eingerichteten Vertrauensstellungen, die durch WS-Trust und WS-Federation ermöglicht werden. Abbildung 10 enthält eine konzeptionelle Darstellung der Anwendung "Shopping List", die mit zwei Tokenanbietern arbeitet (ein Anbieter befindet sich am Firmenstandort, und der andere Anbieter ist ein Vertragspartner).

Abbildung 10 Bei Windows Azure-Anwendungen können mehrere Tokendienste registriert werden

Die Vertrauensstellung beschreibt die STS-Endpunkte (STS, Secure Token Service, sicherer Tokendienst) und die X509-Zertifikate, die zum Signieren von Tokenanforderungen und –antworten notwendig sind. Abbildung 11 zeigt das Schema der Vertrauensstellung, deren XML-Darstellung zum Zeitpunkt der Bereitstellung in die Anwendung "Shopping List" eingebunden wird. Die Benutzer werden in ihrem jeweiligen System authentifiziert und der resultierende SAM (Security Assertion Markup Language)-Token wird an die anfordernde Anwendung weitergeleitet.

Abbildung 11 Beschreibung einer verbundenen Vertrauensstellung

Wie in Abbildung 10 dargestellt, leistet WIF die Anforderung an eine in der Konfiguration der Vertrauensstellung angegebene STS-URL für die Anwendung "Shopping List" weiter, wenn ein Benutzer auf sichere Webinhalte der auf der Windows Azure-Plattform gehosteten Anwendung "Shopping List" zugreift. Der Shopping List-STS erfasst Anmeldeinformationen, authentifiziert die Benutzer gegenüber Active Directory, konstruiert einen SAML-Token mithilfe von ADFS (Active Directory Federation Services, vormals "Geneva Server") und leitet sie über den Webbrowser an die Anwendung "Shopping List" weiter. WIF, das innerhalb der Shopping List-Site auf Windows Azure ausgeführt wird, extrahiert die SAML-Anforderungen und überprüft die Autorisierung.

Wenn mehrere STS beteiligt sind, muss die Website Tokenübersetzungslogik implementieren, um diverse Token in ein kanonisches Format zu konvertieren. Um die Auswirkungen der Einführung neuer STS in das System zu minimieren, kann die Tokenübersetzungslogik externalisiert oder in eine Komponente gekapselt werden, die sich modifizieren lässt, ohne dass sich dies auf die Anwendungen auswirkt, die sie nutzen. Abbildung 12 zeigt das Tokenübersetzungsschema, das in Verbindung mit WIF funktioniert.

Abbildung 12 Verbundidentitätssystem mit mehreren Tokenanbietern

Folgende Szenarien werden durch das Verbundidentitätsmodell ermöglicht:

• Firmeninterne Speicherung der Identitätsdatensätze zur Einhaltung gesetzlicher Bestimmungen
• Nutzung der bereits vorhandenen Sicherheitsinfrastruktur firmeninterner Anwendungen
• Zusammenarbeit mit Partnern in der Wertschöpfungs- und der Versorgungskette
• Einmalige Anmeldung bei firmeninternen Anwendungen und Anwendungen auf der Windows Azure-Plattform.

Häufig haben Großunternehmen bereits Authentifizierungsdienste und Verzeichnisserver implementiert, die zur Sicherung von Anwendungen herangezogen werden müssen. Die Windows Azure-Plattform ermöglicht es, die Cloud für eine beschleunigte Anwendungsbereitstellung zu nutzen und gleichzeitig von den Vorteilen der vorhandenen Sicherheitsinfrastruktur zu profitieren. Die Windows Azure-Plattform ist außerdem darauf ausgelegt, die Verwendung der Verbundidentität zuzulassen und dadurch die Zusammenarbeit zwischen Geschäftspartnern und Wertschöpfungsketten zu ermöglichen.

Windows Azure-Speicher

Anwendungen und Dienste, die auf der Windows Azure-Plattform bereitgestellt werden, können Windows Azure-Speicher als Persistenzspeicher für unstrukturierte und semistrukturierte Inhalte nutzen. Windows Azure-Speicher umfasst drei grundlegende Funktionen, die für die Erstellung professioneller Anwendungen und Dienste erforderlich sind: Tabellen, Blobs und Warteschlangen. Windows Azure-Speicher ist ein äußerst skalierbarer und höchst zuverlässiger Persistenzmechanismus, auf den auch die firmenintern gehosteten Anwendungen über Webdienst-Schnittstellen wie REST zugreifen können. Um den Datenschutz während der Datenübermittlung zu gewährleisten, unterstützt der Windows Azure-Speicher neben dem HTTP-Standardprotokoll auch den auf SSL (HTTPS) basierenden Zugriff. Skalierbarkeit und andere systemische Qualitäten werden durch eine große Speicherfarm erzielt, die aus herkömmlicher Serverhardware und Festplattenarrays besteht, die von der Windows Azure-Speichersoftware verwaltet wird. Um Skalierbarkeit und Verfügbarkeit zu garantieren, wird unter einer Reihe von Knoten ein Lastenausgleich für den Speicherzugriff durchgeführt. Jeder Knoten ist für eine endliche Menge an physischem Speicher zuständig. Für den Zugriff auf Speicher, der nicht im Zuständigkeitsbereich eines Knotens liegt, wird über eine Peer-to-Peer-Schnittstelle verwendet. Zuverlässigkeit wird durch die Redundanz der gespeicherten Entitäten (z. B. ShoppingList) auf mehreren Knoten erreicht. Die Speichersoftware erstellt bei jedem Schreibvorgang automatisch mehrere Kopien (drei zu dem Zeitpunkt, an dem dieser Artikel verfasst wurde) der Daten. Der Speicher unterstützt atomare transaktionale Schreibvorgänge, und die Transaktion wird erst abgeschlossen, nachdem alle Kopien auf die Datenträger geschrieben wurden. Abbildung 13 zeigt eine Sammlung herkömmlicher Speicherknoten, die den Windows Azur-Speicherdienst bilden.

Abbildung 13 Speicherdienst

Während der Nutzung kann ein Speicherdatenträger irgendwo ausfallen, und diese Möglichkeit wird durch das rote "X" bei Knoten Nummer 4 und 11 dargestellt. Sobald der Speicherdienst einen ausgefallenen Datenträger erkennt, repliziert er die Daten von einem funktionierenden Datenträger auf einen anderen Knoten. Der Speicherdienst entspricht zu jedem gegebenen Zeitpunkt stets den Kopierrichtlinien. Wie oben erwähnt, wird für die Anforderungen von Anwendungen ein Lastenausgleich über mehrere Knoten durchgeführt.

Diese Art von Architektur ist den extremen Anforderungen an die Skalierung zuträglich, die PaaS-Angebote in einer öffentlichen Cloud stellen, z. B. die Windows Azure-Plattform. Wie in Abbildung 13 dargestellt, wird angenommen, dass die Knoten 4, 11 und 14 die ersten drei Kopien eines Datenelements verwalten. Falls die Knoten 4 und 11 ausfallen, bedient Knoten 14 die Anforderungen direkt und repliziert die Daten wieder auf mindestens zwei weiteren Knoten (Knoten 2 und 8), um eine gesunde Anzahl von Kopien der Daten beizubehalten. 

Speichersicherheit

Der Windows Azure-Speicher stützt sich bei der Authentifizierung der REST-Webanforderung auf einen Hash-basierten Nachrichtenauthentifizierungscode (HMAC, Hash-based Message Authentication Code). Der gemeinsame geheime Schlüssel, der dem Windows Azure-Speicherprojekt zugeordnet ist, wird bei der Berechnung eines 256-Byte-Hashcode mit der HTTPAnforderung kombiniert, der als "Autorisierungsheader" in die Webanforderung eingebettet wird. Der gleiche Prozess wird auf dem Server wiederholt, um die Authentizität der Anforderung zu überprüfen. Für Windows Azure-Tabelle, -Warteschlange und -Blobs gilt derselbe Authentifizierungsprozess, obwohl die Nutzlast und die Ziel-URLs für jeden dieser Speichertypen anders ist. Es folgen die URLs für den Zugriff auf die drei oben genannten Speicherfunktionen in einem Projekt mit dem Beispielnamen "hkshoppinglist":

• http(s)://hkshoppinglist.blob.core.windows.net/
• http(s)://hkshoppinglist.queue.core.windows.net/
• http(s)://hkshoppinglist.table.core.windows.net/

Im Codebeispiel in Abbildung 14 wird gezeigt, wie mehrere Windows Azure-Tabellen im Rahmen der Speichervorbereitung für die Anwendungsbereitstellung erstellt werden.

Abbildung 14 Pseudocode, der die authentifizierte Erstellung von Windows Azure-Tabellen und -Daten zeigt

[DataServiceKey("TableName")]
Public class StorageTable
{
  Private string _tableName;
  Public string TableName
{
  get { return this._tableName; }
  set { this._tableName = value; }
}
}

Public class Customer: TableServiceEntity
{
  Public string Name { get; set; }
  Public string CustomerID { get; set; }
  public Customer()
{
  PartitionKey = "enterprise";
  RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks –
  DateTime.Now.Ticks, Guid.NewGuid());
}
}
CloudStorageAccount _storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

Public void CreateMultipleCustomers(List<Customer> customers)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials);
  foreach (Customer cust in customers)
{
  tsc.AddObject("customers", cust);
}
try
{
  DataServiceResponse resp =  tsc.SaveChanges(SaveChangesOptions.Batch);
  foreach (ChangeOperationResponse cor in resp)
{
  if (cor.Error != null)
{
//cor.Headers["Location"] can be parsed to find out the failed 
//requests which can be retried after correcting the error condition
}
}
}
catch (Exception ex){ //do something with the exception }
}

protectedvoid linkCreateTables_Click(object sender, EventArgs e)
{
  labelStatus.Text = string.Empty;
try
{
  CreateTable("customers");
  CreateTable("products");
}
catch (DataServiceRequestException ex)
{
  labelStatus.ForeColor = System.Drawing.Color.Red;
  labelStatus.Text = "Error: Table creation error : " + ex.Message;
}
}
//Use ADO.NET services directly to create an Windows Azure Table
Public void CreateTableUsingContext(AzureStorageTable storageTable)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials); tsc.AddObject("Tables", storageTable);
try
{
  DataServiceResponse resp = tsc.SaveChanges(SaveChangesOptions.None);
//handle errors
}
catch (Exception ex){//do something here}
}
//much simpler way of creating an Windows Azure Table
  publicvoid CreateTable(string tableName)
{
CloudTableClient ctc = _storageAccount.CreateCloudTableClient();
try
{
  ctc.CreateTable(tableName);
}
catch(Exception e) { //handle exception }
}

Ich zeige anhand des Windows Azure-Tabellenbeispiels einige einfache Methoden, Windows Azure-Speicher auf das transaktionsgestützte Auffüllen mit Daten vorzubereiten. In den Codebeispielen wird gezeigt, wie die Tabellen "customers" und "products" mithilfe von TableServiceContext und CloudTableClient erstellt werden, um die Flexibilität der REST-basierten Interaktion zu veranschaulichen. In der Tat könnte man auch eine reine Nutzlatz entwerfen, HMAC an die Webanforderung anfügen und mit einem HTTP-POST-Befehl an die Tabellen-URL übertragen, aber hierzu ist eine Menge Code erforderlich, und daher sollte nur zur akademischen Übung so vorgegangen werden. Der empfohlene Ansatz besteht darin, die StorageClient-API zu verwenden, die im Windows Azure SDK enthalten ist.

Die CreateTableUsingContext-Funktion verwendet die AzureStorageTable-Klasse, um die Tabellenerstellungsnutzlatz mithilfe der ADO.NET-Datendienste zu generieren. TableServiceContext generiert automatisch HMAC und fügt diesen Code unter Verwendung des Schlüssels, der in der Eigenschaft CloudStorageAccount.Credentials enthalten ist, an die Anforderung an.

Windows Azure-Tabellenspeicher lässt Batchtransaktionen zu, wie in der Funktion CreateMultipleCustomers in Abbildung 14 gezeigt wird. Ein Batch sollte in einem gegebenen Änderungssatz nicht mehr als 100 Vorgänge umfassen, und ein Batch sollte nicht größer als 4 MB sein. Nähere Einzelheiten hierzu finden Sie in der Dokumentation zum Windows Azure-Speicher. Batchtransaktionen sind nur zulässig, wenn die Entitäten zur gleichen Partition gehören.

Die für die HMAC-Generierung notwendigen Anmeldeinformationen werden in der Dienstkonfiguration der betreffenden Windows Azure-Rolle angegeben. Nachfolgend wird das Format der Verbindungszeichenfolge für lokalen Speicher und Cloud-Speicher angegeben:

Lokaler Speicher:

<Setting name="DataConnectionString"
value="UseDevelopmentStorage=true"/>

Cloud-Speicher:

<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=
http;AccountName=
<your account>;AccountKey=<your account key"/>

Der Windows Azure-Speicher kennt keine rollenbasierte Sicherheit. Daher muss eine authentifizierte Anforderung im Kontext des Speicherprojekts uneingeschränkten Zugriff auf den Speicher haben. Eine Ausnahme hierzu bildet der Blobcontainer, der sowohl öffentlich (anonym) als auch privat sein kann. Die Autorisierung liegt in der Verantwortung der Anwendung, welche die Speicherdienste nutzt.

Zusammenfassung

In diesem Artikel wurde die Windows Azure-Plattform nur oberflächlich behandelt. Ich bin mir sicher, Microsoft SQL Azure, AppFabric, verschiedene Serverrollen und andere Sicherheitsszenarien, auf die hier eingegangen wurde, werden in Zukunft noch ausgiebig behandelt. Die Windows Azure-Plattform ist eine Cloud-Computing-Plattform, die darauf ausgelegt ist, bedarfsgesteuertes Utility Computing für die Entwicklung und das Hosten von Anwendungen und Diensten zu ermöglichen.

Große Pools herkömmlicher Hardware werden durch Software und einen hohen Automatisierungsgrad äußerst zuverlässig. Der ökonomische Vorteil großer Mengen werden durch niedrige Abonnementgebühren an den Verbraucher weitergegeben. Den Abonnenten werden in einem monatlichen Abrechnungszyklus nur die tatsächlich genutzte Bandbreite, Speicherkapazität und Rechenzyklen berechnet. Die Windows Azure-Plattform ist mit den Plattformkomponenten ausgestattet, die zur Erstellung von Anwendungen und Diensten für Unternehmen erforderlich sind, ohne finanzielle Vorleistungen oder langfristige Vertragsbindungen zu erfordern.

Hanu Kommalapati ist Plattformstrategieberater bei Microsoft, und in dieser Funktion berät er Unternehmenskunden bei der Erstellung skalierbarer Branchenanwendungen auf den Plattformen Silverlight und Windows Azure.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Vittorio Bertocci, Brad Calder, Ryan Dunn und Tim O’Brien