Google „Cloud Native“ und Sie erhalten mehr als 800 Millionen Treffer. Cloud Native ist eindeutig ein wichtiger Begriff – und Die Leute sind sich nicht sicher, was es eigentlich bedeutet. Vor einiger Zeit sagte ich in einem Gespräch mit jemand anderem „in der Branche“: „Aber es ist nicht Cloud-nativ!“ Sie nickte weise zustimmend. Es bedeutet eindeutig etwas, da wir uns mit der Abkürzung „Cloud Native“ auf einige komplexe Konstrukte einigen konnten. Lassen Sie uns näher darauf eingehen.
Um zu definieren, was Cloud Native ist, müssen wir mit einer einfacheren Frage beginnen:
Was ist Wolke?
Es geht um Disaggregation
Vor fast 50 Jahren – bevor Microsoft gegründet wurde – schrieben die Harvard-Studenten Bill Gates und Paul Allen einen BASIC-Interpreter für einen der ersten Mikrocomputer der Welt, den MITS Altair 8080. Sie haben das gesamte Programm auf Papierband (eine frühe Form der Speicherung) geschrieben und flogen nach New Mexico, um MITS zu zeigen, was sie geschrieben hatten.
Beim Abstieg nach Albuquerque wurde Allen klar, dass er keine Möglichkeit hatte, das Papierband zu lesen (notwendig, damit der BASIC-Interpreter es auf den Altair 8080 laden konnte). Allen schrieb schnell ein Programm zum Lesen des Papierstreifens. Es hat funktioniert und der Rest ist Geschichte.
Wenn Sie wissen möchten, was „aggregiert“ bedeutet – das ist ein tolles Beispiel. Alles, was zum Ausführen des BASIC-Interpreters von Gates und Allen erforderlich war, musste von Gates und Allen geschrieben werden – einschließlich der Routine zum Einlesen des Codes vom Papierband in den Systemspeicher!
Schneller Vorlauf zum Cloud Computing, wo das Ziel die vollständige Disaggregation ist. Was disaggregieren? Also - alles. Die Rechenleistung ist von allem anderen getrennt, sodass Sie die Menge an Rechenleistung, die Sie benötigen, unabhängig von allem anderen erwerben können. Das Gleiche gilt für Speicher und Netzwerk.
Aber das ist nur Infrastruktur. Die Cloud disaggregiert auch Software. Während Gates und Allen jede einzelne Codezeile für ihre Anwendung schreiben mussten, nutzen Cloud-Apps heute „Dienste“, um bestimmte Aufgaben zu erledigen. Anstatt jahrelang riesige, monolithische Anwendungen zu programmieren, bestehen die heutigen Cloud-Anwendungen aus Hunderten von Codezeilen, die Dutzende (oder Hunderte) von Cloud-Diensten verknüpfen.
Cloud ist die logische Erweiterung der Unix-Philosophie der Zusammensetzbarkeit, die am besten zum Ausdruck kommt Doug McElroy, der Erfinder der Unix-Pipe: „Schreiben Sie Programme, die eine Sache tun, und zwar gut. Schreiben Sie Programme, um zusammenzuarbeiten.“
Das ist die Essenz der Cloud. Aber warum disaggregieren? Auf der einfachsten Ebene sorgt die Disaggregation für Elastizität und Agilität.
Elastizität
Die für jede Arbeitslast erforderlichen Ressourcen variieren im Laufe der Zeit. Zum Beispiel das von James Cameron Avatar hat die Grenzen für Spezialeffekte überschritten. Das Rendern eines einzelnen Frames erforderte das Äquivalent von 3,000 vCPUs in der Cloud für eine Stunde. Da „Avatar“ mit 48 Bildern pro Sekunde gedreht wurde und 192 Minuten lief, mussten über eine halbe Million Bilder gerendert werden. Das sind mehr als 1.6 Milliarden Stunden virtueller CPU-Zyklen.
Der Film wurde insgesamt 12 Jahre lang produziert, aber wie bei allen Filmen erfolgte die Endfassung eines Großteils kurz vor der Veröffentlichung des Films. Cloud sorgte für die Elastizität Spezialeffekte von Avatar Der Lieferant musste die Arbeit erledigen. Der ausführende VFX-Produzent David Conley bemerkte, dass dies ohne AWS nicht möglich gewesen wäre.
Elastizität gilt für Rechenleistung, Speicher, Netzwerk und nahezu jede erforderliche Ressource. Mit der Cloud lässt sich die Nutzung je nach Bedarf einfach und schnell erhöhen und wieder verringern.
Agilität
Der andere Vorteil der Cloud ist Agilität im wahrsten Sinne des Wortes. Cloud ermöglicht:
- Entwicklungsagilität aufgrund der oben genannten Service-Architektur. Entwickler greifen auf ein breites Spektrum an Diensten zurück und reduzieren die Codierung von Jahren und Millionen von Codezeilen auf Wochen und Tausende von Zeilen.
Eine Randbemerkung ist, dass diese neue „Dienstarchitektur“ vom Netzwerkeffekt profitiert. Je mehr Workloads Dienste nutzen, desto stärker sind Dritte motiviert, neue Dienste zu entwickeln. Und je mehr Dienste es gibt, desto größer ist die Motivation der Entwickler, Dienste von Drittanbietern zu nutzen. Dieser positive Kreislauf hat den Übergang von monolithischen Codierungspraktiken hin zu Servicearchitekturen beschleunigt.
- Agilität der Infrastruktur, Denn anstatt Infrastruktur zu kaufen, zu installieren und zu verwalten, fordern Benutzer einfach durch einfache Anfragen an, was sie brauchen – wann sie es brauchen. Der Begriff „Infrastruktur als Code“ bezieht sich auf die Verwendung eines einfachen „Codes“, um die gesamte benötigte Infrastruktur in Minuten statt in Wochen oder Monaten bereitzustellen.
- Wirtschaftliche Agilität, weil du nur für das spielst, was du brauchst, und zwar dann, wenn du es brauchst. Avatar musste kein riesiges SFX-Rechenzentrum aufbauen und es 12 Jahre lang verwalten. Stattdessen entwickelten sie einfach das, was sie brauchten, wenn sie es brauchten.
Nachdem wir nun verstanden haben, was Cloud ist, können wir darüber diskutieren, was es braucht, um wirklich Cloud-nativ zu sein.
Was ist Cloud-Native?
Die einfache Antwort ist, dass eine Cloud-native Anwendung mit der Cloud interagiert Cloud-native Primitiven. Beispielsweise würde eine Cloud-native App direkt die nativen Speicherdienste von Amazon AWS (S3, EBS, EFS usw.) aufrufen. Dieses Prinzip gilt für alle Cloud-Dienste – Computer, Geschäft, Netzwerk usw.
Für Anwendungen, die „in der Cloud geboren“ sind (also vom ersten Tag an so konzipiert sind, dass sie nur in der Cloud laufen), ist dies ganz einfach. Für Anwendungen, die in einer On-Premise-Welt erstellt werden, ist jedoch eine mühsame Umgestaltungsübung erforderlich. Beachten Sie, dass dies erfordert, dass die Anwendung vollständig von der gesamten Infrastruktur – Rechenleistung, Speicher und Netzwerk – getrennt ist.
Die zweite wichtige Voraussetzung für eine echte Cloud-Native-Nutzung ist die Verwaltung „als Code“. Dies bedeutet, dass Sie die Anwendung mit wenigen Codezeilen starten können, im Gegensatz zum herkömmlichen lokalen Prozess, bei dem alles über einen Zeitraum von Wochen manuell installiert und konfiguriert wird.
Wie bei einer Schwangerschaft gibt es kein „teilweises Cloud-Native“. Eine App ist entweder Cloud-nativ oder nicht. Wenn eine App nicht vollständig disaggregiert wird und die „As-Code“-Methodik übernimmt, verliert sie die von der Cloud versprochenen Vorteile der Elastizität und Agilität.
Gibt es Cloud-native Speicherlösungen?
Bevor wir über Cloud-Native-Storage-Lösungen sprechen, werfen wir einen Blick auf die „Primitiven“ der Cloud, soweit es um „Storage“ geht.
Es handelt sich um Objektspeicher (Azure Blob / AWS S3). Dies ist eine erstaunlich erschwingliche, skalierbare, verfügbare und dauerhafte Datenpersistenzschicht mit hervorragender Leistung, gemessen am Durchsatz. Der Nachteil besteht darin, dass es sich um eine neue Schnittstelle handelt, die RESTful und nur letztendlich konsistent ist.
Dann haben Sie das, was ich das Möchtegern-SAN eines armen Menschen nennen würde, also EBS auf AWS und Managed Disk auf Azure. Sie präsentieren sich wie eine „lokale Festplatte“, sind belastbar und verhalten sich größtenteils wie eine normale Festplatte in einem einfachen alten Speicherserver. Diese Grundelemente fungieren als Äquivalent einer „geschützten lokalen Festplatte“ (außer dass sie nicht an die lokale Recheninstanz angeschlossen ist). Diese Grundelemente haben mäßige Leistungsmerkmale und können „zufällige Lese-/Schreibvorgänge“ unterstützen, sind jedoch teuer.
Und schließlich verfügen Sie über an Instanzen angeschlossene NVMe-SSDs, die eher einer Erweiterung von DRAM ähneln, da die Daten auf diesen „Laufwerken“ nicht über Instanz-Neustarts hinweg bestehen bleiben, und dennoch sind sie weitaus kostengünstiger als DRAM oder „geschützte lokale Festplatten“. Leistungsmerkmale zwischen diesen beiden.
Bisher hat sich die Speicherbranche hartnäckig gegen die Cloud gewehrt. Die alten Anbieter (Dell, NetApp) verfügen über viel zu viel hardwarespezifischen Code (starke Abhängigkeit von NVRAM, enge Kopplung von Datenresilienz und Datendienstschichten), um ihre Angebote umzugestalten, um die Vorteile cloudnativer Grundelemente zu nutzen.
Und dann kamen VAST und Pure, die sich ebenfalls für einen hardwareoptimierten Speicherstapel entschieden.
Pures Cloud-Blockspeicher Das Angebot ist sowohl insofern relevant, als es Cloud-native Primitive verwendet, um die von Pure-Kunden so gewünschten Blockdatendienste bereitzustellen, UND darüber hinaus traurig! Wer in aller Welt betreibt ein SAN in der Cloud? Verwirrt einfach den Verstand. Und während wir uns mit diesem Thema befassen, fällt es mir schwer zu verstehen, wer VMWare in der Cloud verwendet. Auch das verwirrt den Verstand!
Unter den Speicheranbietern der nächsten Generation beeindruckt vor allem Weka.io. Sie verfügen über eine „Cloud-native“-Architektur und nutzen Cloud-Objektspeicher als Ausfallsicherheitsschicht. Wenn sie nur nicht den Ruf hätten, ein HPC-Nischenanbieter und ein „gläserner Ferrari“ zu sein …
Was kann ich als CTO von Qumulo zum Cloud-Angebot von Qumulo sagen?
Bleiben Sie dran.
Markieren Sie das Datum in Ihren Kalendern. Donnerstag, 9. November 2023, und seien Sie darauf gefasst, umwerfend zu sein 🙂
