Serie: Eigene Anwendungen auf Microsoft Azure - Teil 1: Überblick


Die meisten Personen, die sich für das Thema Cloud Computing interessieren, haben zunächst ein Szenario im Blick: die Ausführung einer eigenen Anwendung in der Cloud. Ob nun eine bestehende oder eine neu zu entwickelnde Anwendung: in beiden Fällen kommt man recht schnell an den Punkt an dem auffällt, dass es hierzu in Microsoft Azure – anders als bei einem klassischen Hoster oder vielen anderen Cloud-Anbietern – mehrere Optionen gibt. Microsoft Azure bietet nicht nur das Hosting klassischer virtueller Maschinen im Sinne eines Infrastructure-as-a-Service-Ansatzes, sondern auch speziellere Hosting Varianten, die optimiert sind auf die schnelle Bereitstellung von Web-Anwendungen oder die flexible Skalierung mehrschichtiger Anwendungen. Diese Blog-Serie beschäftigt sich nun mit der Auswahl der für ein bestimmtes Szenario bestgeeigneten Ausführungsmodells. Sie ist unterteilt in

Folgende Optionen stehen für die Ausführung eigener Anwendungen auf Microsoft Azure zur Verfügung:

Dies klingt zunächst verwirrend, letztlich lässt sich die Frage nach der besten Alternative aber recht schnell beantworten. Hinzu kommt die Möglichkeit, diese Optionen miteinander zu kombinieren. D.h. es ist durchaus möglich, dass Teile einer Anwendung als Website betrieben werden und andere Teile (z.B. die Datenbank) nutzen, die in einer Virtual Machine ausgeführt werden. Darüber hinaus ist ein Wechsel zwischen den Optionen möglich, d.h. man verbaut sich nichts, wenn man mit einer Option (z.B. Websites) beginnt und später auf eine andere Option (z.B. Cloud Services) wechselt.

Die vier Alternativen unterscheiden sich primär dadurch, wie viele Aspekte der Umgebung durch das Ausführungsmodell vorgegeben und damit von Azure automatisiert verwaltet werden (Einspielen von Patches, Updates, Failover-Management etc.) und welche Aspekte durch den Nutzer bestimmt werden können. Je mehr Aspekte bestimmt werden können, desto weniger Aspekte werden von Azure verwaltet. Umgekehrt gilt entsprechend: je mehr von Azure automatisiert verwaltet wird, desto weniger Einfluss auf die Umgebung ist durch den Nutzer möglich. Höchste Automatisierung (dafür geringste Möglichkeiten, die Umgebung zu kontrollieren) bieten Mobile Services. Bei Virtual Machines ist auf der anderen Seite die Möglichkeit, Einfluss auf die Umgebung zu nehmen, am größten, dafür ist der Automatisierungsgrad am kleinsten. Die beiden anderen Alternativen, Cloud Services und Websites, liegen dazwischen. Folgende Tabelle gibt einen Überblick auf die Alternativen und deren Automatisierungsgrad bzw. die Möglichkeiten, Einfluss auf die Umgebung zu nehmen.

  Virtual Machines Cloud
Services
Websites Mobile
Services
Automatisierungsgrad ●● ●●● ●●●●
Einflussmöglichkeiten ●●●● ●●● ●●

Die Tabelle gibt schon den wichtigsten Hinweis: wann immer möglich, sollten Anwendungen als Mobile Service bzw. Websites ausgeführt werden. Dort ist der Automatisierungsgrad und damit die Einsparungen im Vergleich zu einem Eigenbetrieb oder dem Betrieb in einer virtuellen Maschine am höchsten. Nur wenn die Anforderungen bestimmte Konfigurationen der Umgebung erfordern, d.h. die Umgebung stark angepasst werden muss, sollten Virtual Machines zum Einsatz kommen.

Für einige Szenarien können recht einfach erste Empfehlungen für die Ausführungsoption genannt werden:

Szenario Naheliegende
Ausführungsoption
Grund
Hosting einer ASP.NET- oder PHP-basierten Webseite Websites Websites bieten den höchsten Grad an Automatisierung, und die bereitgestellte Umgebung eignet sich sehr gut zur Ausführung von skalierbaren Web-Anwendungen.
Betrieb einer bestehenden Linux-basierten LOB-App Virtual Machines Virtual Machines bieten als einzige Ausführungsoption den Betrieb einer Linux-basierten Umgebung. Diese kann dann individuell konfiguriert werden. Der Nutzer kann sich hierzu als Admin anmelden.
Bereitstellung eines REST-Backends für mobile Anwendungen Mobile Services Mit Mobile Services lassen sich in kürzester Zeit Backends für mobile Anwendungen bereitstellen. Die Dienste können dabei leicht mit Funktionen zur Benutzerauthentifizierung, Push Notifications, Datenspeicherung versehen werden.
Cloud-Anwendung, die auf Ressourcen im lokalen Unternehmensnetzwerk zugreifen soll Cloud Services oder
Virtual Machines
Cloud Services und Virtual Machines bieten die Möglichkeit, über ein virtuelles Netzwerk Verbindungen zu einem lokalen Rechenzentrum herzustellen.

Diese Tabelle gibt nur einen ersten Hinweis auf eine geeignete Alternative. Vor einer konkreten Umsetzung sollte diese noch genauer betrachtet werden. In den weiteren Teilen dieser Blog-Serie sollen die einzelnen Alternativen deshalb genauer vorgestellt werden.

Weitere Informationen

Comments (4)

  1. Mathias says:

    Hallo, Ich habe Ihren Post "Kosten sparen in azure" "blogs.msdn.com/.../10-tipps-zum-kostensparen-bei-der-verwendung-der-windows-azure-platform.aspx" gelesen, und, da ich recht neu dabei bin direkt mal zwei Fragen bezüglich der Kostenstruktur: Erstens, kosten Idle VMs immer noch den "normalPreis/Stunde", und zweitens, da XS ja günstiger sind, lohnt es sich die Instanzengröße der nicht im "operations" betrieblichen VMs (Dev bei mir im wesentlichen) bei nicht-nutzung (Ich meine damit Abends oder die Tage an denen man nicht damit arbeitet) runterzuskalieren? Vermutlich schon. Ich werde es vermutlich in ein paar Tagen wissen. Aber ich schicke das hier dennoch ab, danke für den Blog. (p.s. Wenn ich noch günstigere temporäre VMs brache nutze ich TechLabs, ich meine wann kommt man schon "Hands on" in Datacentreverwaltungen (MVA-jünger)). Naja, ich mache mal weiter, tschüss.

  2. Holger Sirtl says:

    Hallo Mathias,

    der Blogpost ist schon ein wenig in die Jahre gekommen (was mich darauf hinweist, mal eine Aktualisierung zu schreiben ;).

    Tatsächlich hat sich bezüglich der VM-Abrechnung etwas getan: Eine heruntergefahrene VM verursacht keine Kosten mehr für die Rechenkerne, sofern sie über das Management-Portal oder via PowerShell heruntergefahren wurde und dann im Status "Stopped (Deallocated)" ist. In diesem Status fallen nur noch Kosten für den durch die VM-Disks belegten Speicher an. Wurde die VM aus der VM heraus (z.B. per Remote Desktop und Shutdown) heruntergefahren und ist dann im Status "Stopped", dann fallen sowohl Kosten für den Disk-Speicherplatz als auch für die reservierten Rechenkerne an. Es lohnt sich also, den Status genau zu prüfen. Ein Herunterskalieren bzw. Shutdown von VMs spart natürlich Kosten. Es ist eher die Frage, ob das mit der eigenen Anwendung, die darauf läuft, machbar ist. Weitere Maßnahme zur Kostenersparnis insbesondere in Dev-Szenarien ist es, "Basic"-Instanzen zu nutzen. Diese sind ca. 27% günstiger. Dafür fehlen der vorgeschaltete Loadbalancer und die Möglichkeit zur Auto-Skalierung. Das ist aber in Dev-Szenarien aber in der Regel kein Problem.

    Weitere Infos zu Basic Instanzen:

    azure.microsoft.com/.../basic-tier-virtual-machines-2

    Weitere Infos zu VM-Kosten (insbesondere in den FAQ):

    azure.microsoft.com/.../virtual-machines

    Viele Grüße,

    Holger Sirtl

  3. Holger Sirtl says:

    Ich habe jetzt einen eigenen Blog-Artikel zum Thema "Kostenkontrolle bei Virtual Machines" verfasst. Über folgenden URL ist er aufrufbar:

    blogs.msdn.com/.../kostenkontrolle-bei-microsoft-azure-virtual-machines.aspx

  4. W Klein says:

    Welche Anwendungen eigenen sich eigentlich für den Cloud-Betrieb? Diskutieren Sie hier mit:

    ibmexperts.computerwoche.de/.../anwendungen-fuer-die-cloud

Skip to main content