PaaS2 Added-Value Services in Azure
Kommentare

Dank des Marketingengagements von Cloud-Anbietern wie Microsoft und Amazon hat wahrscheinlich jeder Entwickler schon einmal die Begriffe IaaS, PaaS und SaaS gehört. Sie bezeichnen den Teil der Softwarearchitektur, den der Cloud-Anbieter bereitstellt: nur die Infrastruktur, die Anwendungsplattform oder gar die fertige Softwarelösung. Wie bei vielen IT-Themen haben es die Marketingkampagnen geschafft, die Begriffe zu verwaschen. Was ist in der Praxis der Unterschied zwischen IaaS und PaaS für Entwickler und Administratoren? Welche konkreten Lösungen gibt es in der Windows Azure Cloud? Was hat die Wahl zwischen IaaS und PaaS für Auswirkungen auf die Betriebskosten? Diesen Fragen gehen wir in diesem Artikel auf den Grund.

Will man sich als Microsoft-orientierter Softwareentwickler heute für eine öffentliche Cloud entscheiden, kommen zwangsläufig die beiden großen Anbieter mit ins Spiel: Amazon AWS und Microsoft Windows Azure. Historisch betrachtet starteten die beiden Angebote an entgegengesetzten Enden des Spektrums: Während Amazon lange vor Microsoft durch Infrastructure as a Service (IaaS) erfolgreich wurde, bestand die Azure-Cloud bei ihrem Erscheinen praktisch nur aus Platform as a Service (PaaS). Heute ist diese Zuordnung nicht mehr gültig. Amazon hat zum Beispiel mit Elastic Beanstalk einen PaaS am Start und Microsoft bietet in Windows Azure seit einigen Monaten auch vollwertiges IaaS für Windows und Linux an. In diesem Artikel werden wir uns auf Windows Azure konzentrieren.

Unterschied IaaS und PaaS

Was ist der Unterschied zwischen IaaS und PaaS in der Praxis? Bei der Beantwortung dieser Frage sind zwei Aspekte zu betrachten:

  • Wie sehr will man sich rein auf die eigene Anwendungssoftware konzentrieren und sich nicht um Infrastruktur kümmern (müssen)?
  • Wie viel Kontrolle ist man bereit, abzugeben?

Die erste Frage würde man in der klassischen Wirtschaftslehre als die Frage nach der Fertigungstiefe, also der Frage nach dem Anteil an Eigenfertigung, bezeichnen. Speziell kleine und mittlere Softwarefirmen tendieren oft dazu, sich strategisch auf Kernkompetenzen konzentrieren zu wollen. Innovation bedeutet Verbesserung der Anwendungssoftware. Aufbau, Betrieb und Verwaltung notwendiger Basisinfrastruktur wird als unerwünschter Ballast gesehen, bindet unnötig viele Ressourcen (z. B. investiertes Geld, Personal etc.) und macht das Unternehmen unflexibel. Was spricht also dagegen, voll auf PaaS zu setzen und möglichst fertige Services als Grundlage für den Betrieb der eigenen Software in der Cloud zu nehmen?

Die zweite Frage ist in manchen Fällen ein Showstopper bei PaaS und zwingt eventuell zu IaaS. Je mehr man sich von IaaS entfernt, desto weniger Kontrolle hat man über die Umgebung, in der die eigene Software ausgeführt wird. Ihre Software braucht ein spezielles, am Server installiertes Windows Service, das unter einem Benutzerkonto mit gewissen Berechtigungen läuft? Eine solche Voraussetzung würde eine ganze Reihe von PaaS-Angeboten in Windows Azure ausschließen, da Ihnen dort die Möglichkeit zum Installieren eigener Services, zum Anlegen individueller Benutzerkonten oder gar zum Fernzugriff auf den Server verwehrt bleibt.

Generell kann man sagen, dass relativ neue Webanwendungen oder Web Services, die zum Beispiel vollständig auf aktuellen Versionen von .NET oder Node.js basieren, meist recht gut für PaaS geeignet sind. Alte, über Jahre gewachsene Programme erfordern oft eine spezifische Infrastrukturumgebung, da sie nicht von Grund auf mit der Cloud im Hinterkopf gestaltet wurden. Für sie muss oft IaaS der Vorzug gegeben werden. Lassen Sie uns aber die konkreten IaaS- und PaaS-Services in Windows Azure näher betrachten und ihre Vor- und Nachteile gegenüberstellen. Unser Ziel ist, dass Sie für Software, die Sie in Zukunft als Service in der Cloud anbieten möchten, eine gute Entscheidungsgrundlage bekommen und bewusst den richtigen Schritt zu IaaS oder PaaS gehen können.

IaaS

Windows Azure Virtual Machines [1] (WAVM) ist der Name des IaaS-Diensts in der Microsoft Cloud. Entscheidet man sich gegen ein eigenes Rechenzentrum und für WAVM, nimmt einem Microsoft nur die Basisdienste ab:

  • Betrieb der physischen Rechenzentrumsinfrastruktur (Stromversorgung, Netzwerk, Internetanbindung, Server etc.)
  • Installation des Betriebssystems (Windows oder Linux)
  • Installation von Serverdiensten wie Datenbank (Microsoft SQL Server, Oracle), SharePoint, BizTalk etc.

Die beiden unteren Punkte sind optional. Will man die volle Kontrolle über seine virtuelle Maschine, kann man mit einem lokalen Hyper-V auch Images selbst herstellen und diese in Azure hochladen. Sollten Sie sich für diesen Weg entscheiden, vergessen Sie jedoch das Lizenzthema nicht. Bei vorkonfigurierten virtuellen Maschinen sind in Azure die Lizenzen zum Beispiel für SQL Server bereits enthalten. Verwendet man ein individuelles Image, muss man sich selbst um entsprechende Lizenzen kümmern (Bring your own License-Prinzip).

Natürlich können auch komplexere Szenarien mit WAVM umgesetzt werden. Speziell vorbereitete Images (Sysprep, siehe auch [2]) können als Kopiermuster verwendet werden, um bei Bedarf neue Instanzen einer virtuellen Maschine herzustellen. Verwendet wird dies zum Beispiel zum dynamischen Skalieren von Webfarmen. Mithilfe von Windows Azure Virtual Network [3] können komplexe Netzwerkstrukturen in der Cloud inklusive VPN-Anbindung aus dem lokalen Unternehmensnetz aufgebaut werden.

Allen Optionen gemeinsam ist, dass man als Administrator vollen Zugriff auf die Server zum Beispiel über Remote-Desktop hat und sich seine Umgebung konfigurieren kann, wie man möchte. Der große Unterschied ist, dass man anstatt Server auszupacken und zu verkabeln, diese mit einem Mausklick oder ein paar PowerShell Scripts [4] anlegt. Man spricht in diesem Zusammenhang auch von einem Software-defined Data Center [5]. Das Rollenbild eines Infrastrukturadministrators ändert sich dadurch dramatisch. Aus ihm wird bis zu einem gewissen Grad ein Softwareentwickler, der statt Expertenwissen über Hardware, ein PowerShell-Zauberer wird. Dieses Prinzip wird auch als DevOps bezeichnet: Administratoren werden selbst zu Softwareentwicklern oder arbeiten zumindest sehr eng verzahnt mit Entwicklern zusammen.

[ header = Seite 2: PaaS Stufe 1: Cloud Services ]

PaaS Stufe 1: Cloud Services

Windows Azure Cloud Services (WACS) [2] sind der erste Schritt weg von IaaS hin zu PaaS. Sie sind der Urahn in Windows Azure, da mit ihnen alles begann. Wie unterscheidet sich die Verwendung von WACS von WAVM? Der wichtigste Unterschied ist der Ausgangspunkt: Während bei WAVM alles mit dem Image einer virtuellen Maschine beginnt, startet man bei WACS mit einem Projekt in Visual Studio (Abb. 1). Der Schritt des manuellen Konfigurierens eines VM Images entfällt also komplett. In Visual Studio konfiguriert man über Assistenten oder XML-Dateien (.cscfg und .csdef), welche Infrastruktur man braucht. Hier einige Beispiele:

Abb. 1: Anlegen eines Cloud Service in Visual Studio 2013

  • Welche Serverrollen braucht man (z. B. eine Webserverfarm, einen Cluster für einen Hintergrundjob etc.)?
  • Wie groß müssen die Server sein (T-Shirt sizing)?
  • Welche Ports müssen nach außen auf der Firewall offen sein und über welche Ports können die verschiedenen Serverrollen miteinander kommunizieren?
  • Welche Zertifikate müssen deployt werden?

Das eigentliche Veröffentlichen der Anwendung in Windows Azure geschieht bei WACS entweder direkt aus Visual Studio, automatisiert über einen TFS-Build-Server oder über Kommandozeile und/oder PowerShell. Der zu veröffentlichende Code wird in ein Cloud Service Package (.cspkg, ZIP-Datei) verpackt und in Azure hochgeladen. Abbildung 2 stellt den Veröffentlichungsprozess grafisch dar.

Mit dem Betriebssystem und dem IIS hat man, wenn man das nicht möchte, nichts zu tun. Azure wird automatisch die gewünschte Anzahl an Serverinstanzen starten, das Package installieren und die notwendige Netzwerkstruktur konfigurieren. Und das Schönste daran: Dieser Prozess ist nicht einmalig, sondern geschieht regelmäßig und von Azure automatisch verwaltet:

  • Wenn ein Server einen Windows Patch braucht, wird er automatisch heruntergefahren, aktualisiert und wieder gestartet.
  • Wenn ein Server defekt ist, bekommt man automatisch einen neuen Server, auf den das Package installiert und der zum Load Balancer hinzugefügt wird.
  • Wenn die Last variiert, kann man mit einem Klick und ohne kompliziertes Sysprep die Anzahl der Knoten im Cluster nach oben oder unten anpassen.

Abb. 2: Veröffentlichung eines Cloud Service in Windows Azure

Doch was ist, wenn man individuelle Anpassungen am Betriebssystem vornehmen muss, bevor die eigene Anwendung laufen kann? Auf den ersten Blick scheint das unmöglich zu sein. Das ist jedoch nicht der Fall. Man kann bei Bedarf seine Serverrollen so konfigurieren, dass sie Remote Desktop erlauben (Abb. 3). Diese Option ist allerdings trickreich: Verbindet man sich manuell zu einer Instanz und führt manuelle Konfigurationen durch, sind diese nicht dauerhaft. Wie oben erwähnt, erstellt Windows Azure bei Bedarf neue Serverinstanzen für Ihr Cloud Service. Dabei werden im Gegensatz zu WAVM nicht Kopien eines Image, sondern brandneue Windows-Server erstellt, in denen Ihr Cloud Service Package installiert wird. Manuelle Änderungen, die Sie durch Remote-Desktopzugriff durchgeführt haben, sind weg.

Es gibt jedoch eine Lösung für dieses Problem: Als DevOp kann man eventuell notwendige Konfigurationsänderungen oder Installationsroutinen in Skripten (Kommandozeilenskripte oder auch PowerShell) automatisieren und diese Skripte in Visual Studio zum Cloud Service hinzufügen. Wann immer Windows Azure neue Serverinstanzen für Sie erstellt, werden erst diese Skripte ausgeführt. In den Skripten haben Sie bei Bedarf volle Kontrolle über das gesamte Betriebssystem und können die Umgebung genau so einrichten, wie Ihre Anwendung das braucht.

Die oben beschriebene Einschränkung hinsichtlich Änderungen am lokalen System gilt übrigens auch für die Anwendung selbst. Speichert sie Daten im lokalen Dateisystem, sind diese im schlimmsten Fall plötzlich weg, wenn man sich nicht darum kümmert, die Daten rechtzeitig in ein anderes Speichermedium (z. B. Datenbank, Windows Azure Blob Storage etc.) zu übertragen.

Abb. 3: Remote Desktop für PaaS Service aktivieren

Wozu also PaaS Cloud Services statt WAVM? Es gibt eine ganze Reihe von Argumenten, die dafür sprechen:

  • Geringere Kosten: Im Moment sind Windows-Server in WACS eine Spur günstiger als virtuelle Maschinen in WAVM. Viel wichtiger ist jedoch das einfache Scale Out und Scale Down je nach Last. Warum soll man in der Nacht genauso viele Server betreiben wie am Tag, wenn in der Nacht kaum Ressourcen gebraucht werden? Skalieren ist zwar auch mit WAVM möglich, erfordert jedoch durch Sysprep einiges an manueller Vorbereitungsarbeit.
  • Weniger Administrationsaufwand: Das manuelle Konfigurieren und eventuelle Sysprep’en erfordert spezielles Administrationswissen und Zeit. Die sich daraus ergebenden Kosten kann man in die Softwareentwicklung stecken.
  • Automatisches Update: Microsoft kümmert sich um das Aktualisieren des Betriebssystems. Selbst der Umstieg von einer Betriebssystemversion zu anderen (z. B. Server 2008 auf 2012) ist mit dem Ändern eines Attributs in einer XML-Datei getan.

Es gibt jedoch auch Nachteile von WACS. Manchmal ist das Automatisieren von Konfigurations- und Installationsarbeiten langwierige, mühsame Kleinarbeit. Ein Installer, der manchmal abstürzt oder lange läuft, kann einen in den Wahnsinn treiben. Generell ist das Entwickeln von Start-up-Skripten nicht ganz einfach, da solche Skripte schwierig zu debuggen sind.

[ header = Seite 3: PaaS Stufe 2: Windows Azure Websites ]

PaaS Stufe 2: Windows Azure Websites

Die im vorigen Abschnitt dargestellten Cloud Services sind bereits ein großer Schritt weg von der Infrastruktur hin zur fertigen Anwendungsplattform. Es bleibt jedoch die Tatsache, dass der Entwickler das Betriebssystem nicht ganz vergessen kann. Stellen Sie sich vor, Sie möchten Ihre Webanwendung in zwei Projekte teilen: Einerseits die öffentliche Webseite und andererseits ein REST-basierendes Web-API. Würden Sie Ihre Visual Studio Solution so aufbauen, dass Sie daraus ein Cloud Service mit zwei Webrollen machen, müssten Sie mindestens 2 * 2 = 4 Instanzen, also vier Windows-Server in der Cloud betreiben. Das wird unnötig teuer, da Sie ohne WACS wahrscheinlich beide Anwendungsteile auf einem Server vereinen würden. Wenn Sie nun sogar mehrere solcher Anwendungen für verschiedene Kunden betreiben, steigt die Anzahl der Server und damit auch die monatliche Rechnung von Microsoft rapide an. Man ist als Entwickler gezwungen, bei der Strukturierung der Lösung schon über die Konsequenzen auf den Betrieb der Anwendung in Windows Azure nachzudenken. So sollte PaaS nicht funktionieren.

Dazu kommt, dass viele Entwickler, die zum Beispiel mit ASP.NET oder Node.js arbeiten, überhaupt keine besonderen Anpassungen am Betriebssystem brauchen. Weder muss noch will man sich zum Windows-Server über Remote Desktop verbinden. Man will sich eigentlich voll auf die Anwendungsentwicklung konzentrieren und sich die Hände beim IIS-Konfigurieren nicht mehr „schmutzig“ machen.

Windows Azure Websites (WAWS) [7] bieten genau für diese Probleme eine Lösung. Lassen Sie sich von dem Namen nicht in die Irre führen, natürlich kann man in WAWS nicht nur Webseiten sondern auch Web Services betreiben. Im Wesentlichen erhält man in WAWS statt eines ganzen Windows-Server einen fertig konfigurierten IIS. Das Handling von WAWS ist aus Entwicklersicht auf den ersten Blick nicht unähnlich wie bei WACS: Man entwickelt lokal und veröffentlicht die fertige Anwendung aus Visual Studio (mithilfe des bekannten Web-Deploy-Mechanismus [8]), automatisiert über einen TFS-Build-Server oder auch über Skripte.

WAWS kann aber mehr. Einfache Webseiten können auch über FTP oder sogar über Dropbox veröffentlicht werden. Dazu kommt, dass das Dateisystem bei WAWS im Gegensatz zu WACS persistent ist. Bei WACS ist wie oben erwähnt das lokale Dateisystem nur für die temporäre Speicherung von Daten geeignet, da im schlimmsten Fall die Daten verschwinden können. Bei WAWS stecken hinter dem Dateisystem aber in Wirklichkeit gemountete Virtual Hard Disks (VHD), die in Windows Azure Blob Storage gespeichert und dadurch dauerhaft sind. Betreibt man eine Webfarm in WAWS, die intern auf mehrere Windows-Server verteilt ist, greifen alle auf die gleichen VHDs zu. Speichert Ihr Programm also Daten lokal, bleiben diese erhalten und gehen nicht verloren, falls ein Server ausfällt und durch einen neuen ersetzt wird.

So richtig spannend wird WAWS jedoch durch das Preismodell: Während die kleinste Skalierungseinheit bei WACS und WAVM immer ein Windows-Server ist, kann WAWS mehrere Webanwendungen auf einen Server packen und diese sicher voneinander trennen. Je nach Ihrer Konfiguration können Sie sich also Ihre Windows-Server mit anderen Azure-Entwicklern teilen oder auch nur mehrere Ihrer eigenen Anwendungen auf einen Server vereinen. WAWS bietet dafür verschiedene Betriebsmodi:

 

  • Free: In diesem Modus teilen Sie sich Ihre Server mit anderen Azure-Kunden und müssen auch mit streng limitierten Ressourcen (z. B. Hauptspeicher, CPU etc.) sowie ohne SLA auskommen. Im Gegenzug ist das Angebot, wie der Name schon sagt, kostenfrei. Es eignet sich gut zum Lernen und Üben sowie für kleine, private Webanwendungen.
  • Shared: Wie auch bei Free bekommen sie im Hintergrund keine eigenen Windows-Server. Bei Shared sind jedoch die Ressourcen nicht mehr so stark eingeschränkt. Verbrauchen Sie mehr als das kostenfreie Kontingent, müssen Sie den Rest bezahlen. Shared bietet ein besonders gutes Preis-Leistungs-Verhältnis bei Webanwendungen mit relativ wenig Last, da Microsoft viele Webanwendungen auf jeden einzelnen Server packen kann.
  • Standard: Hier haben Sie Ihre eigenen Windows-Server, müssen sich aber in keiner Weise um diese kümmern. Wählen Sie einfach, welche Webanwendungen sie kombinieren möchten, definieren Sie die Servergröße und -Anzahl (bei Bedarf auch mit dynamischer Skalierung basierend auf Uhrzeit oder aktueller Systemlast) und Windows Azure kümmert sich um den Rest. Abbildung 4 zeigt die Konfiguration des Standard-Modus.

Abb. 4: Mehrere Webanwendungen mit WAWS auf einer Serverfarm vereinen

Welche Vorteile hat also WAWS gegenüber den zuvor beschriebenen Ansätzen:

  • Geringere Kosten: Durch das Kombinieren mehrerer Webanwendungen auf einer Serverfarm spart man sich in der Praxis eine Menge virtueller Server und dadurch Geld. Dazu kommt, dass man bei WAWS im Standard-Betriebsmodus in den Genuss des 99,9-prozentigen SLAs kommt, auch wenn man nur eine Serverinstanz aktiviert. Bei WACS hat man dieses SLA nur bei Rollen, für die mindestens zwei Serverinstanzen existieren – unabhängig davon, ob man diese zum Bewältigen der Last überhaupt braucht oder nicht. Wieder eine Möglichkeit, durch WAWS Serverinstanzen und dadurch Geld zu sparen.
  • Schnelleres Deployment: Bei WACS muss Windows Azure bei jedem Deployment im Hintergrund Windows-Server vorbereiten. Das nimmt einige Minuten in Anspruch. Hinter WAWS stecken fertige, von Microsoft „auf Lager gelegte“ Server, die nur noch auf Ihr Programm warten. Dadurch können Sie bei WAWS in wenigen Sekunden statt Minuten deployen. Das führt zu weniger Wartezeiten im Entwicklungs- und Betriebsprozess und dadurch zu Zeit, die man in die Entwicklung von Innovationen in der eigenen Software investieren kann.

Warum sollte also noch jemand WACS oder WAVM verwenden, wenn WAWS solche Vorteile bietet? Die Antwort lautet: Kontrolle. Bei WAWS haben Sie überhaupt keine Möglichkeiten mehr, den Server individuell zu konfigurieren oder eigene Komponenten auf Serverebene zu installieren. Sie möchten eine neue CTP von .NET testen und diese auf Ihren Server installieren? Keine Chance bei WAWS, kein Problem bei WACS oder WAVM. Man gibt also Kontrolle und Individualität auf und erzielt Vorteile durch Standardisierung – das klassische Prinzip von Economy of Scale [10].

[ header = Seite 4: Paas Stufe 3: Windows Azure Mobile Services ]

PaaS Stufe 3: Windows Azure Mobile Services

Kann man PaaS noch weiter treiben, als es bei WAWS schon der Fall ist? Man kann. Windows Azure Mobile Services (WAMS) [11] sind der beste Beweis dafür. Der Trend bei PaaS geht dazu, für gewisse Anwendungsfälle spezialisierte Dienste anzubieten. Bei WAMS handelt es sich um folgenden Anwendungsfall:

  • Man will eine relativ einfach strukturierte Datenbankanwendung basierend auf SQL Server erstellen. Primäre Zielgruppe sind dabei mobile Geräte (z. B. Windows-Tablets, Windows-Phones, iOS, Android etc.).
  • Der Zugriff auf die Datenbank soll über REST Web Services geschehen. Die Logik der Web Services wird mit Node.js, also serverseitigem JavaScript, entwickelt.
  • Der Zugriffsschutz erfolgt mithilfe von Federated Identity [11], also Identity Providern wie Microsoft, Facebook, Twitter oder Google.
  • Die Anwendung soll in gewissen Fällen Push-Nachrichten zum mobilen Endgerät schicken können.

Möchte man eine solche Anwendung ohne WAMS aufbauen, muss man viele verschiedene Komponenten beherrschen. Hier einige Beispiele:

  • Eine SQL-Server-Datenbank muss in Azure angelegt werden.
  • Man muss mit JavaScript und Node.js die Web-Service-Schicht entwickeln und diese zum Beispiel in WAWS betreiben.
  • Die Web Services müssen mithilfe von entsprechenden Bibliotheken mit den Identity Providern verbunden werden.
  • Auf den Clients muss man sich Klassenbibliotheken zum einfachen Zugriff auf seine Services erstellen.

WAMS nimmt Ihnen alle diese Schritte ab. Beim zweiten Punkt haben Sie die Möglichkeit, die Standardlogik für CRUD (Create, Read, Update, Delete) um individuelle Logik zu ergänzen. Dabei geht WAMS sogar soweit, dass Sie dafür nicht einmal unbedingt Visual Studio brauchen. Abbildung 5 zeigt, wie man direkt in der Windows-Azure-Managementoberfläche den Skriptcode eingeben kann. Zugegeben, diese Variante ist nur bei relativ kleinen Anwendungen praktikabel. Bei komplexeren Programmen kann man die Skriptlogik mit einer Entwicklungsumgebung seiner Wahl entwickeln, in Git einchecken und das Quellcode-Repository mit WAMS verknüpfen (für Details siehe [12]).

Abb. 5: CRUD-Logik in WAMS direkt im Browser hinzufügen

Ähnlich einfach erfolgt die Steuerung der Zugriffsberechtigungen. Abbildung 6 zeigt, wie in der Azure-Managementoberfläche der Zugriff auf eine WAMS-Tabelle mit einem Klick für nicht authentifizierte Benutzer gesperrt werden kann. Braucht man feinere Berechtigungen, kann man diese in den oben erwähnten Skripten mithilfe eines eigenen WAMS-API implementieren.

Abb. 6: Berechtigungen auf Tabellen in WAMS setzen

WAMS schränkt Sie als Entwickler in Ihren Freiheitsgraden deutlich ein. Sie können weder die Möglichkeiten der zugrunde liegenden SQL-Datenbank voll nutzen, noch können Sie im Augenblick serverseitige Logik in einer anderen Programmiersprache als JavaScript entwickeln. Wenn Sie aber eine Anwendung entwickeln wollen, die den oben erwähnten Kriterien entspricht, nimmt Ihnen WAMS einen großen Teil Ihrer Arbeit ab.

Ein zweites Szenario, in dem meiner Erfahrung nach WAMS seine Stärken ausspielt, sind vereinfachte Prototypen. Wenn Sie möglicherweise einen raschen Prototyp brauchen, um Kunden oder Investoren von Ihrer Idee zu begeistern, kann Ihnen WAMS den entscheidenden Vorteil in Sachen Time to Market liefern.

Das Preismodell unterscheidet sich bei WAMS gegenüber den anderen Angeboten in Windows Azure grundlegend. Sie haben zwar wie bei WAWS die Wahl zwischen Free, Shared und Standard. Anstatt für Server zu bezahlen, bezahlen Sie aber für die Anzahl an Aufrufen Ihres Web-API. Abhängig von der zu erwartenden Last kann das zu einer deutlichen Kostenreduktion oder aber auch zu höheren Kosten pro Monat führen.

Fazit: Sie haben die Qual der Wahl

Es gab Zeiten in meiner IT-Karriere, in denen ich mein Geld damit verdient habe, Kunden beim Einrichten von IIS- oder SQL-Server-Clustern zu helfen. Diese Zeiten sind lange vorbei. Durch PaaS konzentrieren wir uns auf die Anwendungsentwicklung statt auf Infrastruktur, reduzieren Betriebskosten und machen Personal frei für die Weiterentwicklung unserer Softwarelösungen.

In dem Artikel haben Sie gesehen, dass PaaS nicht gleich PaaS ist. Die zugrunde liegende Infrastruktur ist unterschiedlich transparent und erlaubt verschieden starke Anpassungen. Wenn keine technischen Einschränkungen dagegen sprechen, empfehle ich für Webanwendungen heute in erster Linie WAWS. Die Vorteile sind bestechend. Dazu kommt, dass hier auch der oft zitierte Lock-in-Effekt nicht wirklich gegeben ist, da Anwendungen, die in WAWS laufen, technisch gesehen nur einen IIS brauchen. Man kann sie also im eigenen Rechenzentrum auf normalen Windows-Servern installieren und betreiben. Sogar der Installationsmechanismus Web Deploy steht in der Cloud genau wie beim lokalen IIS zur Verfügung.

Anders sieht es bei noch abstrakteren Services wie WAMS aus. Hier empfehle ich, genau zu prüfen und zu kalkulieren, ob die Vorteile, die der vorgefertigte Service bringt, die teilweise massiven Einschränkungen aufwiegen. Falls Ihre Anwendung dem Szenario, für das WAMS konzipiert wurde, gut entspricht, kann dieses PaaS-Angebot genau richtig für Sie sein. Wichtig ist die genaue Prüfung meiner Ansicht nach aber insbesondere deshalb, weil ein nahtloser Wechsel von WAMS zu beispielweise WAWS nicht möglich ist.

Auf jeden Fall sind die Optionen, die man als Softwarehersteller für den Betrieb von Software hat, vielfältiger geworden. Die Antwort „läuft auf Windows“ ist schon lange nicht mehr ausreichend. Es gilt, die Fertigungstiefe bewusst zu entscheiden und die Projektentwicklung mit einer Betriebskostenkalkulation in Excel zu beginnen. Die gewählte Softwarearchitektur wird dadurch möglicherweise stark beeinflusst.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -