Vergleich verschiedener PaaS

In den letzten Beiträgen dieser Serie habe ich die PaaS (Platform as a Service) Cloud Foundry, OpenShift, Google App Engine und Heroku vorgestellt. Zuvor wurde diskutiert, was PaaS überhaupt ist und nach welchen Kriterien verschiedene PaaS verglichen werden können. Zum Abschluss der Serie werden die vorgestellten Technologien anhand der diskutierten Kriterien verglichen.

vergleich

 

Technologische Merkmale

Die Open Source Technologien Cloud Foundry und OpenShift können on-premise betrieben werden, und sind das Fundament von mehreren public Plattformen. Dies garantiert eine hohe Portabilität zwischen mehreren Lösungsoptionen, wobei diese bei Cloud Foundry aufgrund der vielen Anbieter am höchsten ist. Bei der Google App Engine und Heroku hingegen ist man an den Anbieter gebunden und muss mit Migrationsaufwänden rechnen, falls die Plattform gewechselt werden soll. Aufgrund der Ähnlichkeit von Heroku zu Cloud Foundry und der eingesetzten Open Source Datenservices ist eine solche Migration von oder zu Heroku machbar.

On-Premise Portabilität Eingabe Service Binding
Cloud Foundry Ja Viele Anbieter Deployment Artefakt Ja
OpenShift Ja Einige Anbieter Git URL Nein
Google App Engine Nein Schlecht Vordefinierte Stacks Nein
Heroku Nein Services Deployment Artefakt Ja

Die Unterschiede aus technischer Sicht.

Die Unterschiede beim Deployment von Applikationen und der Integration von Datenservices sind nicht ganz eindeutig, da alle Plattformen mehrere Vorgehensweisen zulassen bzw. sich erweitern lassen. Die hier beschriebenen Vorgehensweisen sind diejenigen, die aus Sicht des Autors am ehesten bei der Plattform angewendet werden bzw. für die die Plattform ursprünglich konzipiert wurde. So ist es bei Cloud Foundry und der App Engine jeweils normal, das bereits erstellte Softwareartefakt und Konfigurationen an die Plattform zu senden, welche vorher in einem Continuous Integration bzw. Continuous Deployment System erstellt wurden. OpenShift hingegen hört auf die Änderungen eines externen Git Repositories, und erstellt das Softwareartefakt in einem entsprechenden Build selber. Dies ersetzt allerdings keine Continuous Integration Umgebung, diese lässt sich aber in OpenShift integrieren. Heroku hat sogar ein eigenes Git Repository, auf Basis dessen der Build ausgeführt wird.

Eine andere Entscheidungsgrundlage ist der Fokus der Plattform. Kennen sich Entwickler gut mit Docker aus und wird eine flexible Laufzeitumgebung benötigt, ist OpenShift sicher eine gute Wahl. Ist hingegen ein standardisierter Softwarestack wichtig und mögen sich die Entwickler nicht selber mit Containerkonfigurationen herumschlagen, dürften die anderen Plattformen eher bevorzugt werden. Vor allem Cloud Foundry und Heroku haben ein höheres Abstraktionslevel, so dass Deployment und vor allem das Anbinden von Datenservices konsistent und einfach ist. OpenShift und auch die App Engine dagegen sind etwas näher an einem CaaS (Container as a Service wie Kubernetes), mit dem Vorteil, dass der Build und das Deployment von Applikationen freier gestaltet werden können. So erlauben diese Plattformen auch, dass ein Applikationscontainer persistenten Diskspeicher haben darf, während Cloud Foundry und Heroku dies nicht zulassen.

Public Cloud Angebote

Will man Cloud Foundry oder OpenShift nicht on-premise verwenden, spielt auch der konkrete Anbieter eine Rolle. Deshalb werden im folgenden die Plattformen APPUiO, Red Hat (beide OpenShift), Pivotal und Swisscom (beide Cloud Foundry) mit der App Engine und Heroku verglichen.

Technologien

Sämtliche Plattformen bieten Unterstützung für die Programmiersprachen Java, PHP, Python, Node.js und Ruby, und unterstützen zusätzlich weitere individuelle Sprachen. Zudem erlaubt OpenShift den Entwicklern, selbstständig eine neue Sprachunterstützung hinzuzufügen. Auch der Rest der Laufzeitumgebungen ist auf sämtlichen Plattformen ähnlich, alles basierend auf Unix. Nur Cloud Foundry bietet auch Unterstützung für Windows Knoten an.

Pivotal CF Swisscom CF Red Hat OpenShift APPUiO OpenShift Google App Engine Heroku
Go ok ok ok ok
Scala ok
Clojure ok
.NET ok ok ok ok ok
Perl ok ok

Unterstützte Programmiersprachen zusätzlich zu Java, PHP, Python, Node.js und Ruby.

Die Auswahl der verfügbaren Datenservices ist von PaaS zu PaaS verschieden. Die OpenShift Installationen haben eigentlich gar keine Datenservices wie die anderen Plattformen, sie stellen lediglich fertige Container Images zur Verfügung, die auf der Plattform aber selber installiert und betrieben werden müssen. Bei OpenShift werden Services deshalb auch oft extern betrieben und die Zugangsdaten in der Plattform zur Verfügung gestellt. OpenShifts Abhängigkeit zu Red Hat ist offensichtlich, so dass die bereitgestellten Service Container oft Red Hat Produkte sind. Ähnlich verhält es sich bei den Pivotal Webservices, bei denen mehrere Services speziell das Spring Framework unterstützen, welches von Pivotal weiterentwickelt wird. Pivotal ist der grösste Contributor von Cloud Foundry, weshalb Spring Entwickler allgemein bei Cloud Foundry gute Integrationsmöglichkeiten haben. Die Cloud Foundry Plattform von der Swisscom ist ansonsten relativ beschränkt, was die Serviceauswahl im Marktplatz angeht.

Pivotal CF Swisscom CF Red Hat OpenShift APPUiO OpenShift Google App Engine Heroku
Datenbanken MySQL, Postgre, MongoDB, Redis MariaDB, MongoDB, Redis MariaDB, MySQL, Postgre, MongoDB, Redis, JBoss Data Grid MariaDB, MySQL, Postgre, MongoDB, Redis, JBoss Data Grid Cloud SQL, Cloud Datastore, Bigtable (HBase) MariaDB, MySQL, Postgres, MongoDB, Redis
Weitere Services Elasticsearch, RabbitMQ, … ELK, RabbitMQ JBoss Middleware, … JBoss Middleware, … BigQuery, Pub/Sub, Dataproc, … Elasticsearch, RabbitMQ, Kafka, …

Unterstützte Datenservices

Preismodell

Es ist schwer, die Preismodelle miteinander zu vergleichen. Vor allem die oben genannten Datenservices können kaum fair verglichen werden, da einige skalierbar sind, andere hingegen produktiv gar nicht empfohlen werden, oder auch der Support unterschiedlich ist. Verschiedene Support- und Betriebsbedingungen gibt es auch bei den Applikationen.

  • Appinstanzen sind am günstigsten bei Red Hat OpenShift, Pivotal Webservices und Swisscom. Für vier Instanzen und insgesamt 2GB RAM werden beispielsweise ca. 50 CHF pro Monat veranschlagt. Bei Red Hat ist sogar noch Diskspeicher dabei. Services wie zum Beispiel MongoDB sind bei der Swisscom aber teuer, so dass dieser Anbieter insgesamt trotzdem im höheren Preissegment sein dürfte.
  • Die anderen Anbieter verlangen für dieselben Instanzen ca. zwei- bis dreimal so viel, dafür ist beispielsweise die NoSQL Datenbank bei Google so billig, dass gewisse Szenarien mit der App Engine trotzdem am billigsten sein könnten. Auch die anderen beiden Anbieter kommen bei den Datenservices teilweise günstiger weg.

Fazit

Es gibt eine Vielzahl an Merkmalen, die bei der Evaluierung einer PaaS zu beachten sind. Dadurch ist es nicht möglich, eine einzige Empfehlung zu geben. Grundsätzlich sollte vor der Evaluierung geklärt werden, was die wichtigsten Anforderungen an die PaaS sind. Die Anforderungen müssen unbedingt priorisiert werden, da es keine eindeutige Wahl geben wird, die alle Anforderungen am besten erfüllt.

Im Folgenden gebe ich eine kurze Entscheidungsgrundlage. Sie ersetzt eine richtige Evaluierung im konkreten Kontext nicht, soll aber eine Idee geben, aus welchen Gründen welche Plattform empfohlen werden kann.

  • Open Source: Soll die Plattform nicht bei einem Cloud Anbieter bezogen werden, sondern möchte man selber eine Plattform betreiben (lassen)? Ist es wichtig, nicht von einem Anbieter abhängig zu sein, sondern muss es möglich sein, den Anbieter zu wechseln, ohne dass eine neue Technologie erlernt werden muss? Falls eine dieser Fragen mit “Ja” beantwortet wird, ist die Frage nur noch, ob Cloud Foundry oder OpenShift, und der nächste Punkt kann übersprungen werden.
  • Neuentwicklung oder Migration: Wird die Plattform verwendet, um extra für PaaS entwickelte Applikationen zu betreiben? D.h. es ist kein Problem, proprietäre Services zu verwenden? Dann kann ein Angebot wie die Google App Engine oder entsprechendes von Amazon oder Microsoft am effizientesten und günstigsten sein. Und sollten die Vorgaben der Plattform an die Laufzeitumgebungen zu strikt sein, kann immer noch auf ein Container-basiertes System wie bspw. Kubernetes bei Google ausgewichen werden.
    Sind die proprietären Serviceangebote von Google ein No-Go, zum Beispiel weil auch bestehende Applikationen auf die Plattform migriert werden sollen, dürfte Heroku eine gute Alternative sein. Bei Heroku gilt es vor allem den grossen Marktplatz mit all den Datenservices herauszustreichen, welcher den Entwicklern grösstmögliche Flexibilität gibt. Dies kann allerdings auch gefährlich sein, da Datenservices, welche nicht von Heroku betrieben werden, zu grosser Latenz führen können.
    So oder so sind natürlich Cloud Foundry- oder OpenShift-basierte Angebote auch ohne Open Source Argument konkurrenzfähig. Hier könnte auch der Ort der Cloud ein Vorteil bieten, da Swisscom und APPUiO je eine Plattform in der Schweiz anbieten.
  • OpenShift und Cloud Foundry: Beide Technologien haben Vor- und Nachteile. Grundsätzlich setzt OpenShift eher auf Container Deployment (Kubernetes), Cloud Foundry klassisch auf Source Code Deployment, obwohl Docker Container mittlerweile auch unterstützt werden. Ich denke aber auch, dass eine Evaluation von der Grösse der nötigen Plattform abhängt. Ein OpenShift Cluster kann mit weniger als zehn VMs aufgesetzt werden, während ein hochverfügbares Cloud Foundry über zwanzig benötigt. Deshalb muss man schon etliche Apps betreiben wollen, damit ein selbst gehostetes Cloud Foundry Sinn macht. Auch lässt sich Cloud Foundry mit BOSH beliebig hochskalieren, während bei OpenShift die Skalierung der Plattform selber nicht automatisch abläuft. Deshalb ist der Betrieb einer eigenen Cloud Foundry Plattform nur grossen Organisationen zu empfehlen, der Betrieb von OpenShift auch kleineren.
    Cloud Foundry mit seiner Abstraktion von Organisationen zielt darauf ab, dass die Plattform für mehrere von sich unabhängigen Entwicklungsorganisationen betrieben wird. Auch der Service Marktplatz macht nur Sinn für grosse Plattformen, da neben Datenbanken und anderen Services auch noch Service Broker betrieben werden müssen. Dafür braucht es dann eben wirklich keine manuellen Prozesse mehr, um ein Softwareprojekt aufzusetzen oder live zu gehen.

Ich hoffe, ich konnte Ihnen sowohl aufzeigen, auf was bei einer Evaluation des richtigen PaaS geachtet werden sollte, wie Ihnen auch einige wichtige Technologien näher bringen. Falls Sie sich für dieses Thema weiter interessieren, können Sie mich gerne per E-Mail kontaktieren.

Kommentar verfassen