Seite 3: Die Bewertungskriterien

Inhaltsverzeichnis

Die vier Bewertungskriterien Kosten, Flexibilität, Komplexität und Geschwindigkeit sind allgemein und relevant genug, um die Basis der Bewertungsmatrix zu bilden. Sicherlich sind in einigen Fällen auch noch mehr oder andere Kriterien passender. Mit den vier hier gewählten Kriterien ist aber eine erste, gute Objektivierung möglich. Schließlich stehen die vier Kriterien sowohl für ganz unterschiedliche Bewertungsaspekte, etwa Organisation, Prozess und Technik, als auch teilweise diametral zueinander, was zu einer besseren Ausleuchtung des Lösungsraums beiträgt.

An erster Stelle stehen die Kosten, die sich in OpEx- und CapEx-Kosten unterscheiden lassen. Die OpEx-Kosten sind die Kosten, die bei der Nutzung der Cloud-Services entstehen, um die Laufzeitumgebung bereitzustellen. Die OpEx-Kosten sind transparent und können für jeden Cloud-Provider bestimmt werden. Allgemein gilt, dass die OpEx-Kosten um so höher ausfallen, je mehr Cloud-Services zum Einsatz kommen. Die CapEx-Kosten werden nicht berücksichtigt, da die Cloud und die Cloud-Services nicht selbst aufgebaut werden sollen.

Die Komplexität lässt sich mit der Kompetenz und den Experten gleichsetzen, die benötigt werden, um die Laufzeitumgebung mit dem gewählten Cloud-Ansatz zu konfigurieren. Je mehr Cloud-Services Verwendung finden, desto geringer ist die Komplexität, da wenig individuell aufgebaut werden muss. Natürlich wird auch für die Konfiguration der Cloud-Services Kompetenz benötigt, allerdings viel weniger, als wenn die Cloud-Services selbst aufzubauen wären.

Proportional zur Komplexität verhält sich die Flexibilität. Sie repräsentiert die Autonomie der IT bei der Gestaltung der Laufzeitumgebung, etwa der Auswahl spezieller Prozessortypen. Oder die Flexibilität, die Versionen, die Updates oder die Konfiguration der verwendeten Software selbst bestimmen zu können.

Die Geschwindigkeit ist ein Maß dafür, wie schnell man die Laufzeitumgebung bereitstellen kann. Je mehr Cloud-Services einsetzbar sind, desto schneller kann die Laufzeitumgebung zur Verfügung stehen, da keine individuellen Aufbauten notwendig sind.

Für jedes Bewertungskriterium lässt sich nun eine relative Einschätzung hinsichtlich des verwendeten Cloud-Ansatzes von IaaS bis SaaS für den Aufbau der Laufzeitumgebung vornehmen. Die gewählten Bewertungsstufen sind hoch, mittel und niedrig (Tabelle 2), aber beliebig durch andere wie T-Shirt-Größen oder Farben ersetzbar.

Ansatz	Kosten	Komplexität	Flexibilität	Geschwindigkeit
IaaS	niedrig	hoch	hoch	niedrig
CaaS	niedrig	mittel	mittel	mittel
PaaS	niedrig	niedrig	niedrig	hoch
FaaS	niedrig	niedrig	niedrig	hoch
SaaS	entfällt	entfällt	entfällt	entfällt
Tabelle 2: Bewertungskriterien

Der IaaS-Ansatz

Der Infrastructure-as-a-Service-Ansatz kümmert sich ausschließlich um Computer und Netzwerk, wie in Abbildung 1 dargestellt. Er ist der älteste Cloud-Ansatz. Die Kosten sind niedrig, weil sich nur wenige Services für den Aufbau der Laufzeitumgebung nutzen lassen. Amazon liefert dafür etwa EC2 sowie Networking, VPN, Routing, Route53 und Security. Die Komplexität des IaaS-Ansatzes ist allerdings hoch, denn Containerisierung, Scheduling und Orchestrierung, Clustering und Service-Mesh müssen Unternehmen komplett selbständig aufbauen und pflegen. Als Container-Techniken lassen sich dann beispielsweise Docker, Docker-Swarm oder Kubernetes und das Service-Meshes wie Linkerd oder Istio umsetzen. Der individuelle Aufbau benötigt Zeit, was sich negativ auf die Geschwindigkeit auswirkt. Die Belohnung für die Investition ist eine hohe Flexibilität, denn die verwendeten Produkte sind passgenau ausgesucht, konfiguriert und aktualisiert.

Der CaaS-Ansatz

Container as a Service liefert, wie Abbildung 1 darstellt, zusätzlich zu Computer und Netzwerk auch Betriebssystem und Container. CaaS bietet damit alles rund um die Container-Techniken an, also Containerisierung, Scheduling und Orchestrierung sowie Clustering. Der CaaS-Ansatz ist ein junger Cloud-Ansatz. Erste Cloud-Services wurden 2015 von Unternehmen wie Cycle bereitgestellt.
Amazon bietet für die Anwendung dieser Container-Techniken die Services Elastic Container Services (ECS), Elastic Container Repositories (ECR) und Elastic Kubernetes Services (EKS). Zwar bringen die genannten Dienste wichtige Mesh-Features wie Load Balancer, Proxy oder API Gateway mit, allerdings sind sie in der Regel nicht ausreichend und man muss sie um Monitoring, Tracing oder Metriken ergänzen. Mit dem Produkt AWS App Mesh lassen sich die Container-Services um ein Service-Mesh samt Monitoring, Traffic-Control und anderer Features ergänzen oder ersetzen.

Trotz des CaaS-Komforts steigen die Kosten gegenüber dem IaaS-Ansatz nicht. Denn für die Nutzung der Container-Services stehen die gleichen Kosten wie für IaaS auf der Rechnung. Die Komplexität sinkt wiederum beträchtlich, denn die Produkte, von Docker über Kubernetes bis Istio, müssen Firmen nicht mehr selbst aufsetzen und pflegen. Der Komfort schmälert auch die Flexibilität nicht wesentlich, denn es lassen sich alle Konfigurationen, APIs und Tools wie Command Line Interpreter der darunter liegenden Open-Source-Produkte verwenden. Ebenso lässt sich Einfluss auf die Versionen und Updates nehmen, sodass neue Features immer zur Verfügung stehen. Zudem profitiert das Kriterium der Geschwindigkeit, weil sich die Services recht einfach aufsetzen lassen.

Der PaaS-Ansatz

Die Application Runtime, Tools sowie Bibliotheken sind die Domäne der Platform as a Service. Den PaaS-Ansatz gibt es bereits seit 2009. Pioniere sind die Open-Source-Softwareentwickler von Cloud Foundry die später unter der Schirmherrschaft der Cloud Foundry Foundation von Unternehmen wie IBM Unterstützung erhielten.

Dieser Ansatz kapselt das Thema Container-Techniken vollständig. Der Microservice wird lediglich noch in ein geeignetes Format überführt, in der Java-Welt beispielsweise als JAR oder WAR. Anschließend lässt er sich per API und mit einem CLI-Befehl in die Cloud übertragen und ausführen. Ein Zitat von Onsi Fakhouri, CTO von Pivotal, illustriert diese Einfachheit: “Here is my source code, run it on the cloud for me. I do not care how!” [4]

Die PaaS bringt in der Regel den Service-Mesh gleich mit. Beispielsweise liefert die Pivotal Cloud Foundry mit Istio einen Service-Mesh-Stack. Amazon stellt mit Beanstalk eine PaaS zur Verfügung, die auch Service-Mesh unterstützt. Man kann sie außerdem mit weiteren Services wie AWS App Mesh erweitern. Auch hier gilt: Trotz des PaaS-Komforts steigen die Kosten gegenüber des IaaS-Ansatzes nicht, weil für Beanstalk selbst keine zusätzlichen Kosten anfallen. Außer die, die für IaaS sowieso benötigt werden. Der PaaS-Ansatz reduziert die Komplexität stark und die Zeit bis zur Bereitstellung der Laufzeitumgebung sinkt deutlich.

Der einzige Nachteil ist, dass Flexibilität verloren geht. Lediglich über eine Konfigurationsdatei besteht noch partiell Einfluss auf die Infrastruktur. Auf die in Beanstalk verwendeten Produkte, Versionen und Updates haben die Unternehmen dann gar keinen Einfluss mehr.

Der FaaS-Ansatz

FaaS, Functions as a Servive oder auch Serverless Computing, adressiert Service-Mesh und Service-Events und ist der jüngste Ansatz unter allen anderen. Einer der Pioniere auf dem Gebiet ist AWS, die 2018 ihren ersten Cloud-Services mit AWS Lambda anbieten konnten. Dieser steht unter dem Motto "Run Code, Not Servers".

FaaS kapselt dazu die Container- und Service-Mesh-Techniken vollständig. Im Zentrum von FaaS steht die Ausführung einzelner Funktionen. Dabei nimmt der Service den Sourcecode der Funktion direkt entgegen und führt ihn aus. Die Funktionen lassen sich dann miteinander zu einer Anwendung vernetzen. Die Kommunikation zwischen den Services erfolgt über Service-Events.

Die Kosten mit dem Einsatz von Amazon Lambda steigen gegenüber Ansätzen wir IaaS, CaaS und PaaS. Neben den IaaS-Kosten fallen bei jedem Funktionsaufruf nämlich Kosten für die Ausführungszeit der Funktion an. Dafür sinkt die Komplexität, denn der Service kapselt die Laufzeitumgebung komplett. Selbst die Skalierung läuft automatisch ab. Damit konvergiert die Flexibilität gegen Null. Der Einfluss auf die für die Laufzeitumgebung verwendeten Produkte, Versionen oder Updates geht komplett verloren. Die Geschwindigkeit bleibt vergleichbar mit einem PaaS-Ansatz. So ist ein Beanstalk-Service genauso schnell eingerichtet wie ein Lambda-Service – die Installation und Ausführung der Anwendungen läuft über API- oder CLI-Befehle ab.

Der SaaS-Ansatz

Software as a Service liefert bereits fertige Applikationen und Services. Salesforce ist hier sicherlich als SaaS-Pionier zu bezeichnen. Das Unternehmen bietet vollständige Anwendungen aus verschiedenen Unternehmensbereichen, von Marketing bis Vertrieb, in der Cloud an. Im Kontext der Cloud-Native Architecture werden über SaaS-Ansätze auch APIs über beispielsweise REST oder GraphQL im Internet angeboten, die sich durch andere Apps oder APIs konsumieren lassen.

Das ist ein signifikanter Unterschied zu den anderen vier Cloud-Ansätzen. Denn im Gegensatz zu diesen liefert SaaS somit nicht nur die Laufzeitumgebung aus, sondern deren Anwendung gleich mit. Ein Vergleich mit den Alternativen ist dabei schwierig. Insbesondere erkennbar an den signifikant höheren Kosten, deren Großteil sich auf die fachliche Nutzung der Services zurückzuführen lässt und nicht auf die Kosten für die Bereitstellung der Laufzeitumgebung. Daher ist dieser Ansatz zwar in der Bewertungsmatrix aufgenommen, die Bewertung entfällt allerdings.