Häufig werde ich auf die Frage angesprochen, welche Funktionen denn als nächstes in die Windows Azure Platform eingebaut werden. Oft ist dies auch mit der Bitte verbunden, ich möge den einen oder anderen Vorschlag doch an die Produktgruppe melden, da ich (so die Annahme) ja einen “guten Draht” nach Redmond hätte.

Nun will ich an dieser Stelle ein Geheimnis verraten: Die Produktgruppe hat durchaus ein Interesse daran, direkt von der Welt “außerhalb der Microsoft Corp.” Wünsche und Anregungen zur Weiterentwicklung von Azure zu erfahren. Beispiel…:

Die Website “My Great Windows Azure Idea”
(http://www.mygreatwindowsazureidea.com/")

Dort hat jeder die Möglichkeit, Ideen, Wünsche und Anregungen für die Windows Azure Platform einzubringen, und über bestehende Vorschläge abzustimmen. Derzeit sind dort als Top 10 der Wünsche folgende Punkte:

Diese Punkte überraschen in der Tat wenig. Sie decken sich grob mit den häufigsten Fragen und Wünschen, die mir gegenüber geäußert werden.

Der erste Punkt ist nachvollziehbar. Für kleinere Webseiten erscheint Windows Azure oft zu hochpreisig (insbesondere, wenn die Vorteile von Azure wie automatisches Management, Hochverfügbarkeit, hohe Skalierbarkeit nicht unbedingt benötigt werden).

Also: fleißig mit-“voten” und die Meinung äußern. Die Vorschläge werden alle ernst genommen!!! Das Portal gibt auch Aufschluss darüber, welche der Vorschlage angenommen bzw. bereits umgesetzt sind.

Analoges gibt es übrigens für SQL Azure und Microsoft Codename “Dallas”. Bei SQL Azure sieht die “Top 10”-Liste derzeit wie folgt aus:

Im Grunde zielen hier die meisten Punkte (alle bis auf Punkt 2 und 3) auf eine größere Kompatibilität von SQL Azure zu SQL Server ab.

Weitere Informationen

• http://www.mygreatwindowsazureidea.com/

Neben Erweiterungen an den Kerndiensten der Windows Azure Platform (Windows Azure, AppFabric und SQL Azure) hat Microsoft noch eine Reihe von ergänzenden Diensten veröffentlicht, die Anwender der Plattform dabei unterstützen, auf Windows Azure basierende Cloud Services zu vermarkten und zu integrieren.

Microsoft Pinpoint

Microsoft stellt mit Microsoft Pinpoint Kunden und Partnern einen Marktplatz für Cloud-Anwendungen, die sie auf Windows Azure betreiben, zur Verfügung. Partner haben die Möglichkeit, Ihre Services (sowohl Anwendungsdienste als auch Dienstleistungen) über das Developer Portal in diesen Marktplatz einzustellen und mit Metainformationen (Dienstbeschreibung, Kosten etc.) zu versehen. Kunden können diese Anwendungen und Dienste in Pinpoint suchen, auswählen, und direkt aus den Microsoft-Rechenzentren beziehen. Abbildung 10.5 zeigt die Hauptseite von Microsoft Pinpoint.

Abbildung 10.5: Microsoft Pinpoint – Marktplatz für Cloud Services

Über das Pinpoint Portal besteht die Möglichkeit, Einträge nach Bewertung, regionaler Verfügbarkeit und weiteren Kriterien zu filtern.

Microsoft Codename »Dallas«

Über Microsoft Codename »Dallas« können Entwickler und Anwender Datendienste über die Windows Azure Platform bereitstellen, auffinden, konsumieren und abrechnen. Dallas agiert dabei als technische und vermittelnde Datendrehscheibe, indem es eine Plattform zur technischen Bereitstellung der Datendienste, Abrechnungsfunktionalitäten und standardisierte Schnittstellen für den Zugriff zur Verfügung stellt.

Dallas umfasst folgende Funktionsbereiche:

• Rich Web Services
  Den Datendiensten liegt jeweils ein REST-basiertes Zugriffsmodell zugrunde. Darüber hinaus sind für die meisten Dienste auch ATOM 1.0 Feeds verfügbar. Die Dienstnutzung wird über einheitliche Verfahren erfasst und abgerechnet.
• Service Explorer
  Mit diesem können C#-Proxy-Klassen generiert werden, die bei den Service-Aufrufen und der Darstellung der Daten unterstützen. Die generierten Klassen enthalten eine Kurzdokumentation des betreffenden Dienstes und Beispielwerte für die Aufrufe.
• Marktplatzintegration und Portal zur Verwaltung
  Über den Marktplatz können Daten gefunden, Zugriffe eingerichtet, verwaltet und abgerechnet werden. Das Portal ermöglicht die Erstellung von Zugriffsstatistiken.

Über Dallas können quasi beliebige Arten von Inhalten bereitgestellt werden: Blobs, strukturierte Daten, Webservices etc.

Microsoft hat bereits einige Ergänzungen und Weiterentwicklungen angekündigt:

• Einheitliche EULA für die Dienstnutzung
• Vorschaufunktionen für Videos, Bilder, 3D-Modelle
• Integrationspunkte für Microsoft Office, SQL Server, SQL Azure-Datenbank und andere Systeme

Zusammenfassung

Mit Version 1.0 der Windows Azure Platform steht der finale Umfang der Plattform fest. Sie enthält Windows Azure, die Windows Azure Platform AppFabric (ehemals .NET Services) und SQL Azure. Mit der Markteinführung sind für die einzelnen Dienste Leistungsdaten, Service Level und Preismodelle verfügbar.

In Zusammenhang mit der Produktivsetzung hat Microsoft auch Änderungen an den einzelnen Diensten vorgenommen. Zum Teil sind neue Funktionen hinzugekommen (z.B. Logging und Diagnose bei Windows Azure), zum Teil sind aber auch Funktionen entfallen, deren Wiedereinsetzung für zukünftige Versionen der Plattform angekündigt sind (z.B. Queues und Router beim Service Bus, WS-* Unterstützung beim Access Control Service).

Hinzu gekommen sind mit Microsoft Pinpoint und Microsoft Codename »Dallas« zwei Dienste, die Entwickler und Anwender bei der Vermarktung, Nutzung und Integration von Daten und Services unterstützen.

Weitere Informationen

• Buch “Cloud Computing mit der Windows Azure Platform”
• Artikelserie: http://www.microsoft.com/germany/msdn/knowhow/press/default.mspx

SQL Azure ist in seinem Funktionsumfang nahezu stabil geblieben. Die in Kapitel 6 beschriebenen Aspekte und Beispiele sind weiterhin gültig. Neu eingeführte Funktionalitäten sind unter anderem:

• Firewall-Unterstützung
• Bulk-Inserts
• Erweiterte TSQL Unterstützung

Aus Visual Studio heraus konnte bislang nur unzureichend auf SQL Azure zugegriffen werden (geschweige denn, dass Daten angezeigt oder geändert werden konnten). Für die finale Version von Visual Studio 2010 (also erst die RTM-Version und nicht die Beta 2) hat Microsoft bereits erweiterte Unterstützung von SQL Azure angekündigt. Tabelle 10.7 gibt einen Überblick über die in Visual Studio verfügbaren Funktionen.

Tabelle 10.7: Geplante Visual Studio-Unterstützung für SQL Azure

Als weiteres Entwicklungswerkzeug steht weiterhin der SQL Azure Migration Wizard, der über den URL http://sqlazuremw.codeplex.com/ heruntergeladen werden kann, zur Verfügung. Abbildung 10.4 zeigt dessen Hauptbildschirm, von dem aus die verschiedenen Funktionsbereiche aufgerufen werden können.

Abbildung 10.4: Hauptbildschirm des SQL Azure Migration Wizards

Der SQL Azure Migration Wizard bietet folgende Möglichkeiten:

• Analyse von SQL, TSQL und SQL Profiler-Skripten
• Migration einer Datenbank von SQL Server nach SQL Azure
• Migration einer Datenbank von SQL Azure nach SQL Server
• Migration einer Datenbank von SQL Azure nach SQL Azure

Die Analysefunktion prüft, ob ein bestehendes Datenbankskript kompatibel mit dem Funktionsumfang von SQL Azure ist.

Zum in Kapitel 6 beschriebenen SQL Azure Data Sync Service wurden weitere Informationen bekannt gegeben. Der Service umfasst Bibliotheken und eine Laufzeitumgebung, die die Datensynchronisation mit SQL Azure unterstützt. Der Dienst basiert auf dem Sync Framework und unterstützt zwei grundsätzliche Szenarien:

• Erweiterung einer bestehenden Vor-Ort-Infrastruktur in die Cloud
  Daten können über die Synchronisation mit SQL Azure vielen Anwendern bereitgestellt werden, ohne dass diese notwendigerweise direkten Zugriff auf die Vor-Ort-Infrastruktur (die möglicherweise hinter einer Firewall liegt) haben müssen.
• Implementierung von Offline-fähigen Anwendungen
  Anwendungen, die ihre lokalen Datenbanken mit SQL Azure synchronisieren, können beim Ausfall der Netzwerkverbindung mit ihrer lokalen Datenkopie arbeiten. Änderungen werden, sobald die Verbindung wieder steht, automatisch in die zentrale SQL Azure-Datenbank übertragen.

Ausblick

Bezüglich SQL Azure wurden für zukünftige Versionen bereits einige vielversprechende Funktionen angekündigt:

• Database Cloning zur Erstellung von Datenbankkopien
• Laufende Backups, mit deren Hilfe historische Daten wiederhergestellt werden können
• Upgrade und Downgrade zwischen Größenoptionen (Web Edition vs. Business Edition)
• Schreibgeschützte Datenbanken
• Dynamische Datenbanksplits und -zusammenführungen
• Weitere Größenoptionen neben den bereits bekannt gegebenen (1 GB vs. 10 GB)

Eine im Kontext von Unternehmensanwendungen äußerst interessante Erweiterung von SQL Azure wird derzeit unter der Bezeichnung SQL Azure Codename »Vidalia« geführt. Dabei handelt es sich um eine Technologie, mit der Unternehmen sehr feingranular Zugriffsrechte auf SQL Azure-Datenbanken erteilen können. Dies ist insbesondere für sensible Geschäftsdaten erforderlich, auf die beispielsweise nur vereinzelte Anwender und Auditoren, nicht aber der Systemadministrator Zugriff haben sollen. Mit Vidalia wird es möglich, genau festzulegen, wer auf welche Daten in welcher Detailliertheit zugreifen darf. Technisch liegen Vidalia folgende Konzepte zugrunde:

• Datenbezogene Sicherheit (mit Datenverschlüsselung basierend auf Policys)
• Federated Access (bei dem die Zugriffskontrolle vom Speicher getrennt ist)
• Audit as a Service (zur gesicherten Bereitstellung von Audit-Informationen)

Vidalia liegt als Zugriffsschicht über SQL Azure. Zugriffe auf die Datenbank werden über Vidalia abgewickelt.

Weitere Informationen

• Buch “Cloud Computing mit der Windows Azure Platform”

Auf ARCast.TV ist ein äußerst interessantes Video zum Thema “Entwurf multimandantenfähiger Anwendungen für Windows Azure” mit Joseph Hofstader verfügbar.

Joseph geht in dieser Folge auf den im Bereich Cloud Computing bedeutsamen Aspekt der Multimandantenfähigkeit von SaaS-Angeboten ein. Dies ist inbesondere deshalb ein wichtiges Thema, als dass die Möglichkeit, mehrere Mandanten gemeinsam auf einer IT-Infrastruktur zu bedienen, zusätzliche Optionen für die optimale Auslastung dieser Infrastruktur schafft.

Die .NET Services haben mit der Produktivsetzung eine sofort ins Auge fallende Änderung erfahren. Sie wurden umbenannt. Die neue Bezeichnung für diese Dienstgruppe ist Windows Azure Platform AppFabric. Die AppFabric umfasst die beiden Dienste

• Windows Azure Platform AppFabric Service Bus
• Windows Azure Platform AppFabric Access Control Service

Im Folgenden werden diese beiden Dienste kurz als Service Bus und Access Control Service bezeichnet. Der Workflow Service wird in zukünftigen Versionen der AppFabric enthalten sein.

An der Positionierung der AppFabric hat sich nichts geändert: Sie umfasst Cloud Services, mit deren Hilfe Entwickler Anwendungen und Dienste, die auf Windows Azure, Windows Server und einer Reihe von anderen Plattformen betrieben werden, verknüpfen. Die Kommunikation kann dabei über den Service Bus abgewickelt und – sofern es sich um REST-basierte Services handelt – Claims-basiert über den Access Control Service abgesichert werden.

Service Bus

Der Service Bus behält seine zentrale Rolle in der Vernetzung verteilter Anwendungskomponenten. Folgende primäre Anwendungsmuster werden unterstützt:

• Eventing, d.h. der Austausch von Benachrichtigungen zwischen Anwendungen über verschiedene Kommunikationsprotokolle
• Service Remoting, d.h. das Angebot von lokal beim Anwender (hinter einer Firewall) betriebenen Services in der Cloud
• Tunneling, d.h. die Kommunikation zwischen Anwendungen über Firewall-Grenzen hinweg

Gegenüber dem Juli-CTP wurde der Funktionsumfang des Service Bus leider in einem entscheidenden Bereich reduziert: Router und Queues wurden aus dem Service Bus entfernt (diese sollen in einem zukünftigen Release mit erweiterten Möglichkeiten wieder verfügbar werden). Entsprechende Abschnitte in diesem Buch sind also zunächst hinfällig.

Im SDK der Produktivversion ist das Beispiel LoadBalance enthalten, das zeigt, wie mit den bestehenden Mitteln des Service Bus eine ähnliche Funktionalität wie die durch Router zuvor bereitgestellte erzielt werden kann.

Die Queues wurden vorübergehend durch Message Buffers ersetzt. Diese bieten einen großen Teil der zuvor von Queues bereitgestellten Funktionalitäten an. Message Buffers sind in den folgenden Bereichen gegenüber Queues eingeschränkt:

• Ein Message Buffer kann maximal 1 MB Daten enthalten
• Eine Dequeue-Operation liefert immer nur eine Nachricht zurück
• Die Overflow-Policy ist auf reject beschränkt
• Message Buffer sind ausschließlich über REST ansprechbar

Darüber hinaus sind die Konfigurationsmöglichkeiten gegenüber Queues eingeschränkt. Das grundsätzliche Verhalten (»best effort FIFO«) ist allerdings vergleichbar.

Access Control Service

Der Access Control Service (ACS) wurde funktional ebenfalls beschränkt und fokussiert nun auf die Claims-basierte Zugriffskontrolle für REST-basierte Webservices. Vorübergehend wurden also Funktionen für Single-Sign-On oder WS-* Unterstützung aus dem Dienst entfernt und für spätere Releases des ACS angekündigt.

Die Funktionalitäten des ACS umfassen unter anderem folgende Bereiche:

• Claims-basierte Zugriffskontrolle für REST-basierte Webservices
• Integrationsmöglichkeit mit ADFS v2
• Unterstützung von WRAP (= Web Resource Authorization Protocol) und SWT (= Simple Web Token)

Der Prozess zum zugriffsgesicherten Aufruf einer durch ACS geschützten Ressource durch einen Client erfolgt wie in Abbildung 10.3 dargestellt.

Abbildung 10.3: Claims-basierte Zugriffskontrolle in OAuth Terminologie

Der ACS stellt dem Client also Security Tokens als sogenannte Simple Web Tokens zur Verfügung, das der Client beim Zugriff auf die geschützte Ressource übergeben kann und das diese dann für die Entscheidung über den Zugriff auswerten kann.

Der Client kann drei Arten von Tokens anfordern:

• Plaintext (einfachste Variante, ohne Verschlüsselung)
• Signierte Token (HMAC SHA 256 erforderlich)
• Von AD FS v2 ausgegebene Token, die SAML enthalten (erlaubt Unternehmensintegration)

ACS liefert Tokens immer im SWT-Format zurück. Diese Token haben einen Aufbau ähnlich dem in Listing 10.5 gezeigten Token.

role=Admin%2cUser&
customerName=Contoso%20Corporation&
Issuer=https%3a%2f%2fadatum.accesscontrol.windows.net%2fWRAPv0.8&
Audience=http%3a%2f%2fadatum%2fbillprint&
ExpiresOn=1255912922&
HMACSHA256=yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d

Listing 10.5: Beispiel für das SWT-Format

Ausblick

Microsoft plant, Funktionen, die in der Produktivversion der AppFabric gegenüber früheren CTP-Versionen entfernt wurden, in zukünftigen Releases der Plattform wieder einzuführen. Hierzu gehört beim Service Bus insbesondere die Verfügbarkeit von Routern und Queues.

Für den Access Control Service sind unter anderem folgende Erweiterungen angekündigt:

• Web Single-Sign-On
• WS-* Unterstützung (WS-Trust und WS-Federation)
• Unterstützung verschiedener Web Identity Provider (Live ID, Facebook Connect, Google, Open ID, etc.)
• Erweiterte Unterstützung von Enterprise Identity Providern
• Integration von CardSpace

Weitere Informationen

• Buch “Cloud Computing mit der Windows Azure Platform”

Was die Live Services betrifft, so war die Änderung im Bezug auf die Windows Azure Platform am einschneidensten: Die Live Services wurden aus der Plattform komplett herausgelöst und werden in Zukunft unabhängig von Azure weiterentwickelt. Neuerungen an den Live Services sind für die Webkonferenz MIX 2010 zu erwarten.

Weitere Informationen

• Buch “Cloud Computing mit der Windows Azure Platform”

Nachdem es bereits in der CTP-Phase zahlreiche Veränderungen im Aufbau und Funktionsumfang von Windows Azure gegeben hat, steht mit der Produktivsetzung eine Windows Azure Platform in einer ersten Version bereit. Der schematische Aufbau ist in Abbildung 10.2 wiedergegeben.

Abbildung 10.2: Aufbau von Windows Azure

Windows Azure umfasst damit folgende Bestandteile:

• Business Portal
  Über dieses Portal erfolgt die Abrechnung der genutzten Dienste. Dabei teilt sich Windows Azure das Portal mit Microsofts SaaS-Angeboten (SharePoint Online, Exchange Online etc.). Somit haben Nutzer stets einen Überblick über die laufenden Kosten für die Nutzung aller Microsoft Cloud Services.
• Developer Portal
  Entwickler und Administratoren nutzen dieses Portal, um Anwendungen auf Windows Azure zu installieren und zu verwalten. Hier können neue Projekte angelegt und Konfigruationseinstellungen vorgenommen werden.
• Service Management Service
  Der Verwaltungsdienst führt die Management-Aufgaben, die ihm entweder über das Entwicklerportal oder die neue Management API (von der aus Aufgaben über Webservice-Aufrufe eingehen) übergeben werden, aus.
• Storage Cluster
  In den Storage Clustern werden die Dienste für den Windows Azure Storage betrieben. Diese sind von den Rechendiensten getrennt. Ein Zugriff ist direkt von Windows Azure-Anwendungen und von außen über REST Webservices möglich.
• Compute Cluster
  Die VMs zur Ausführung von Anwendungen werden in Compute Clustern betrieben. Diese sind von den Speicherdiensten getrennt.
• Entwicklungsumgebung
  Für Entwickler stehen zum einen die Tools für Visual Studio (die für Visual Studio 2010 nochmals erweitert werden), zum anderen ein überarbeitetes Software Development Kit (SDK) zur Verfügung.

Mit der Produkteinführung wurden in den einzelnen Bestandteilen von Windows Azure Kenngrößen und funktionale Erweiterungen eingeführt bzw. angekündigt. Die folgenden Abschnitte geben einen Überblick über diese Änderungen.

Windows Azure Compute

Jede Instanz einer Rolle, die in Windows Azure zum Betrieb von Diensten angelegt wird, wird auf einer eigenen virtuellen Maschine (VM) ausgeführt. Während der CTP-Phase standen VMs in einer einzigen Größe zur Verfügung. Die VMs waren jeweils mit einem Prozessorkern mit 1,6 GHz und 1,75 Gigabyte Hauptspeicher ausgestattet.

Verschiedene Größen virtueller Maschinen

Mit dem Produktionsstart von Azure stehen nun vier verschiedene Größen von VMs zur Verfügung, aus denen der Nutzer auswählen kann: Small, Medium, Large und XLarge. Diese sind in Tabelle 10.5 aufgelistet.

Tabelle 10.5: Verschiedene Größen virtueller Maschinen

Die Variante Small ist die bisher im Rahmen der CTP verfügbare VM. Mit den weiteren VMs gehen bezüglich Zahl der Prozessorkerne und Speicherausstattung jeweils Verdoppelungen einher (Medium ist doppel so groß wie Small usw.).

Nachrichtenaustausch mit Rollen

Die Kommunikation zwischen zwei Rollen erfolgte bislang immer über eine Vermittlerkomponente. Dies konnte eine Windows Azure Storage Queue, Blob-Storage etc. sein, über die Nachrichten zwischen Rollen ausgetauscht und hierüber eine Kommunikationsbeziehung unterhalten werden konnte. Neu ist, dass Web und Worker Roles nun direkt miteinander kommunizieren können. Die API stellt hierzu Funktionen bereit, mit denen einzelne Instanzen einer Rolle identifiziert und Nachrichten über direktem Weg ausgetauscht werden können. Die Identifikation einer Rolle ist insbesondere dann wichtig, wenn mehr als eine Instanz einer Rolle betrieben wird, die Kommunikation aber immer mit der jeweils gleichen Instanz erfolgen soll, da beispielsweise zur Verarbeitung aufeinander folgender Nachrichten beim Empfänger notwendige Kontextinformation im Speicher gehalten werden soll.

Änderungen hat es nicht nur in der Kommunikation zwischen Rollen, sondern auch im Bereich der Kommunikation mit der Außenwelt gegeben. Rollen haben nun gewissen Einfluss darauf, wie sie von außen über den Loadbalancer angesprochen werden können. Während Web Roles Nachrichten grundsätzlich über einen vorgeschalteten Internet Information Server (IIS) empfangen, kann für Worker Roles konfiguriert werden, über welchen Port sie Nachrichten direkt vom Loadbalancer empfangen können. Die Rolle kann dabei über einen ähnlich dem in Listing 10.1 angegebenen Code den eigenen Endpunkt ermitteln.

IPEndPoint endpoint =
RoleEnvironment.Roles["HelloWorld_WorkerRole"].Instances[0].InstanceEndpoints["TestEndpoint"].IPEndpoint;

Listing 10.1: Ermittlung des IP-Endpunkts (Ports) über die Windows Azure Runtime API

Dieser Endpunkt kann dann verwendet werden, um Nachrichten zu empfangen, die von außen an den betreffenden Port gesendet wurden. Hierzu stehen wiederum Befehle der Windows Azure Runtime API zur Verfügung. Ein entsprechendes Codefragment ist in Listing 10.2 zu sehen.

var client = new TcpClient();
client.Connect(endpoint);
var rd = new StreamReader(client.GetStream());
var test = rd.ReadToEnd();
client.Close();

Listing 10.2: Empfang von Daten über den zuvor ermittelten IP-Endpunkt

Neben den bereits während der CTP-Phase verfügbaren Web und Worker Roles wurde für die Produktivphase der Windows Azure Plattform eine dritte Art von Rollen bekannt gegeben: die Virtual Machine Role. Während bei Web und Worker Roles Software auf eine von Azure vorkonfigurierte VM aufgespielt wird, besteht bei VM Roles die Möglichkeit, auch die VM selbst zu konfigurieren und dann auf Windows Azure auszuführen. Dabei steht eine Auswahl an vorgefertigten VMs zur Verfügung. Diese können angepasst und dann als Snapshot auf Windows Azure geladen und durch dieses betrieben werden. Für die Konfiguration erhält der Entwickler deutlich mehr Flexibilität als bei Web und Worker Roles. Erkauft wird diese Flexibilität allerdings mit Einschränkungen bei der automatisierten Skalierung von Anwendungen (wenn beispielsweise zusätzliche Instanzen einer Rolle hinzugeschaltet werden sollen).

Logging- und Diagnose-System

Nachdem ein direktes Debuggen von Anwendungen, die auf Winodws Azure betrieben werden, nicht möglich ist, kommt dem Logging- und Diagnose-System, welches mit Produktivsetzung der Plattform verfügbar ist, besondere Bedeutung zu. Dieses System zielt unter anderem auf folgende Einsatzszenarien ab:

• Messung der Performanz der Anwendung
• Ermittlung des Ressourcenverbrauchs
• Fehlersuche und -behebung
• Überwachung
• Prüfung der Metriken für die Dienstqualität der Anwendung
• Kapazitätsplanung (um die Zahl der Anwendungsinstanzen zu optimieren)
• Auslastungsanalyse (Anwender, Zugriffsstatistiken)
• Abrechnung und Auditierung der Anwendung

Um Tracing-Ausgaben erzeugen zu können, muss in der web.config-Datei einer Anwendung (diese wird von Visual Studio für Web Roles automatisch erzeugt) ein sogenannter Trace Provider registriert werden. Dies kann wie in Listing 10.3 gezeigt erfolgen.

<system.diagnostics>
<trace autoflush="false" indentsize="4">
<listeners>
<add name="AzureDiagnostics"
type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</listeners>
</trace>
</system.diagnostics>

Listing 10.3: Registrierung eines Trace Providers als Voraussetzung zur Erzeugung von Trace-Ausgaben

Mit Hilfe der bekannten Tracing API können damit dann Tracing-Ausgaben in Logs erfolgen, die gesammelt und dann zeitgesteuert oder auf Anforderung in Windows Azure Storage abgelegt werden. Beispielaufrufe der Tracing API sind in Listing 10.4 zu sehen.

Trace.WriteLine("Hier ist ein KRITISCHER Log-Eintrag", "Critical");
Trace.WriteLine("Hier ist eine INFORMATION für das Log", "Information");

Listing 10.4: Beispielaufrufe der Tracing API

Bei der Übertragung in den Azure Storage, von wo aus die Logs dann auf dem üblichen Weg (Storage API oder Webservices) ausgelesen werden können, können die Logs nach Datentyp, Level und Zeitraum gefiltert werden. Tabelle 10.6 gibt einen Überblick über die möglichen Informationsquellen für die Anwendungsüberwachung und Analyse.

Tabelle 10.6: Informationsquellen für die Anwendungsüberwachung und -analyse

Die Datenquellen erzeugen Informationen, die in den Windows Azure Storage (als Tables oder Blobs) übertragen werden können und dort für Analyseprozesse zur Verfügung stehen.

Windows Azure Storage

Der Speicherdienst von Windows Azure umfasste bisher Queue, Table und Blob Storage. Diese wurden auf Basis zahlreichen Kunden- und Anwenderfeedbacks in ihren Funktionen deutlich erweitert. Viele der neuen Funktionen reduzieren den Umstellungsaufwand bei der Migration bestehender Anwendungen auf Windows Azure.

Drives als virtuelle NTFS-Festplatten

Blob Storage wurde beispielsweise um eine wichtigen Funktionalität erweitert: Drives. Bei Drives handelt es sich um Blob Storage, der als ein virtuelle NTFS-Festplatte (Virtual Hard Drive (VHD)) formatiert wird. Diese steht dann Windows Azure-Anwendungen zur dauerhaften Speicherung von Daten in einem virtuellen Dateisystem zur Verfügung. Drives zeichnen sich durch folgende Eigenschaften aus.

• Ein Drive kann eine Maximalgröße von 1 Terabyte haben
• Eine VM kann dynamisch bis zu acht Drives anbinden
• Ein Drive kann zu einem Zeitpunkt nur an eine einzige VM angebunden werden
• Zugriff von außen erfolgt über die Page Blob API
• Import und Export von Drives ist möglich. Ein VHD kann über die Blob-Schnittstelle hochgeladen bzw. darüber auch wieder heruntergeladen werden.

Mit Drives hat Microsoft nun eine Möglichkeit geschaffen, Anwendungen, die auf den Zugriff auf ein Dateisystem angewiesen sind, auf Windows Azure zu migrieren.

Offizielle Storage Client Library

Für den Zugriff auf den Windows Azure Storage ist eine offizielle Storage Client Library verfügbar. Dies hat zur Folge, dass Entwickler nicht mehr über Klassenbibliotheken aus dem Samples-Namespace, sondern über den Namespace Microsoft.WindowsAzure.StorageClient mit dem Windows Azure Storage interagieren. Anwendungen, die während der CTP-Phase erstellt wurden, müssen in diesem Bereich also geändert werden, um den neuen Namespace zu unterstützen.

Erweiterte Funktionalitäten der Speicherdienste

Die Speicherdienste werden noch um einige weitere Funktionalitäten erweitert. Stichpunktartig die wichtigsten Erweiterungen:

• Operationen auf Table Entitys können unter bestimmten Voraussetzungen zu Entity Group Transactions (bis zu 100 Anweisungen in einer Transaktion) zusammengefasst werden
• Auf Tables sind (neben Partition/Row-Key) Sekundärindizes möglich
• Mittels CopyBlob können Kopien eines Blobs innerhalb eines Storage Accounts angelegt werden
• Über SnapshotBlob können schreibgeschützte Backups und Versionen eines Blobs erzeugt werden. Kostenpflichtig sind dabei nur jeweils individuelle Versionen von Blöcken über alle Versionen eines Blobs.
• Für den Blob Storage kann ein Root Blob Container definiert werden. Dieser hat die Form http://mystorage.blob.core.windows.net/$root/blobdocument.xml. Beim Zugriff kann dann die Angabe eines Containernamens entfallen.
• Für den Windows Azure Storage kann ein eigener Domainname vergeben werden

Content Delivery Network (CDN)

Beim Zugriff auf große Dateien, die im Windows Azure Blob Storage abgelegt sind, kann die Netzwerklatenz zu einem Problem werden, wenn der Anwender in großer räumlicher Distanz zum Rechenzentrum ist, in dem der Blob abgelegt ist. Um diese Latenz zu minimieren, bietet Microsoft das sogenannte Content Delivery Network (CDN) an.

Das CDN umfasst 18 Standorte rund um den Globus und wird stetig ausgebaut. Das Windows Azure CDN legt Kopien von Blobs in einem Zwischenspeicher an den verschiedenen Standorten an, um einem Anwender Blobs vom jeweils nächsten Standort auszuliefern und dadurch die Übertragungszeit zu optimieren. Der Einsatz des CDN kann über das Windows Azure Developer Portal aktiviert werden.

Dabei wird für den Blob Storage eine CDN-URL der Form http:/ /<guid>.vo.msecnd.net/ vergeben. Dieser URL kann dazu verwendet werden, Blobs aus einem öffentlichen Blob-Speicher zu lesen. Der Zugriff über den bestehenden URL über den Storage Account ist dabei weiterhin möglich.

Ein Beispiel: Gegeben sei ein Storage Account namens mystorageaccount. In diesem befindet sich ein öffentlicher Container images. Sobald der CDN-Zugriff auf diesen Container eingerichtet ist, können Anwender den Container über zwei URLs auslesen:

• Windows Azure Blob Service URL: http://mystorageaccount.blob.core.windows.net/images/
• Windows Azure CDN URL: http://<guid>.vo.msecnd.net/images/

Beim Zugriff über den Service-URL erfolgt der Zugriff direkt auf den am ursprünglichen Ort gespeicherten Container. Beim Zugriff über den CDN-URL wird die Anfrage sofort an den Endpunkt weitergeleitet, der dem Anwender am nächsten ist.

Version 1.0 der Windows Azure Managed Library

Die Klassenbibliothek für die Interaktion mit Windows Azure, die im Windows Azure SDK enthalten ist, wurde im Rahmen der Produktivsetzung der Plattform überarbeitet. Sie umfasst nun die folgenden Namespaces:

• Microsoft.WindowsAzure
  Über die Klassen dieses Namespaces können die Credentials für Windows Azure Storage Accounts verwaltet werden
• Microsoft.WindowsAzure.ServiceRuntime
  Klassen in diesem Namespace erlauben die Interaktion mit der Windows Azure-Umgebung aus einer Role heraus
• Microsoft.WindowsAzure.Diagnostics
  Die Klassen aus diesem Namespace werden für die Sammlung von Logging- und Diagnosemeldungen benötigt
• Microsoft.WindowsAzure.Diagnostics.Management
  Klassen dieses Namespaces können dazu verwendet werden Logging- und Diagnoseinformationen auszulesen
• Microsoft.WindowsAzure.StorageClient
  Dieser Namespace umfasst die Klassen für den Zugriff auf den Windows Azure Storage Service. Die betreffenden Klassen waren während der CTP-Phase im Namespace Samples enthalten.
• Microsoft.WindowsAzure.StorageClient.Protocol
  Klassen aus diesem Namespace stellen Wrapper für den Zugriff auf den Windows Azure Storage via REST-Protokoll zur Verfügung.

Für Anwendungen, die während der CTP-Phase erstellt wurden, ist hier also unter Umständen eine Überarbeitung erforderlich. Dies ist insbesondere dann der Fall, wenn Funktionalitäten des StorageClients genutzt wurden, der sich zur CTP-Phase im Samples-Namespace befand.

Programmgestützte Verwaltung über die Service Management API

Es steht nun eine Management API zur Verfügung, über die die meisten Aktionen, die über das Windows Azure Developer Portal zugänglich sind, aus einem Skript oder Programm (unabhängig davon, ob dieses auf Windows Azure oder außerhalb betrieben wird) heraus ausgeführt werden können. Über die Service Management API können Storage Accounts, Services, Service Deployments und Affinity Groups verwaltet werden. Die API selbst ist dabei eine REST API, deren Operationen über SSL erfolgen und über X.509 v3-Zertifikate abgesichert werden.

Um mit der Service Management API arbeiten zu können, ist zunächst das Anlegen eines Benutzerkontos über das Windows Azure Developer Portal erforderlich. Diesem ist eine eindeutige Subscription ID zugeordnet, die für API-Aufrufe benötigt wird und die auf dem Portal beim Konto angezeigt wird.

Innerhalb eines Benutzerkontos können zwei Arten von Diensten angelegt werden:

• Storage Account
  Ein Storage Account bietet Zugriff auf die Windows Azure Storage Services zur Nutzung von Blob, Queue und Table Services.
• Hosted Service
  Ein gehosteter Service umfasst Web, Worker und VM Roles innerhalb der Windows Azure-Umgebung in der Cloud.

Diese Dienste müssen über das Windows Azure Developer Portal angelegt werden. Sobald die Anlage abgeschlossen ist, können sie mittels der Service Management API verwaltet werden.

Im Falle eines Storage Accounts umfasst die API beispielsweise Operationen zum Auflisten von Storage Accounts innerhalb eines Benutzerkontos, zum Ermitteln von Eigenschaften des Storage Accounts, Auslesen oder Neugenerieren des primären oder sekundären Zugriffsschlüssels. Eine vollständige Liste der API-Operationen findet sich in der MSDN-Dokumentation.

Die API kann im Falle von Hosted Services zum Beispiel dazu verwendet werden, die Eigenschaften des Service auszulesen, Deployments zu aktualisieren und zu verwalten und Konfigurationen der Dienste zu ändern.

Erweiterte Interoperabilität

Zu den wichtigsten Ankündigungen, die zu Azure auf der PDC 2009 gemacht wurden, gehörten die erweiterten Möglichkeiten zur Interoperabilität. Nachdem schon bei den Schnittstellen nach außen großer Wert auf Standards gelegt wurde – so bleibt es grundsätzlich möglich, auf Services, die auf Azure betrieben werden, über REST- und andere Schnittstellen zuzugreifen – können nun auch Dienste, die in PHP oder Java entwickelt wurden, auf Windows Azure betrieben werden. Allgemein formuliert können auf Windows Azure grundsätzlich alle Technologien betrieben werden, die auf Windows ohne Administratorrechte ausgeführt werden können. Entwickler haben hierbei die Möglichkeit, ihre jeweils benötigte Laufzeitumgebung selbst zu bestimmen.

Mit der Möglichkeit Ports auf Windows Azure für den Nachrichtenempfang von außen zu konfigurieren, können auf Azure auch Anwendungsserver wie Apache Webserver oder Tomcat betrieben werden. Darüber hinaus wird MySQL als Datenbanksystem auf Azure unterstützt. Damit sind die Voraussetzungen geschaffen, auf Basis von Azure einen WAMP-Stack (Windows-Apache-MySQL-PHP) in der Cloud bereitzustellen. Auf der PDC wurde dies von Matt Mullenweg, Gründer von Automattic, eindrucksvoll belegt, indem er sein beliebtes, auf PHP, Apache und MySQL basierendes Content Management System WordPress auf Azure installiert vorführte.

Neben Visual Studio wird es auch für Eclipse Entwicklerwerkzeuge zur Programmierung von Windows Azure-basierten Anwendungen bzw. zum Zugriff auf SQL Azure oder die AppFabric geben.

Ausblick

Bereits bekannt sind eine Reihe von Weiterentwicklungen, die die Funktionalitäten von Windows Azure deutlich erweitern werden:

• Gewährung von Administratorrechten auf den VMs
• Deployment vorkonfigurierter VM-Images (VM Roles)
• Remote Terminal Server-Zugriff auf die VMs

Eine weitere wichtige, angekündigte Funktion ist die laufende Datenreplikation zwischen Rechenzentren einer Affinity Group. Rechenzentren einer Region werden von Microsoft zu Affinity Groups zusammengefasst. Beim anlegen eines Storage Accounts oder eines gehosteten Services kann der Anwender eine Affinity Group (also kein einzelnes Rechenzentrum) wählen. Microsoft garantiert, dass die gebuchten Ressourcen in einem Rechenzentrum aus dieser Affinity Group betrieben werden.

Der Betrieb von Software in der Cloud zeichnet sich unter anderem durch hohe Skalierbarkeit, hohe Verfügbarkeit und einem automatisierten Management der Softwarekomponenten aus. Zu Letzterem gehört die Möglichkeit Microsofts, in Abstimmung mit den Nutzern der Plattform laufend Plattformaktualisierungen und –Patches einspielen zu können, ohne dass dies den laufenden Betrieb der Cloud Services beeinträchtigt. Die Windows Azure Platform ist deshalb permanent Änderungen unterworfen, was es zwangsläufig erschwert, ein Buch zur Plattform stets auf dem aktuellen Stand zu halten.

Seit der Fertigstellung des Buchmanuskriptes hat es eine Reihe von Änderungen und Erweiterungen an der Plattform gegeben, die in diesem Kapitel überblicksartig beschrieben werden. Zusammen mit der gedruckten Version des Buches bildet es ein Gesamtwerk, welches einen Überblick über die aktuelle Version (Stand: Januar 2010) der Windows Azure Platform gibt. Zu einem späteren Zeitpunkt werden die Neuerungen in die betreffenden Kapitel des Buches überführt und dann in einer zweiten Auflage des Buches veröffentlicht.

Allgemeine Änderungen der Plattform

Die Änderungen, die die Plattform erfahren hat, sind vielschichtig: Einige betreffen die Gesamtplattform, einige den Funktionsumfang von Windows Azure bzw. Azure Services. In Abbildung 10.1 ist die Windows Azure Platform im Versionsstand 1.0 im Überblick zu sehen.

Abbildung 10.1: Die Windows Azure Platform – Version 1.0

Hier fallen ein paar Änderungen gegenüber der CTP-Version unmittelbar auf:

• .NET Services sind nicht mehr zu sehen. Diese Dienstgruppe hat den Namen Windows Azure Platform AppFabric erhalten. Neben der reinen Namensänderungen haben sich auch eine Reihe von Änderungen in der AppFabric ergeben, die im ì Abschnitt »Änderungen der .NET Services« erläutert werden.
• Live Services sind formal nicht mehr Bestandteil der Windows Azure Platform. Zwar bestehen diese Dienste weiter und werden auch in den gleichen Rechenzentren wie Azure betrieben, sie werden aber nicht mehr unter der Marke Azure geführt, sondern als eigene Marke weiterentwickelt.
• Dynamics CRM Services und SharePoint Services sind formal ebenfalls nicht mehr Bestandteil der Windows Azure Platform. Diese beiden Dienstgruppen werden im Rahmen der Microsoft Online Services weiterentwickelt. Die beiden Produkte Dynamics CRM Online (befindet sich derzeit in Entwicklung) und SharePoint Online (verfügbar seit März 2009) werden neben der Möglichkeit der Anpassung über die Programmoberfläche bzw. SharePoint Designer über eigenen Programmcode erweiterbar sein. Damit erhalten diese Online Services die Funktionalität, die bisher über die beiden Azure Services geplant war.

Damit besteht die Windows Azure Platform nun aus den drei Dienstgruppen Windows Azure, SQL Azure und Windows Azure Platform AppFabric. In jeder der drei Gruppen wurden zum Produktstart Änderungen bekanntgegeben bzw. Erweiterungen angekündigt, die in den jeweiligen Folgeabschnitten beschrieben werden.

Preismodelle für die Bestandteile der Plattform

Mit der Produktivsetzung, bei der eine Abrechnung der genutzten Ressourcen erfolgen soll, sind jetzt auch entsprechende Preismodelle verfügbar. Diese orientieren sich grundsätzlich am Verbrauch der einzelnen Cloud Services, legen aber jeweils unterschiedliche Abrechnungseinheiten zugrunde. So wird die Rechenleistung von Windows Azure pro Abrechnungsstunde, Windows Azure Storage nach Datenmenge und Speicheroperationen, SQL Azure nach Abrechnungsmonat und die AppFabric nach der Zahl der Transaktionen bzw. Verbindungen abgerechnet. Tabelle 10.1 gibt einen Überblick über die Kosten der einzelnen Dienste.

Tabelle 10.1: Kosten für die Nutzung der einzelnen Dienste der Windows Azure Platform

Zu beachten ist, dass bei Windows Azure Kosten anfallen, sobald eine Anwendung auf Windows Azure installiert ist und nicht erst, wenn auch tatsächlich Zugriffe auf die Anwendung erfolgen. Für die Betreiber von Anwendungen besteht somit ein Optimierungspotenzial aus der Steuerung der Anzahl aktiver Instanzen einer Anwendung. Die Anzahl sollte immer so klein wie möglich (um Kosten zu sparen) und so groß wie nötig (um Antwortzeiten für Anwender zu minimieren) gehalten werden.

Unabhängig vom genutzten Dienst kommen zu den in Tabelle 10.1 aufgelisteten Kosten noch Beträge für den Datentransfer, der in Microsofts-Rechenzentren hinein bzw. aus diesen heraus geht. Diese sind in Tabelle 10.2 aufgeführt.

Tabelle 10.2: Kosten für die Datentransfers über die Grenzen von Microsofts Rechenzentren

Der Datentransfer innerhalb der Rechenzentren ist kostenfrei. Kommuniziert eine auf Windows Azure betriebene Anwendung mit einer auf SQL Azure betriebenen Datenbank (und Anwendung und Datenbank liegen im gleichen Rechenzentrum), fallen für den Datenaustausch keine Kosten an.

Die Nutzung von Azure auf Basis der oben beschriebenen Preismodelle ist die flexibelste Variante. Es fallen genau dann Kosten an, wenn die entsprechende Ressource genutzt wird. Ohne Nutzung, keine Kosten. Bezogen auf die Abrechnungseinheit ist dies allerdings auch die teuerste Variante (die Flexibilität wird also über einen höheren Preis erkauft). Neben dieser sogenannten »pay as you go«-Variante gibt es weitere Bezugsmöglichkeiten, bei denen für eine vereinbarte Abnahmemenge Rabatte gewährt werden:

• Windows Azure Platform Development Accelerator Core
  Befristet auf sechs Monate kann hier ein festgelegtes Kontingent von Windows Azure Compute, Windows Azure Storage, Datentransfer, Service-Bus-Verbindungen und Access-Control-Transaktionen mit 54% Kostenrabatt genutzt werden.
• Windows Azure Platform Development Accelerator Extended
  Zusätzlich zu den Dienstkontingenten des Development Accelerator Core umfasst dieses Paket auch eine SQL Azure-Datenbank (Business Edition) und bietet 52% Kostenrabatt gegenüber dem »pay as you go«-Preis.
• Windows Azure Platform Introductory Special
  In einem zeitlich sehr befristeten Rahmen können bei diesem Angebot einige Azure Services zu Test- und Evaluierungszwecken kostenfrei genutzt werden.

Weitere Informationen zu diesen und weiteren Angeboten können über den URL http://www.microsoft.com/windowsazure/offers/ abgerufen werden.

Service Level der Plattform

Darüber hinaus erfolgt die Nutzung der Plattform unter verbindlichen Service Level Agreements (SLAs). Ein Ausschnitt aus diesen SLAs ist in Tabelle 10.3 zu sehen.

Tabelle 10.3: Ausschnitt aus den Service Level Agreements der Windows Azure Platform (Angaben ohne Gewähr)

Eine Vereinbarung individueller Service Level (insbesondere höhere Service Level) ist grundsätzlich nicht möglich. Die Dienste werden in einer automatisierten Form angeboten, die es nicht zuließe, für einzelne Anwender Ausnahmeregelungen zu treffen. Werden andere als die angebotenen Service Level benötigt, verweist Microsoft an die große Zahl an Hosting-Partnern, bei denen in der Regel eine individuelle Vereinbarung von Service Leveln möglich ist.

Auswirkungen auf die Buchkapitel im Überblick

Die Änderungen der Plattform haben zum Teil große Auswirkungen auf die entsprechenden Kapitel des Buches. Tabelle 10.4 listet die wichtigsten Änderungen der Services auf.

Tabelle 10.4: Überblick über die wichtigsten Änderungen bezogen auf die Buchkapitel

Die folgenden Abschnitte geben einen detaillierteren Überblick über die Änderungen und Erweiterungen der einzelnen Dienste der Windows Azure Platform.

Weitere Informationen

• Buch “Cloud Computing mit der Windows Azure Platform”

[1] Router und Queues sollen in zukünftigen Versionen der Plattform (ggf. mit erweitertem Funktionsumfang) wieder zur Verfügung stehen.

[2] Die Unterstützung der WS-* Standards soll in zukünftigen Versionen wieder zur Verfügung stehen.

Normalerweise bin ich mit der Übernahme von Werbetexten für Infomaterial etwas zurückhalten. Das neue Training-Kit für Visual Studio 2010 und .NET Framework 4 ist aber schon eine sehr feine Sache.

Das Training-Kit steht ab sofort kostenlos öffentlich zum Download bereit. Diese umfangreiche Ressourcensammlung enthält erweiterte und kommentierte Versionen der Trainingsinhalte von Microsoft, wie sie auch im Rahmen der Microsoft Trainings verwendet werden.

Das Visual Studio 2010 und .NET Framework 4 Training-Kit richtet sich an Anwender, Journalisten, Trainer und Unternehmen. Es wurde auf die aktuelle Beta 2 abgestimmt und enthält 17 Präsentationen, 21 Demos und 26 Hands-On-Labs (Tutorien). Neu in der aktuellen Version sind außerdem spezifische Inhalte für Office, SharePoint und Application Lifecycle Management. 

• Download: Visual Studio 2010 and .NET Framework 4 Training-Kit

Seit Mitte Dezember 2009 sind außerdem neue deutschsprachige Webcasts zu Visual Studio 2010 von den Visual Studio 2010/.NET-Experten Christian Binder und Dariusz Parys verfügbar. Auf Basis der Visual Studio 2010 Beta 2 werden am Beispiel einer Windows Forms Anwendung einige Aspekte der Anwendungsentwicklung demonstriert. Zielgruppe der Serie sind vor allem Entwickler und Tester. Angefangen mit einigen Grundlagen zu Agiler Software Entwicklung mit VS 2010 über die Erweiterung der Windows Forms Anwendung bis hin zum Testing der Anwendung wird alles in einem EndtoEnd-Demo gezeigt. Nach Erweiterung und Test der Windows Forms Anwendung zeigt, wird auch darauf eingegangen, wie mit Hilfe neuer .NET Framework Technologien , wie Workflow Foundation 4, Entitiy Framework 4 und ASP.Net MVC, das Anwendungs-Szenario effizient erweitert werden kann.

• Zur Webcast-Serie zu Visual Studio 2010 und .NET Framework 4

Seit Freitag, den 8. Januar 2010, ist SQL Azure nun auch in Europa, genauer: Nordeuropa verfügbar. Mit diesem Datum ist es möglich, beim Anlegen eines neuen SQL Azure Servers zwischen folgenden Regionen zu wählen:

• South Central US
• East Asia
• North Europe

Originalpost: SQL Azure Team Blog

Weitere Informationen

• Windows Azure Platform
  (http://www.azure.com)
• SQL Azure Team Blog
  (http://blogs.msdn.com/ssds/)