SaaS-Modernisierung mit Amazon EKS, Teil 1 Vom Lizenz- zum SaaS-Angebot in der Cloud

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Amazon Web Services Germany GmbH

Softwarehersteller mit erfolgreichen Lizenzprodukten denken immer häufiger über die Portfolioerweiterung um ein SaaS-, sprich Software-as-a-Service-Angebot nach. In dieser Kurzserie sehen wir uns an, wie sich das praktisch realisieren lässt.

SaaS-Angebote sind über die Jahre immer populärer geworden. Kunden schätzen dabei, dass der Hersteller die Verantwortung für den Betrieb der Software übernimmt. Darüber hinaus macht SaaS das eigene Produkt attraktiv für neue Zielgruppen, die zum Beispiel kein Budget für hohe Gebühren einer Jahreslizenz haben.

Doch was bedeutet SaaS eigentlich? Muss ich hierzu meine Anwendung so betreiben, dass sie über das Internet verwendet werden kann? Ist meine Anwendung dann SaaS, wenn der Kunde sie nicht mehr selbst betreibt? Habe ich ein SaaS-Angebot, wenn meine Anwendung mandantenfähig ist?

All das sind typische Eigenschaften von SaaS, sie sind jedoch weder notwendige noch hinreichende Kriterien eines SaaS-Angebots. Statt eine Definition zu finden, schauen wir auf zwei wichtige Vorteile für Kunden, die mit dem Umstieg von Lizenz- auf SaaS-Produkten einhergeht:

• 1. Die Time-to-Value für den Nutzer einer Softwarelösung wird minimiert – er registriert sich, erhält Zugangsdaten und kann den eigenen Mandanten der Software in kürzester Zeit nutzen.

• 2. Der Kunde konsumiert einen Service – er muss weder Infrastruktur noch Erfahrungen im Betrieb der Software besitzen.

Daraus lassen sich für Hersteller Anforderungen an die Bereitstellung und den Betrieb einer SaaS-Lösung ableiten:

Für eine niedrige Time-to-Value muss die Bereitstellungszeit minimiert werden. Das bedeutet, Software-Hersteller müssen ihr Produkt soweit standardisieren, dass jeder Mandant auf demselben Code-Stand basiert, um den Automatisierungsgrad bei der initialen Bereitstellung maximieren zu können.

Kundenspezifika müssen durch Konfiguration erfolgen und der Kunde sollte befähigt sein, diese Konfiguration selbst anzupassen. Diese Standardisierung ist ebenfalls für die Bereitstellung der Software als Service wichtig. Je weniger Abweichungen zwischen den einzelnen Mandanten in der Software existieren, desto geringer ist die Komplexität im Betrieb.

Anforderungen an eine SaaS-Umgebung

Ist die neue SaaS-Lösung dann erfolgreich und zieht neue Kunden an, steht der SaaS-Anbieter vor der Herausforderung, seine Infrastruktur mit dem steigenden Bedarf zu skalieren. Darüber hinaus muss die Anwendung im Tagesverlauf oft hohe Lastspitzen auffangen können. Und natürlich muss die Anwendung außerhalb der Hauptnutzungszeiten verfügbar sein, gleichzeitig sollen in diesen Zeiten die Infrastrukturkosten aber minimiert werden.

Statt Rechenzentren zu betreiben und nach Erwartungen zum Kundenwachstum mit Vorlauf zu erweitern, entscheiden sich Softwarehersteller deshalb meist dazu, ihr SaaS-Angebot in der Cloud aufzubauen. Infrastruktur kann automatisiert provisioniert werden, um einem steigenden Bedarf zu begegnen. Überflüssige Kapazitäten lassen sich genauso schnell wieder abbauen, um die Betriebskosten zu reduzieren.

Bei Modernisierungsprojekten wählen Softwarehersteller oft Container als Betriebsumgebung. Sie bieten den Vorteil, dass die Modernisierung mit einem Re-Platforming-Ansatz oft mit geringen Aufwänden begonnen werden kann. Die Anwendung wird zunächst containerisiert, was in vielen lediglich Fällen bedeutet, dass in einem Dockerfile die Laufzeitumgebung beschrieben und die Konfiguration herausgezogen wird.

Dies ermöglicht es, dynamische Parameter zur Laufzeit über Umgebungsvariablen oder Konfigurationsdateien zu setzen. Die Anwendung wird dadurch portabel, da das Container-Image die notwendige Laufzeitumgebung und alle Abhängigkeiten enthält. Auch werden viele betriebliche Abläufe, wie die Aktualisierung durch das Austauschen des Container-Images, standardisiert.

Um Container im großen Umfang produktiv zu betreiben, muss jedoch eine Container-Plattform eingesetzt werden, die zum Beispiel Deployment-Logik wie Blue/Green oder Funktionen wie Service Discovery übernimmt. Eine weit verbreitete Lösung ist in diesem Bereich das zur Cloud Native Computing Foundation (CNCF) gehörende Kubernetes.

Die Container-Plattform Kubernetes

Kubernetes ist eine Open-Source-Software, mit der containerisierte Anwendungen skalierbar bereitgestellt werden können. Dazu verwaltet Kubernetes ein Cluster von Compute-Ressourcen und abstrahiert die unterliegende Hardware. Es bietet Prozesse zum Deployment, der Wartung sowie Skalierung von beliebigen containerisierten Anwendungen im Cluster.

Diese Orchestrierung ermöglicht es SaaS-Anbietern Anwendungskomponenten unterschiedlicher Mandanten auf gemeinsam genutzten Compute-Ressourcen zu betreiben. Dadurch steigt die Auslastung der unterliegenden Hardware und der Betrieb wird kosteneffizienter als dies bei der Bereitstellung von dedizierter Hardware pro Mandanten der Fall wäre.

Auch wenn Kubernetes den Betrieb von SaaS-Lösungen vereinfachen kann, ist die Plattform selbst komplex und erfordert einen hohen Grad an Erfahrung im produktiven Betrieb. Gerade bei Softwareherstellern, die Lizenzprodukte vertrieben und keine eigene Betriebserfahrung gesammelt haben, kann dies zu großen Verzögerungen im Aufbau eines SaaS-Angebots führen.

Der Betrieb einer Container-Plattform selbst ist darüber hinaus kein Alleinstellungsmerkmal eines SaaS-Anbieters. Entscheidet sich ein Softwarehersteller für den Betrieb in einer Kubernetes-Umgebung in der Cloud sollte er die verwaltete Kubernetes Services des Cloud-Providers in Betracht ziehen.

Ein Kubernetes Cluster lässt sich grob in zwei Teile aufteilen. Die Control-Plane enthält Software-Komponenten zum Betrieb des Clusters. Dies umfasst die Kubernetes API zur Veränderung des Cluster Zustands von außen (beispielsweise durch Administratoren), Controllern zur Verarbeitung von Events im Cluster (beispielsweise Skalierung) und einem Key-Value-Store zur Verwaltung des Zustands im Cluster (etcd). Die Komponenten der Control-Plane müssen nicht nur hochverfügbar aufgesetzt werden, sie müssen mit steigender Nutzung auch skaliert und unterbrechungsfrei gewartet werden.

Der zweite Teil eines Kubernetes Clusters ist die Data-Plane. Dies sind die Knoten des Clusters, auf denen Kubernetes Container einer Workload platzieren kann. Neben einer Container-Runtime wie containerd sind mit dem kubelet ein Agent zur Kommunikation mit der Control-Plane sowie mit kubeproxy ein Proxy für den Netzwerkverkehr auf allen Nodes der Data-Plane zu finden.

Amazon Elastic Kubernetes Service

Amazon Web Services (AWS) bietet mit Amazon Elastic Kubernetes Service (EKS) eine von der CNCF zertifizierte Kubernetes-Distribution als verwalteten Service an. Diese Zertifizierung bedeutet, dass EKS den festgelegten Standards folgt und diese Kompatibilität bei Änderungen geprüft wird. Damit ist eine Anwendung, die in EKS läuft, auch in anderen CNCF zertifizierten Kubernetes-Distributionen lauffähig.

EKS stellt die Kubernetes Control Plane als verwalteten Service bereit. Nutzer sind damit für den Großteil der Komponenten aus dem oberen Architekturdiagramm nicht mehr verantwortlich, die Cluster-Architektur vereinfacht sich. Betriebliche Aufgaben rund um die Data Plane lassen sich zudem mit Managed Node Groups und AWS Fargate reduzieren.

AWS arbeitet sehr eng mit der Open Source Community und ist aktiver Maintainer von Kubernetes-Plugins sowie Kontributor für das Hauptprodukt selbst. Weitere Informationen zum Open Source Engagement von AWS rund um Kubernetes und Container können in der öffentlichen Roadmap auf GitHub gefunden werden.

Ein EKS Cluster lässt sich auf unterschiedliche Arten erzeugen. Zunächst kann natürlich die AWS Konsole verwendet werden, um ein Cluster zu konfigurieren. Ebenso ist es möglich, diese Schritte in einem Skript mit Hilfe der AWS CLI zu automatisieren. Best Practice ist jedoch Infrastructure-as-Code und damit eine deklarative Beschreibung des Clusters.

Mit CloudFormation, dem AWS Cloud Development Kit (CDK) oder Tools von Drittanbietern wie Pulumi oder Terraform gibt es eine Reihe von Optionen, Infrastrukturcode zu schreiben. Mit eksctl bieten GitOps-Erfinder Weaveworks und AWS aber auch ein EKS-spezifisches Open Source Tool an.

Mit eksctl wird die Menge an Infrastrukturcode, die für das Aufsetzen eines EKS Clusters geschrieben werden muss, stark reduziert. Dies wird durch EKS-spezifische Standards für Infrastrukturkomponenten ermöglicht. Der EKS Workshop bietet eine gute Übersicht und Einführung in die Installation und Verwendung des Tools.

Mit eksctl definieren wir das EKS Cluster in einer YAML Datei. Die folgenden Zeilen Code genügen, um mit eksctl ein hochverfügbares EKS Cluster über drei Verfügbarkeitszonen aufzusetzen:

Speichern wir diese YAML Datei als cluster.yaml genügt ein Aufruf von …

… um ein EKS Cluster mit der vorangestellten Architektur im AWS Account anzulegen.

Ein Blick in den von eksctl angelegten CloudFormation Stack zeigt, wieviel Aufwand für die Definition von Infrastruktur-Code vom Tool übernommen wird. Auch wenn wir nur eine Managed Node Group von EC2 Instanzen für die Data Plane definiert haben, wird ein CloudFormation Stack für die Basis-Infrastruktur wie beispielsweise den Netzwerkkomponenten angelegt.

Das eksctl Tool kann ebenfalls verwendet werden, um die Ressourcen wieder zu löschen:

Die Container Registry

Eine weitere zentrale Komponente für jede Container-Plattform ist die Container-Registry. Hier ist der Speicherort für Container-Images, die zur Instanziierung der Anwendungskomponenten durch die Plattform geladen werden. Kubernetes kann mit einer Vielzahl von Container-Registries betrieben werden. Jeder AWS Account besitzt bereits eine private Registry bereitgestellt durch den Service Amazon Elastic Container Registry (ECR). Er ist ideal dafür geeignet Container Images für EKS vorzuhalten.

Da ECR ein verwalteter Service ist, erhält der Nutzer eine skalierende und hochverfügbare Lösung. ECR bietet darüber hinaus noch die Möglichkeit Container-Images beim Hochladen auf Sicherheitslücken zu prüfen. So lässt sich zum Beispiel verhindern, dass Images mit bekannten kritischen Sicherheitslücken in Produktion ausgerollt werden.

Jeder AWS Account verfügt über eine AWS Elastic Container Registry, in der Repositories für die einzelnen Komponenten der Anwendung angelegt werden können. Dies ist denkbar einfach, wie im Bild zu sehen ist. Über die AWS Konsole lässt sich mit wenigen Klicks ein Repository anlegen, das Container Images verschlüsselt und unveränderlich ablegt. Darüber hinaus bietet ECR mit der „Scan on Push“ Funktion an jedes Image beim Hochladen auf Common Vulnerabilities and Exposures (CVEs) des „CoreOS Claire“-Projekts zu prüfen.

Nachdem das Repository erstellt wurde, können die Instruktionen zur Verwendung in der Detailansicht gefunden werden. Im Rahmen dieser Artikelserie zeigen wir Beispiele auf, wie Lösungen für typische Herausforderungen im Aufbau einer SaaS-Lösung in EKS implementiert werden können. Die Konzepte hinter den einzelnen Beispielen lassen sich in der Regel jedoch auf andere Laufzeitumgebungen, wie zum Beispiel Serverless Compute übertragen. Im nächsten Teil der Serie betrachten wir zunächst ein fundamentales Konzept in Multi-Tenant-Environments: die SaaS-Identität.

* Markus Kokott arbeitet als Solutions Architect bei Amazon Web Services. Er hilft Softwareherstellern dabei ihre Prozesse und Produkte zu modernisieren und damit fit für die Cloud zu machen. Technologisch interessiert sich Markus insbesondere für die Bereiche DevOps und Container.

(ID:47734418)