Cloud-Native oder Kubernetes-Native? Guideline für Ihre Architektur-Entscheidung

Alle Services managen lassen oder auf ein offenes System setzen? Beides hat Vor- und Nachteile. In diesem Artikel erfahren Sie, auf welche Strategie Sie beim Aufbau und der Weiterentwicklung Ihrer Systemlandschaft setzen sollten und warum.

Bevor wir loslegen, möchte ich diese beiden Begriffe so definieren, wie sie in diesem Artikel zu verstehen sind, denn beide lassen Interpretationsspielraum zu und natürlich ist auch Kubernetes selbst etwas Cloud-Native, aber darum soll es hier heute nicht gehen.

Cloud-Native soll in diesem Artikel alle Services beschreiben, die in verwalteter Form, also weitgehend Serverless, von verschiedenen Anbietern zur Verfügung gestellt werden, ohne, dass man mit der dahinter liegenden Server-Infrastruktur zu tun hat. Beispiele dafür sind z.B.: AWS Lambda, um Code-Schnipsel verschiedenster Sprachen ausführen zu können, AWS RDS, um eine SQL-Datenbank zu betreiben oder Microsoft Azure’s Visual Studio-Plattform, um Git-Repositorys und CI/CD-Pipelines zur Verfügung zu stellen.

Kubernetes-Native soll im Gegenzug Services beschreiben, die in einer Kubernetes-Umgebung betrieben werden, und von den Features profitieren, die ihnen diese K8S-Umgebung im Gegensatz zu einem klassischen Deployment auf virtuellen Maschinen oder Bare-Metal-Servern bietet.

Das ist natürlich eine elementare Frage und die Antwort muss eigentlich lauten: Ja! Natürlich wird man fast jede Infrastruktur und fast jedes Projekt auf beide Weisen und in beiden Umgebungen realisieren können. Die Frage ist: Sollte man?

Wie Sie sicher schon ahnen, ist die Antwort auf die Frage, welche Variante die richtige für Sie ist, ein klares „Kommt drauf an!“ - und genau darum geht es in diesem Artikel.

Die Prioritäten dürften bei den meisten Entscheidungsträger vergleichbar sein. Die wichtigsten Faktoren sind üblicherweise:

• Geschwindigkeit der Bereitstellung eines Projekts oder eines Service
• Initialkosten
• Laufende Kosten für den Betrieb
• Laufende Kosten für die Instandhaltung, Updates, Wartung und Weiterentwicklung
• Resilienz und Integrität: Wie stabil verhält sich das System im normalen Tagesgeschäft, aber auch unter Last?
• Performance: Wie sehen CPU-, Memory- und Storage-Footprint und damit die Kosten im Verhältnis zum geleisteten Feature-Set aus?
• Compliance, Datenschutz und Datensicherheit

Ich bin der für das Operating zuständige Vorstand der Esono AG mit Sitz in Freiburg und Berlin und verantworte Betrieb und Hosting für Projekte, die jährlich dreistellige Millionenbeträge für unsere Auftraggeber umsetzen. Mit ihnen zusammen planen und realisieren wir dabei die optimale Lösung für die jeweilige Anforderung. Wir erhalten zum aktuellen Zeitpunkt von keinem einzigen Hyperscaler, Cloud-Hoster oder Rechenzentrum Provisionen oder Rabatte für das Hosting oder die Vermittlung unserer Kunden und können so eine tatsächlich unabhängige Empfehlung im Sinne des Auftraggebers aussprechen.

Und genau so ist auch dieser Artikel geschrieben: ohne Sponsoring. Wir möchten hier Wissen und Erfahrung offen teilen. Wenn wir Sie dann im Nachgang bei einer entsprechenden Entscheidung beraten und begleiten dürfen - freut uns das natürlich umso mehr.

Die einfachste Form der Skalierung ist die vertikale: Sobald die bestehende Leistung nicht mehr ausreicht, spendiert man dem betroffenen Server einfach mehr CPU-Kerne, mehr RAM oder mehr Storage. Aus Sicht der Systeme, die darauf laufen, ändert sich dabei also erst einmal nicht viel. Normalerweise muss ihre Konfiguration nicht oder nur minimal angepasst werden. Diese Art der Skalierung ist also denkbar einfach: In Cloud-Native- und Kubernetes-Umgebungen auf virtuellen Maschinen ist das gewissermaßen per Knopfdruck erledigt. Auf Bare-Metal-Servern hingegen, muss die Hardware getauscht werden. Diese Art der Skalierung hat neben dem Vorteil der Einfachheit und der Kosteneffizienz aber entscheidende Nachteile: Zum einen ist sie durch maximale Ausbaustufen begrenzt, zum anderen trägt sie allein nicht zur Verbesserung der Ausfallsicherheit bei.

Erst die horizontale Skalierung hingegen ist das, was man klassischerweise unter „skalierbaren Systemen“ versteht. Hier werden mehrere Server parallel betrieben und übernehmen ähnliche oder auch gleiche Aufgaben. Das ermöglicht im Optimalfall eine relativ lineare Leistungssteigerung des Gesamt-Systems durch einfaches Zuschalten weiterer Maschinen. Gleichzeitig werden Ausfälle einzelner Maschinen erheblich tolerierbarer. Schlussendlich sollte eine horizontale Skalierung also immer den präferierten Weg darstellen.

Eine dynamische Skalierung erweitert eine horizontale dann primär um die Funktion der automatischen Zuschaltung weiterer Maschinen, z. B. sobald definierte Leistungsmetriken überschritten werden. Eine dynamische Skalierung ist also primär in Hosting-Umgebungen zu Hause, bei denen per API automatisch neue virtuelle Server zugeschaltet werden können, oder bei Cloud-Native-Systemanbietern, die je nach Service einfach immer mehr Leistung nach Bedarf anbieten und abrechnen.

Warum verwendet man dann nicht immer eine horizontale Skalierung? Glad you asked!

Die große Herausforderung bei der horizontalen Skalierung ist, dass auch die eingesetzten Softwarekomponenten dafür geeignet sein müssen. Das ist bei NoSQL-Datenbanken wie z.B.: OpenSearch oder Elasticsearch der Fall. Diese Datenbanken skalieren quasi von Haus aus problemlos horizontal. Anders sieht es bei relationalen Datenbanken wie MariaDB oder MySQL aus. Auch diese können horizontal skalieren, das setzt aber erheblich mehr Know-how beim Betreiber voraus.

Besonders spannend wird es im Regelfall dann, wenn mehrere solche Softwarekomponenten zusammenarbeiten müssen und horizontal skaliert werden sollen, womit wir auch direkt schon beim nächsten Punkt sind, nämlich:

Beispiel-Szenario: Ein erfolgreicher Online-Shop, der noch auf einem klassischen LAMP-Stack (also Linux, Apache, MySQL, PHP) betrieben wird, ist über die Jahre gewachsen und an die Grenzen seiner vertikalen Skalierbarkeit gestoßen und er soll außerdem eine höhere Ausfallsicherheit erhalten. Die Herausforderungen hier sind hauptsächlich:

• Sinnvolles Aufteilen der bestehenden Systemkomponenten in Container
• Orchestrierungs-Logik dieser Container definieren, z. B. über HELM-Charts
• Planung, welche Teile des Systems Node-spezifisch auf hochperformanten Dateisystemen laufen können und welche auf langsameren, aber dafür skalierten, geteilten Dateisystemen betrieben werden können
• Betrieb einer skalierten, redundanten relationalen Datenbank
• Etwaige Anbindung einer zusätzlichen, nicht relationalen Datenbank
• Etwaige Anpassungen am Code
• Weitere Schritte je nach Bestandssystem

Sind diese Punkte erledigt, bei denen wir Sie übrigens gerne unterstützen, ist das System startklar für eine horizontale Skalierung und damit für einen Kubernetes-nativen Betrieb.

Um ein System Cloud-Native zu machen, kann man jetzt noch einen Schritt weiter gehen und die einzelnen Container und Workload-Komponenten genauer untersuchen. Eventuell sind einzelne oder alle Teile auch über komplett gemanagte Services sinnvoll abbildbar.

Generell werden Bestandsprojekte eher selten zu 100 % in eine Cloud-Native-Anwendung konvertiert. Dies bleibt überwiegend neuen Projekten vorbehalten, bei denen zum Projektstart entschieden wird, ob sie primär auf Managed Services oder auf eigene Services setzen.

Essenziell ist: Je komplexer und größer ein System ist, umso schneller kann sich auch ein Hybrid-Modell aus Cloud- und Kubernetes-Native bezahlt machen, wenn man die am Markt verfügbaren Tools optimal einsetzt. Man sollte jedoch nicht versuchen, mit einer einzigen Lösung alle Aufgaben gleichzeitig zu erschlagen.

Wenn man alle anderen Faktoren einmal völlig fahrlässig außer Acht lässt, und auf die reine „Compute-Power pro Euro schaut“, dann hat ein einfaches Kubernetes -Hosting auf womöglich nur einer einzigen Bare-Metal-Maschine (also einem echten, physischen Server) die Nase natürlich meilenweit vorn. Bei der gerade angesprochenen „Compute-Power pro Euro“ hat man dann zwischen einem günstigen Hardware-Hoster und einem großen Hyperscaler schnell mal einen Faktor von 10 erreicht. Und ob ich für den Betrieb meines Systems nun 1.000 € / Monat ausgebe oder doch 10.000 € interessiert die Controlling-Abteilung auch in größeren Unternehmen immer noch brennend. Aber:

Einerseits ist dieser Preisbereich eine heftige Ansage – andererseits wird niemand eine unternehmenskritische Anwendung auf einem einzigen Hardware-Node betreiben wollen, denn es ist keine Frage, ob, sondern nur, wann dieser ausfallen wird.

Am anderen Ende der Skala stehen leistungsfähige virtuelle Maschinen großer Hyperscaler wie AWS, Azure oder Google, die auf äußerst ausfallsicherer Hardware betrieben werden. Selbst im Falle eines Ausfalls können diese sofort mit den gleichen Storage-Daten wieder auf anderer Hardware hochgefahren werden.

Das klingt nicht nur verführerisch – das ist auch einfach richtig gut. Aber eben nicht billig. Die Herausforderung ist, den Sweetspot zwischen diesen beiden Varianten zu finden.

Dazu gesellen sich obendrein noch die Cloud-Native-Services, die eine eigene Spezies bilden: Sie sind immer verfügbar, müssen nicht gewartet werden, skalieren automatisch und sind normalerweise sehr sicher. Dafür lösen sie meist recht spezifische Aufgaben auf sehr fest definierte Weise. Wenn die auf den eigenen Anwendungsfall passt, kann das eine perfekte Lösung sein, die sowohl Setup- als auch Betriebskosten spart – oder im Gegenteil, wenn sie eben nicht auf den eigenen Anwendungsfall passen.

Man verschiebt die Verantwortung für eine hohe Systemverfügbarkeit also weg von der Hardware, hin zur Software und generiert damit günstigere Betriebskosten bei vergleichbaren Service-Levels.

Beispiel: Sie müssen von 10 Millionen Bildern, die auf einem S3-Storage liegen „On Demand“ Thumbnails erstellen. An manchen Tagen werden nur 10 davon angefragt und an anderen Tagen eine ganze Million. In diesem Fall ist z. B. eine AWS Lambda-Funktion vermutlich die perfekte Lösung, die praktisch keine Bereitstellungs- und Betriebskosten verschlingt. Wenn sie hingegen jeden Tag immer 10 Millionen neue Bilder zu Thumbnails umrechnen müssen, sind sie mit einem eigenen VM-Server unter Umständen erheblich besser und günstiger bedient.

Das Interessante: Durch verschiedene Systemarchitekturen, wie z.B. dem oben beschriebenen, horizontalen Skalieren via Kubernetes, rücken auch preislich deutlich attraktivere Hosting-Angebote plötzlich wieder in den Fokus, da eine tendenziell schlechtere Verfügbarkeit einzelner Maschinen durch eine redundantere Systemarchitektur aufgefangen wird. Man verschiebt die Verantwortung für eine hohe Systemverfügbarkeit also weg von der Hardware, hin zur Software und generiert damit günstigere Betriebskosten bei vergleichbaren Service-Levels.

Gehen wir einmal davon aus, dass Sie die perfekte Aufteilung zwischen Cloud-Native Workloads, Workloads auf VMs und Workloads auf Bare-Metal-Maschinen gefunden haben. Als perfekt definieren wir hierbei die optimale Balance der Faktoren Preis, Leistung und Zuverlässigkeit für jede einzelne Workload.

Gibt es dann trotzdem noch einen Grund, von dieser Lösung abzuweichen? Ja! Denn diese Faktoren allein greifen zu kurz, wenn man dabei das Ressourcen-Management eigener und externer Teams aus den Augen verliert.

Eine Lösung abseits der oben beschriebenen, optimalen technischen Balance mag Sinn ergeben, wenn sie das Fähigkeiten-Spektrum der eigenen Belegschaft besser widerspiegelt. Ein Team, das sich bei der Lösung von IT-Anforderungen beispielsweise in der Cloud-Native-Umgebung von AWS Lambda, SQS, SNS und DynamoDB zu Hause fühlt und diese damit in kürzester Zeit umsetzen kann, profitiert von einer schnellen Entwicklungszeit. Außerdem muss sich dieses Team kaum oder gar nicht mit den Themen Skalierung, Serverwartung und Verfügbarkeit auseinandersetzen. Die im Vergleich zu anderen Lösungen ggf. höheren Betriebskosten können so an anderer Stelle eingespart werden und letztlich eine perfekte Gesamtlösung darstellen.

Im Gegenzug wird ein Team, das in der klassischen Softwareentwicklung und bei dem Betrieb von Container-Workloads beheimatet ist, zunächst erhebliches Know-how aufbauen müssen, wenn es Projektentwicklung auf Basis von Cloud-Native-Lösungen in sein Portfolio aufnehmen möchte.

Cloud-Native- und Kubernetes-Native Lösungen binden beide sehr breite und tiefe Wissens-Ressourcen im Unternehmen. Die Cloud-Native Welt erweckt dabei den Anschein, dass sie tendenziell einfacher vollständig erfassbar ist, denn es gibt eine endliche Anzahl von Services und Funktionsweisen, die vom Anbieter angeboten werden. Schaut man jedoch genauer hin, wird auch hier klar: Wo vorgefertigte Lösungen nicht mehr passen, wird natürlich auch in Cloud-Native-Umgebungen auf klassische Programmiersprachen oder Managed-Kubernetes-Cluster zurückgegriffen.

Fazit: Man sollte also eher ganze Know-how-Bereiche voneinander abgrenzen:

• Mit Cloud-Native-Umgebungen spart man sich tendenziell Großteile des Operating Know-hows auf Kosten des Betriebsbudgets.
• Mit Kubernetes-Native-Umgebungen spart man sich tendenziell die Bindung an einen bestimmten Anbieter und Betriebsbudget auf Kosten des benötigten Know-hows, das aufgebaut oder eingekauft werden muss.

Diese Frage ist im Gegensatz zu den anderen relative eindeutig zu beantworten: Ja, es gibt einen starken Vendor Lock-In, also eine schwer umkehrbare Bindung an einen bestimmten Anbieter, je anbieterspezifischer die verwendeten Services sind.

• Ein Beispiel für einen leicht anbieterspezifischen Service, der aber so gut wie keinen Vendor Lock-In generiert, ist der Relational Database Service (RDS) von Amazon Web Services (AWS). Hier kann z. B. eine MySQL-kompatible Datenbank betrieben werden, die ausgezeichnete zusätzliche Services in puncto Backup, Wiederherstellung und Fail-Over-Bertrieb bereitstellt. Sie kann aber bei einem Anbieterwechsel durch eine normale MySQL oder MariaDB-Datenbank mit entsprechenden Zusatz-Services ausgetauscht werden.

• Schwieriger wird es hingegen, wenn man etwa zahlreiche AWS-Accounts betreibt, die jeweils über SQS-Queues, API-Gateways, DynamoDB-Datenbanken, Lambda-Funktionen und andere AWS-spezifische Services verfügen. Eine solche Infrastruktur in z. B. einen Kubernetes-Cluster zu migrieren und damit anbieterunabhängig betreiben zu können, wird einen größeren Umbau und damit ein schwergewichtiges IT-Projekt bedeuten.

Die Esono AG hat als eines der ersten Unternehmen bereits 2007 auf das Deployment von Workloads in die Cloud gesetzt und parallel dazu weiterhin Bare-Metal- und virtuelle Maschinen für seine Systeme eingesetzt.

Daraus resultieren zahlreiche Erkenntnisse und Best-Practices, von denen wir Ihnen einige wertvolle in diesem Artikel vorstellen wollten.

Letztlich hängt es von Ihrem konkreten Projektvorhaben und Ihrer Teamstruktur ab, welche der oben beschriebenen Kriterien von Ihnen wie stark zu gewichten und zu bewerten sind.

Gerne unterstützen wir Sie mit einem Expertenteam bei einem entsprechenden Vorhaben mit Rat und Tat – sprich angefangen vom Consulting, über die Planung bis hin zur Umsetzung. Melden Sie sich bei uns! Entweder telefonisch unter 0761-151828-0 oder per E-Mail unter info@esono.de