Categories
Analysen

Wo bleibt der Killer PaaS?

Es gibt nunmehr eine Vielzahl von Platform as a Service (PaaS) Angeboten auf dem Markt, die mehr oder weniger jede moderne Programmiersprache unterstützen. Doch eines haben alle gemeinsam. Jedes Angebot setzt auf maximal einem Infrastructure as a Service (IaaS) Angebot auf. Sei es ein Proprietäres oder das eines Drittanbieters. Wie zu erwarten ist derzeit noch die Infrastruktur von AWS die bevorzugte Wahl.

Betrachten wir eine kleine Auswahl von PaaS Angeboten und das darunter eingesetzte IaaS Angebot.

Was also fehlt ist ein unabhängiges gehostetes PaaS Angebot. Eine richtige PaaS Innovation! Eine Art PaaS Broker. SteamCannon geht in diese Richtung. Jedoch ist er 1. kein unabhängiger gehosteter Service (es steht ein AWS AMI zur Verfügung) und 2. wird derzeit nur AWS EC2 unterstützt.

Selbstverständlich muss der Service auch auf einer Plattform betrieben werden, aus diesem Grund mag das Verlangen nach einem unabhängigen gehosteten Service zunächst missverständlich sein. Aber bereits hier muss die Macht der Cloud genutzt werden. Der Killer PaaS darf nicht nur als AMI auf einer Infrastruktur laufen, sondern muss über mehrere Anbieter hinweg verteilt sein. So ist bereits dessen Ausfallsicherheit gewährleistet.

Der Killer

Warum ich diesen Service als Killer PaaS bezeichne ist ganz einfach. Er muss alle IaaS Anbieter und nicht nur einen bestimmten am Markt, sowie alle gängigen Programmiersprachen, unterstützen. Die Funktionalität ist in der Theorie recht simpel. Als Nutzer des Killer PaaS habe ich bereits vorher bei unterschiedlichen IaaS Anbietern wie AWS, Rackspace, GoGrid etc. einen Account registriert. Alternativ bietet mir der Killer PaaS an, dort einen erstellen zu lassen.

Nach belieben werden die Zugangsdaten für den jeweiligen IaaS Anbieter hinterlegt, auf die der Killer PaaS zugreifen kann. Ich kann bereits hier, wenn ich möchte, meinen primäre, sekundären etc. Anbieter festlegen. Mehr habe ich als Nutzer nicht zu tun.

Möchte ich meine Anwendungen in der Cloud betreiben, lade ich den Programmcode auf den Killer PaaS hoch. Dieser kümmert sich nun um den Rest und deployed die Anwendung auf die von mir hinterlegten Infrastrukturen. Das kann er entweder willkürlich vornehmen, da er den Status der jeweiligen Infrastruktur bzgl. Performance etc. kennt, oder er zieht die von mir vorher festgelegten Einstellungen in betracht und verteilt die Anwendung auf den primären Anbieter. Falls dieser zu ausgelastet ist auf den Sekundären usw..

Der Killer PaaS ist so intelligent, dass er die gesamte Anwendung über mehrere Anbieter hinweg verteilt und damit die bestmögliche Performanz und Verfügbarkeit gewährleistet. Habe ich mich als Nutzer jedoch zu Beginn dafür entschieden die Anwendung bei einem primären Anbieter ausführen zu lassen und hat dieser nun Performance- oder anderweitige Probleme, sorgt der Killer PaaS dafür, dass automatisch weitere (oder alle) Ressourcen von einem anderen Anbieter genutzt werden. Mir sind Fälle bekannt, bei denen Anwender bei AWS keine neuen Instanzen in einer AWS Region mehr starten konnten, weil nicht genügend Ressourcen vorhanden waren. Davon darf ich bzw. meine Anwendung jedoch nichts mitbekommen. Wenn meine Anwendung plötzlich einer enormen Belastung, z.B. auf Grund eines Besucherandrangs, ausgesetzt ist und der IaaS Provider ebenfalls einen Ressourcenengpass hat, sorgt der Killer PaaS dafür, dass Ressourcen von einem anderen Anbieter bezogen oder andere Maßnahmen eingeleitet werden.

Mit so einem Killer PaaS können ebenfalls viele Fragen bzgl. SLAs geklärt werden. Die Ausfallsicherheit und Verfügbarkeit der Anwendung wird hier durch den Killer PaaS sichergestellt. Da dieser ebenfalls über mehrere IaaS Anbieter hinweg in der Cloud betrieben wird, ist auch dessen Verfügbarkeit gewährleistet.

Was also benötigt wird ist eine unabhängige Cloud Management Platform wie bspw. enstratus, nur für PaaS.