Wenn Sie „Cloud Native“ googeln, erhalten Sie mehr als 800 Millionen Treffer. Es liegt auf der Hand, dass „Cloud Native“ ein wichtiger Begriff ist – und Die Leute sind sich nicht ganz im Klaren darüber, was der Begriff eigentlich bedeutet. Vor einiger Zeit sagte ich in einem Gespräch mit einer Kollegin „aus der Branche“: „Aber das ist doch nicht cloud-nativ!“ Sie nickte weise zustimmend. Offensichtlich hat der Begriff eine Bedeutung, da wir uns mithilfe dieser Kurzform „cloud-nativ“ auf einige komplexe Konstrukte einigen konnten. Schauen wir uns das genauer an.
Um zu definieren, was „Cloud-Native“ bedeutet, müssen wir mit einer einfacheren Frage beginnen:
Was ist die Cloud?
Es dreht sich alles um die Aufschlüsselung
Vor fast 50 Jahren – noch bevor Microsoft gegründet wurde – schrieben die Harvard-Studenten Bill Gates und Paul Allen einen BASIC-Interpreter für einen der weltweit ersten Mikrocomputer, den MITS Altair 8080. Sie übertrugen das gesamte Programm auf Lochstreifen (eine frühe Form der Datenspeicherung) und flogen nach New Mexico, um MITS zu zeigen, was sie geschrieben hatten.
Beim Landeanflug auf Albuquerque wurde Allen klar, dass er keine Möglichkeit hatte, das Lochband zu lesen (was notwendig war, damit der BASIC-Interpreter es auf den Altair 8080 laden konnte). Allen schrieb kurzerhand ein Programm, um das Lochband auszulesen. Es funktionierte, und der Rest ist Geschichte..
Wenn Sie wissen möchten, was „aggregiert“ bedeutet – das ist ein hervorragendes Beispiel. Alles, was für den Betrieb des BASIC-Interpreters von Gates und Allen erforderlich war, musste von Gates und Allen selbst geschrieben werden – einschließlich der Routine zum Einlesen des Codes vom Lochstreifen in den Systemspeicher!
Springen wir nun zum Cloud-Computing, wo das Ziel darin besteht, alles vollständig zu entbündeln. Was soll entbündelt werden? Nun – alles. Die Rechenleistung wird von allen anderen Komponenten getrennt, sodass Sie die benötigte Rechenleistung unabhängig von allem anderen erwerben können. Das Gleiche gilt für Speicher und Netzwerk.
Aber das ist nur die Infrastruktur. Die Cloud entbündelt auch die Software. Während Gates und Allen jede einzelne Zeile Code für ihre Anwendung selbst schreiben mussten, nutzen Cloud-Anwendungen heute „Dienste“, um bestimmte Aufgaben zu erledigen. Anstatt jahrelang riesige, monolithische Anwendungen zu programmieren, bestehen heutige Cloud-Anwendungen aus Hunderten von Codezeilen, die Dutzende (oder Hunderte) von Cloud-Diensten miteinander verknüpfen.
Die Cloud ist die logische Weiterentwicklung der Unix-Philosophie der Kombinierbarkeit, die am besten beschrieben wurde von Doug McElroy, der Erfinder der Unix-Pipe: „Schreibt Programme, die eine Sache tun und diese gut machen. Schreibt Programme, die zusammenarbeiten.“
Das ist das Wesentliche der Cloud. Aber warum eine Disaggregation? Im Grunde genommen sorgt die Disaggregation für Elastizität und Agilität.
Elastizität
Der Ressourcenbedarf einer Arbeitslast schwankt im Laufe der Zeit. Zum Beispiel James Camerons „Avatar“ hat die Grenzen der Spezialeffekte erweitert. Das Rendern eines einzelnen Bildes erforderte in der Cloud die Rechenleistung von umgerechnet 3.000 vCPUs für eine Stunde. Da „Avatar“ mit 48 Bildern pro Sekunde gedreht wurde und eine Laufzeit von 192 Minuten hatte, mussten über eine halbe Million Bilder gerendert werden. Das entspricht mehr als 1,6 Milliarden Stunden virtueller CPU-Zyklen.
Die Produktion des Films dauerte insgesamt 12 Jahre, doch wie bei allen Filmen erfolgte ein Großteil der endgültigen Bearbeitung erst kurz vor dem Kinostart. Cloud bot dem für die Spezialeffekte von „Avatar“ zuständigen Anbieter die nötige Flexibilität, um das Projekt zum Abschluss zu bringen. David Conley, Executive VFX Producer, betonte, dass dies ohne AWS nicht möglich gewesen wäre.
Die Skalierbarkeit gilt für Rechenleistung, Speicher, Netzwerk und nahezu alle benötigten Ressourcen. Dank der Cloud lässt sich die Nutzung je nach Bedarf einfach und schnell nach oben und wieder nach unten skalieren.
Beweglichkeit
Ein weiterer Vorteil der Cloud ist Agilität im wahrsten Sinne des Wortes. Die Cloud ermöglicht:
Agilität in der Entwicklung aufgrund der oben genannten Service-Architektur. Entwickler greifen auf eine Vielzahl von Diensten zurück und reduzieren den Programmieraufwand von Jahren und Millionen von Codezeilen auf Wochen und Tausende von Zeilen.
Nebenbei sei angemerkt, dass diese neue „Service-Architektur“ vom Netzwerkeffekt profitiert. Je mehr Workloads Dienste nutzen, desto stärker sind Drittanbieter motiviert, neue Dienste zu entwickeln. Und je mehr Dienste es gibt, desto stärker sind Entwickler motiviert, Dienste von Drittanbietern zu nutzen. Dieser positive Kreislauf hat den Übergang von monolithischen Programmierpraktiken hin zu Service-Architekturen beschleunigt.
Agilität der Infrastruktur, Denn anstatt Infrastruktur zu kaufen, zu installieren und zu verwalten, fordern die Nutzer einfach per Anfrage an, was sie benötigen – und zwar genau dann, wenn sie es brauchen. Der Begriff „Infrastructure-as-Code“ bezieht sich auf die Verwendung eines einfachen „Codes“, mit dem die gesamte benötigte Infrastruktur innerhalb von Minuten statt Wochen oder Monaten bereitgestellt werden kann.
Wirtschaftliche Flexibilität, denn man nutzt nur das, was man braucht, und zwar genau dann, wenn man es braucht. Avatar musste kein riesiges SFX-Rechenzentrum aufbauen und dieses 12 Jahre lang betreiben. Stattdessen haben sie einfach genau das bereitgestellt, was sie brauchten, wann immer sie es brauchten.
Da wir nun also wissen, was die Cloud ist, können wir darüber sprechen, was es braucht, um wirklich cloud-nativ zu sein.
Was versteht man unter „Cloud Native“?
Die einfache Antwort lautet: Eine Cloud-native Anwendung kommuniziert mit der Cloud über Cloud-nativ Grundelemente. So würde beispielsweise eine Cloud-native Anwendung direkt die nativen Speicherdienste von Amazon AWS (S3, EBS, EFS usw.) aufrufen. Dieses Prinzip gilt für alle Cloud-Dienste – Rechenleistung, Speicher, Netzwerk usw.
Für Anwendungen, die „in der Cloud entstanden sind“ (d. h. von Anfang an dafür konzipiert wurden, in der Cloud und ausschließlich dort zu laufen), ist dies relativ einfach. Bei Anwendungen, die ursprünglich für den Einsatz vor Ort entwickelt wurden, ist jedoch eine mühsame Umgestaltung erforderlich. Beachten Sie, dass hierfür die vollständige Entkopplung der Anwendung von der gesamten Infrastruktur – Rechenleistung, Speicher und Netzwerk – notwendig ist.
Die zweite wichtige Voraussetzung dafür, wirklich cloud-nativ zu sein, ist die Verwaltung „als Code“. Das bedeutet, dass die Anwendung mit nur wenigen Zeilen Code gestartet werden kann – im Gegensatz zum herkömmlichen On-Premises-Verfahren, bei dem alles manuell über einen Zeitraum von mehreren Wochen installiert und konfiguriert werden muss.
Genau wie bei einer Schwangerschaft gibt es kein „teilweise Cloud-Native“. Eine App ist entweder Cloud-Native oder nicht. Wenn eine App nicht vollständig disaggregiert ist und die „As-Code“-Methodik nicht vollständig umsetzt, verliert sie die Vorteile der Elastizität und Agilität, die die Cloud verspricht.
Gibt es cloudnative Speicherlösungen?
Bevor wir über Cloud-native Speicherlösungen sprechen, wollen wir uns zunächst die „Grundbausteine“ der Cloud im Hinblick auf den „Speicher“ noch einmal vor Augen führen.
Es handelt sich um Objektspeicher (Azure Blob / AWS S3). Dies ist eine erstaunlich kostengünstige, skalierbare, verfügbare und dauerhafte Datenspeicherschicht mit hervorragender Leistung, gemessen am Durchsatz. Der Nachteil ist, dass es sich um eine neue, REST-konforme Schnittstelle handelt, die nur „eventually consistent“ ist.
Dann gibt es noch das, was ich als „SAN für den kleinen Geldbeutel“ bezeichnen würde, d. h. EBS auf AWS und Managed Disk auf Azure. Sie präsentieren sich wie eine „lokale Festplatte“, sind ausfallsicher und verhalten sich größtenteils genau wie eine normale Festplatte in einem herkömmlichen Speicherserver. Diese Komponenten entsprechen einer „geschützten lokalen Festplatte“ (abgesehen davon, dass sie nicht an die lokale Recheninstanz angeschlossen sind). Diese Komponenten weisen moderate Leistungsmerkmale auf und unterstützen „zufällige Lese- und Schreibvorgänge“, sind jedoch teuer.
Und schließlich gibt es noch an Instanzen angebundene NVMe-SSDs, die eher einer Erweiterung des DRAM entsprechen, da die Daten auf diesen „Laufwerken“ bei einem Neustart der Instanz nicht erhalten bleiben; dennoch sind sie weitaus kostengünstiger als DRAM oder „geschützte lokale Festplatten“ und weisen gleichzeitig Leistungseigenschaften auf, die zwischen diesen beiden liegen.
Bislang hat sich die Speicherbranche hartnäckig gegen die Cloud gewehrt. Die etablierten Anbieter (Dell, NetApp) verfügen über viel zu viel hardwarespezifischen Code (starke Abhängigkeit von NVRAM, enge Verknüpfung von Datensicherheit und Datendienstschichten), um ihre Angebote so umzugestalten, dass sie die Vorteile cloud-nativer Primitive nutzen können.
Und dann kamen VAST und Pure auf den Markt, die sich ebenfalls für einen hardwareoptimierten Speicher-Stack entschieden.
Pure’s Cloud-Blockspeicher Dieses Angebot ist zwar insofern relevant, als es cloud-native Primitive nutzt, um jene Blockdatendienste bereitzustellen, die von den Kunden von Pure so sehr gewünscht werden, ABER es ist auch mehr als traurig! Wer um alles in der Welt nutzt denn noch SAN in der Cloud? Das ist einfach unfassbar. Und wo wir gerade bei diesem Thema sind: Ich kann mir nur schwer vorstellen, wer in der Cloud noch VMware nutzt. Auch das ist einfach unfassbar!
Unter den Anbietern von Speicherlösungen der nächsten Generation ist es tatsächlich Weka.io, das beeindruckt. Das Unternehmen verfügt über eine „Cloud-native“ Architektur und nutzt Cloud-Objektspeicher als Ausfallsicherheitsschicht. Wenn es nur nicht den Ruf hätte, ein Nischenanbieter im HPC-Bereich und ein „Ferrari aus Glas“ zu sein …
Was habe ich als CTO von Qumulo also zu den Cloud-Lösungen von Qumulo zu sagen?
Bleibt dran.
Merkt euch das Datum in eurem Kalender vor: Donnerstag, den 9. November 2023 – und macht euch darauf gefasst, dass ihr aus den Socken gehauen werdet 🙂