Cloud Computing Anbietervergleich

http://go.
// microsoft.com/fwlink/?LinkId=166357.
RoleEnvironment.Changing +=
RoleEnvironmentChanging;

return base.OnStart();
}

private void RoleEnvironmentChanging(object sender,
RoleEnvironmentChangingEventArgs e)
{
// If a configuration setting is changing
if (e.Changes.Any(change => change is
RoleEnvironmentConfigurationSettingChange))
{
// Set e.Cancel to true to restart this role
// instance
e.Cancel = true;
}
}
}
    Listing 1.3: WebRole-Eintrittspunkt
    Ähnlich wie die WebRole verhält sich die WorkerRole. Der einzige Unterschied ist, dass es zusätzlich noch die Methode Run gibt. Das ist der eigentliche Worker-Prozess, wo auch Workflows gehostet werden. Der Assistent lässt die Rolle in einer Endlosschleife laufen, da sie sonst nicht mehr gestartet werden würde. Architekturell könnte man Rollen über Task-Rollen nachstarten, wofür jedoch eine Überwachungsrolle notwendig wäre. In Listing 1.4 ist die Methode Run dargestellt.
    public override void Run()
{
// This is a sample worker implementation.
// Replace with your logic.
Trace.WriteLine("WorkerRole1 entry point
called", "Information");

while (true)
{
Thread.Sleep(10000);
Trace.WriteLine("Working", "Information");
}
}
    Listing 1.4: Die Methode „Run“ der WorkerRole
    Die Kombination von Web- und WorkerRole bietet einige sehr interessante Ansatzmöglichkeiten für skalierbare Anwendungen in der Cloud. Damit das auch tatsächlich umgesetzt wird, ist jedoch eine gute Architektur der Anwendung nötig. Mit Asp.NET und PHP hat man auf Windows Azure zwei sehr mächtige Entwicklungssprachen zur Verfügung, die es erlauben, komplexe Webanwendungen zu erstellen. Sehr interessant sind die lokal ausgeführte Development Fabric und der Development Storage. Das gibt Softwareentwicklern und Systemhäusern die Möglichkeit, Anwendungen zuerst lokal zu entwickeln und zu testen, bevor sie in der Cloud auf die Masse losgelassen werden – und somit auch Kosten anfallen.
    Diagnostik und Management
    Wichtig für Cloud-Computing-Umgebungen sind das Management der Plattform und Anwendungen sowie die Diagnostik für den Fehlerfall. Ein Hauptproblem in der Cloud ist, dass es kaum Möglichkeiten gibt, Anwendungen sinnvoll zu debuggen. Daher muss man hier auf Diagnosefunktionen von Servern ausweichen.
    Die Diagnoese von Windows-Azure-Anwendungen läuft über Windows Azure Diagnostics, ein eigenständiges API, das von verschiedenen Quellen wie Clientanwendungen oder Windows-Azure-Rollen angesprochen werden kann. Standardmäßig werden die Windows Azure Logs für Web- und Worker-Rollen erstellt. Zusätzlich gibt es noch die Windows Diagnostic Infrastructure Logs. Für die WebRoles gibt es außerdem den IIS 7 Log, der Informationen über die WebRole sammelt.
    Windows-Azure-Rollen werden entweder über das Webportal oder eine Managementkonsole verwaltet. In der sehr übersichtlich gestalteten Onlineplattform kann man mit wenigen Mausklicks neue Services erstellen ( Abbildung 1.24 ). Hierbei werden lediglich der Name des Services sowie die Region, in der der Service gehostet werden soll, angegeben.

    Abbildung 1.24: Neuen Service erstellen
    Wählt man den Service aus, kann man eine Anwendung über die Schaltfläche Deploy erstellen. Das Paket, das hochgeladen wird, wird von Visual Studio erstellt. Ebenso wird die Konfigurationsdatei benötigt, die nicht im Paket enthalten ist. In Abbildung 1.25 ist die Verwaltungsplattform dargestellt.

    Abbildung 1.25: Windows-Azure-Upload verwalten
    Preise
    Für Windows Azure gibt es vier Instanztypen: klein, mittel, groß und extra groß. Hier fallen auch unterschiedliche Preise an, die in Tabelle 1.18 aufgelistet sind.
Instanz
Kosten in € pro Stunde
Micro
0.02840
Small
0,08520
Medium
0,01703
Large
0,34050
Extra Large
0,68090
    Tabelle 1.18: Die Kosten pro Compute Hour für Windows Azure
    Für die unterschiedlichen Instanztypen kommen natürlich auch unterschiedliche Rechenkapazitäten zum Einsatz: unterschiedliche CPU-Leistungen, Speichergrößen des Arbeitsspeichers, Speichergröße der Instanz sowie die Performanz bei I/O-Operationen ( Tabelle 1.19 ).
Instanz
CPU
Speicher
Instanzspeicher
I/O Leistung
Small
1,6 GHz
1,75 GB
225 GB
Mittel
Medium
2 x 1,6 GHz
3,5 GB
490 GB
Hoch
Large
4 x 1,6 GHz
7,0 GB
1000 GB
Hoch
Extra Large
8 x 1,6 GHz
14 GB
2040 GB
Hoch
    Tabelle 1.19: Leistung der jeweiligen Instanz
    Da es sich bei Windows Azure um ein PaaS-Angebot handelt, fallen außerdem Kosten für den Datentransfer an. In Europa und Nordamerika sind sie