Cloud Native Entwicklung mit Google Cloud

Kapitel 1. Warum Cloud Native und nicht nur Cloud?

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Ende der 1990er Jahre, als ich meine berufliche Laufbahn begann, befand sich die digitale Landschaft im Anfangsstadium des Wandels. Die Unternehmen führten zum ersten Mal E-Mail-Server ein, und die Beschäftigten begannen, sich mit den PCs auf ihren Schreibtischen vertraut zu machen. Als praktischer Techniker war es meine Aufgabe, diese PCs einzurichten, E-Mail-Server in Serverräumen zu installieren und sie über Einwahlmodems oder ISDN-Leitungen mit dem Internet zu verbinden.

Damals war ein Computerraum oft nur ein klimatisierter Schrank, in dem die gesamte Computerinfrastruktur des Unternehmens untergebracht war. Ich erinnere mich noch gut daran, wie ich einen Server neben einer waschmaschinengroßen DEC VAX installierte, einem Computerrelikt aus den 1980er Jahren, das noch genauso lief, wie ich es in meinen Informatiklehrbüchern gesehen hatte.

Mit dem Dot-Com-Boom Anfang der 2000er Jahre wurde eine stabile und unterbrechungsfreie Internetpräsenz für Unternehmen unerlässlich. Große Unternehmen reagierten darauf mit Investitionen in Rechenzentren vor Ort, spezielle Einrichtungen, die IT-Geräte mit mehreren redundanten Internetverbindungen und Stromversorgungen beherbergen.

Der Bau eines eigenen Rechenzentrums war für kleinere Unternehmen jedoch nicht machbar. Stattdessen konnten sie Platz in gemeinsam genutzten Colocation-Rechenzentren oder "CoLos" mieten. Für aufstrebende Internet-Startups stellte dies jedoch eine große Herausforderung dar: Was passiert, wenn du über Nacht ein Erfolg wirst? Was, wenn deine Nutzerbasis über Nacht von eintausend auf eine Million Nutzer/innen ansteigt?

Wäre es klüger, mit Servern zu beginnen, die tausend Nutzer/innen aufnehmen können, und zu riskieren, dass deine Website abstürzt, wenn du nicht schnell genug skalieren kannst? Oder solltest du vorsorglich in die Kapazität investieren, um im Falle eines schnellen Wachstums Millionen von Nutzern bedienen zu können? Letzteres würde eine beträchtliche Finanzierung erfordern, die möglicherweise von einem Risikokapitalgeber mit tiefen Taschen abhängt. Die Abwägung zwischen diesem Risiko und dem potenziellen Wachstum wurde in dieser Zeit für viele Unternehmen zu einer drängenden Frage.

Das Aufkommen des Cloud-Zeitalters

Das Aufkommen der öffentlichen Cloud markierte einen bedeutenden Wendepunkt. Im Jahr 2006 begann Amazon Web Services (AWS) mit dem Angebot von EC2-Servern auf Abruf, und ab 2008 konnte jeder, der eine Kreditkarte besaß, praktisch im Handumdrehen einen Server einrichten. Die Möglichkeit, die Serverkapazität bei steigender Nachfrage nahtlos zu erhöhen, war ein Wendepunkt. Start-ups konnten mit einer bescheidenen Infrastruktur beginnen und diese dann erweitern, wenn sie profitabler wurden, was die Anfangsinvestitionen minimierte und die Innovationskosten senkte.

Im Jahr 2008 zog Google mit der Google App Engine (GAE) nach und leistete damit Pionierarbeit für eine der ersten Plattformen als Service (PaaS). Mit GAE konnten Entwickler/innen eine Webanwendung in PHP oder Python schreiben und sie in der öffentlichen Cloud von Google bereitstellen, ohne sich um eine Serverinfrastruktur kümmern zu müssen. Trotz des Potenzials von GAE stellte es Entwickler/innen wie mich, die an die Arbeit mit traditionellen Anwendungen und relationalen Datenbanken gewöhnt waren, aufgrund der ungewohnten Einschränkungen vor Herausforderungen.

Als sich die 2010er Jahre entwickelten und Cloud Computing immer beliebter wurde, begannen Unternehmen mit teuren Rechenzentren vor Ort, neidisch auf ihre digitale Konkurrenz zu blicken. Unternehmen wie Netflix, Airbnb und Slack. Diese neueren Unternehmen, die in der Cloud entstanden sind und ihre Software auf Plattformen wie AWS, Google Cloud und Microsoft Azure bereitstellen, brachten schnell wettbewerbsfähige Produkte auf den Markt, ohne die hohen Kosten für die Unterhaltung eines Rechenzentrums tragen zu müssen. Außerdem nutzten sie zusätzliche On-Demand-Cloud-Dienste wie maschinelles Lernen und künstliche Intelligenz, die noch nie dagewesene Möglichkeiten boten.

Etablierte Unternehmen, die im traditionellen Rechenzentrumsbetrieb verwurzelt sind, fanden die Verlockung der Cloud aus mehreren Gründen unwiderstehlich, wie in Abbildung 1-1 dargestellt.

Abbildung 1-1. Schneller gehen, Geld sparen und mehr tun

Diese waren typischerweise:

Schneller gehen

Steigere die Produktivität von Entwicklern, indem du die bedarfsgerechten, skalierbaren Ressourcen der Cloud und eine breite Palette vorgefertigter Dienste nutzt. So können sich die Entwickler auf die eigentliche Anwendungslogik konzentrieren und müssen sich nicht um die Infrastruktur kümmern.

Geld sparen

Senkung der Infrastruktur- oder Betriebskosten durch Verlagerung von Investitionsausgaben (CapEx) für Hardware und Wartung zu Betriebsausgaben (OpEx) für On-Demand-Dienste, Verbesserung des Cashflows und Verringerung der Vorabinvestitionen.

Mehr tun

Greife auf Ressourcen und Dienste zu, die vor Ort nicht möglich sind, wie z. B. umfangreiche skalierbare Speicheroptionen, leistungsstarke Datenanalysetools, Plattformen für maschinelles Lernen und fortschrittliche KI-Dienste.

Der entscheidende Fehler, den diese Unternehmen oft begehen, ist die Migration in die Cloud, ohne die Einzigartigkeit und die zusätzliche Komplexität zu verstehen, die sie mit sich bringt, und ohne zu wissen, inwiefern sie Änderungen in den Softwareentwicklungspraktiken erfordert. Anstatt die Effizienz zu steigern und die Kosten zu senken, kann die Cloud daher manchmal zusätzliche Komplikationen und Kosten verursachen, was den Fortschritt verlangsamt und die Ausgaben erhöht. Der häufig versprochene Vorteil, dass man "sein Chaos billiger betreiben kann", tritt daher nur selten ein, was unterstreicht, wie wichtig ein gut informierter und strategischer Ansatz für die Cloud-Migration ist.

Navigieren durch die Cloud-Migration

Ich bin eine große Bewunderin von Marie Kondo, der japanischen Organisationsberaterin, die Freude ins Haus bringt, indem sie unordentliche Räume in ein Reich der Ruhe undEffizienz verwandelt.

Stell dir einen Schrank vor, in dem sich zwei Jahrzehnte lang Besitztümer angesammelt haben - eine Mischung aus überholten, kaputten und ungeöffneten Gegenständen. Darunter befinden sich auch Dinge, die du doppelt gekauft hast, ohne zu wissen, dass es sie in den Tiefen des überfüllten Schranks gibt. Inmitten des Chaos warten ein paar praktische Gegenstände darauf, entdeckt zu werden. Aber der Versuch, sie auszugraben, könnte eine katastrophale Lawine auslösen. Glaub mir, ich besitze einen solchen Schrank.

Dieses Szenario ist ein typisches Beispiel für ein Rechenzentrum vor Ort, ein Labyrinth von Anwendungen, deren Bedeutung nicht erkennbar ist.

Auf der Suche nach den Vorteilen der Cloud wurden die Unternehmen dazu gedrängt, eine "Lift-and-Shift"-Strategie zu verfolgen, d.h. ihre bestehenden Anwendungen komplett in die Cloud zu verlagern. Diese Strategie fühlt sich oft so an, als würdest du deinen vollgestopften Schrank in eine gemietete Garage in einem anderen Stadtteil verlagern. Du hast immer noch mit der gleichen Menge an Material zu kämpfen, es ist nur unbequemer zu erreichen und zu sichern. Ganz zu schweigen davon, dass die Garage mit zusätzlichen Mietkosten verbunden ist.

Als Alternative zum "Lift and Shift" wurde den Unternehmen auch empfohlen, ihre Anwendungen vor der Cloud-Migration zu "containerisieren". In Anlehnung an den Schrank wäre das so, als würde man sein Hab und Gut in Plastikkisten packen, bevor man es in die Garage bringt. Die Containerisierung vereinfacht den Transport und die Verwaltung von Anwendungen und erleichtert zukünftige Umzüge zwischen verschiedenen Speichereinheiten. Allerdings hat sie auch die Nachteile der Speicherung in der Garage und die zusätzlichen Kosten für die Container. Diese "Umzugs- und Verbesserungs"-Strategie scheint verlockend zu sein, aber die Motivation zum Aussortieren schwindet oft, sobald der Kram außer Sichtweite ist.

Die Fallstricke einer ungeplanten Reise

Im Idealfall wird der Schrank komplett entrümpelt. Kaputte Gegenstände sollten repariert oder weggeworfen werden, überflüssige Dinge entfernt und doppelte oder ungenutzte Besitztümer gespendet werden. Nach dem Mantra von Marie Kondo solltest du nur die Dinge behalten, die "Freude machen". Sobald diese Auswahl abgeschlossen ist, kannst du dir überlegen, ob du diese wertvollen Gegenstände ausstellen oder ordentlich und sicher verstauen willst.

Im Bereich der Cloud-Technologie wird dieser Ansatz als Cloud-Modernisierung bezeichnet: eine umfassende Überprüfung und Umstrukturierung von Anwendungen für eine optimale Cloud-Leistung. Dieses Thema würde jedoch den Rahmen dieses Buches sprengen. Wie viele Unternehmen festgestellt haben, kann die Cloud-Modernisierung ein langwieriger und kostspieliger Prozess sein. Viele Unternehmen haben auf Lift-and-Shift- oder Containerisierungsstrategien zurückgegriffen, nur um festzustellen, dass ihre Anwendungen in der Cloud schwerer zu verwalten und zu sichern sind und teurer werden.

Nicht optimale Erfahrungen mit der Cloud-Migration haben zu Skepsis und Enttäuschung über die Cloud geführt. Die Unternehmen wurden daran erinnert, dass es keine Einheitslösung oder schnelle Lösung gibt. Trotz dieser Enttäuschung nutzen die Wettbewerber der Digital Natives weiterhin die Vorteile der Cloud und es lohnt sich, genauer zu untersuchen, was diese Unternehmen in ihrer Cloud-Strategie auszeichnet.

Mehr als nur ein Online-Rechenzentrum

Digital Natives wissen, dass die wahre Stärke von Public Cloud Services in ihren riesigen, weltweit verteilten, gemeinsam genutzten und hoch automatisierten Rechenzentren liegt. Diese Merkmale ermöglichen die Abrechnung nach Verbrauch, eine praktisch unbegrenzte Skalierbarkeit und ein Selbstbedienungsmodell, wie in Abbildung 1-2 dargestellt.

Abbildung 1-2. Vorteile der Cloud

Öffentliche Clouds bestehen jedoch aus handelsüblicher Hardware, die über Netzwerke verbunden ist, die so ausgewählt wurden, dass die Gesamtbetriebskosten möglichst gering sind. Die Hardware wird von einem Drittanbieter verwaltet und von mehreren Kunden gemeinsam genutzt. Es ist wichtig zu verstehen, dass Cloud Computing nicht per se zuverlässiger, kostengünstiger oder sicherer ist als der Betrieb eines eigenen Rechenzentrums:

• Die Hardware im Rechenzentrum ist oft auf Redundanz und aufgabenspezifische Optimierung ausgelegt, während die Hardware in der Cloud allgemein und standardisiert ist und mit gelegentlichen Ausfällen gerechnet werden muss.

• In einem Rechenzentrum gehört dir die Hardware und ein Wechsel ist schwierig. Im Gegensatz dazu stellt die Cloud gemietete Hardware im Minutentakt zur Verfügung, was einen einfachen Wechsel ermöglicht, allerdings zu einem höheren Preis als deine Hardware.

• Ein physisches Rechenzentrum ist von einer effektiven Mauer umgeben, die ein gewisses Vertrauen in die darin befindliche Infrastruktur schafft. In der Cloud sollte jedoch ein vertrauensfreier Ansatz verfolgt werden.

Bei der Umstellung auf die Cloud geht es nicht nur darum, den Betrieb deines traditionellen Rechenzentrums online zu verlagern. Es ist eine Chance, eine leistungsstarke Technologie zu nutzen, die den Geschäftsbetrieb grundlegend verändern kann. Das erfordert jedoch den richtigen Ansatz. Wenn du einfach nur dein lokales System in die Cloud überträgst, ohne deine Methoden anzupassen, kann das zu höheren Kosten, größeren Sicherheitsrisiken und möglicherweise geringerer Zuverlässigkeit führen, wie in Abbildung 1-3 dargestellt. Dadurch wird das Potenzial der Cloud nicht voll ausgeschöpft und kann kontraproduktiv sein.

Abbildung 1-3. Die Realität der Behandlung der Cloud als ein weiteres Rechenzentrum

Stattdessen kann die Anerkennung der einzigartigen Merkmale und Anforderungen der Cloud und deren vollständige Nutzung wirklich transformativ sein. Die Nutzung der Elastizität, Skalierbarkeit und fortschrittlichen Sicherheitsfunktionen der Cloud kann zu einem Maß an betrieblicher Effizienz, Kosteneffizienz und Innovation führen, das die Möglichkeiten traditioneller Rechenzentrumsumgebungen übertrifft.

Die Cloud ist nicht nur eine Online-Variante deines aktuellen Rechenzentrums. Sie ist ein anderes Paradigma, das einen anderen Ansatz erfordert. Wenn sie geschickt genutzt wird, kann sie eine Welt voller Möglichkeiten eröffnen, die weit über die Möglichkeiten der traditionellen Infrastruktur hinausgeht. Wenn du dich auf die Unterschiede einlässt, kannst du das Potenzial der Cloud voll ausschöpfen.

Die Cloud als verteiltes System begreifen

Das Wesentliche an der Cloud ist, dass sie als verteiltes System funktioniert. Dieses Hauptmerkmal macht viele Annahmen der traditionellen Entwicklungüberflüssig.

Diese Irrtümer, die sogenannten " Fallacies of Distributed Computing" ( ), wurden zuerst von Peter Deutsch und seinen Kollegen bei Sun Microsystems erkannt:

• Das Netzwerk ist zuverlässig.

• Die Latenzzeit ist gleich null.

• Die Bandbreite ist unendlich.

• Das Netzwerk ist sicher.

• Die Topologie ändert sich nicht.

• Es gibt einen Verwalter.

• Die Transportkosten sind gleich null.

• Das Netzwerk ist homogen.

Jeder dieser Punkte stellt eine Hürde dar, die überwunden werden muss, wenn man versucht, eine Cloud von Grund auf neu zu konstruieren. Glücklicherweise haben die Cloud-Provider in den letzten zwei Jahrzehnten erhebliche technische Ressourcen in die Entwicklung von APIs auf höherer Ebene gesteckt, um diese Probleme effektiv zu lösen. Das ist genau der Grund, warum die Digital Natives im Vorteil sind - sie sind auf die Cloud Native Development eingestellt, eine Methode, die diese Grundlagen nutzt.

Die Cloud-Native-Entwicklung erkennt die besonderen Merkmale der Cloud an und macht sich die hochgradigen Abstraktionen der Cloud-Provider-APIs zunutze. Es ist ein Entwicklungsstil, der mit den Realitäten der Cloud im Einklang steht, ihre Eigenheiten annimmt und ihr Potenzial voll ausschöpft.

Unterscheidung zwischen Cloud Hosted und Cloud Native

Es ist wichtig, den Unterschied zwischen in der Cloud gehosteten und nativen Cloud-Anwendungen zu verstehen. Vereinfacht gesagt, geht es bei ersterem um das Wo, bei letzterem um das Wie.

Anwendungen können in der Cloud gehostet werden, d. h. sie laufen auf der Infrastruktur eines öffentlichen Cloud-Providers, sind aber traditionell aufgebaut, als würden sie in einem lokalen Rechenzentrum betrieben. Umgekehrt können Anwendungen in der Cloud entwickelt und trotzdem in einem Rechenzentrum vor Ort gehostet werden, wie in Abbildung 1-4 dargestellt.

Abbildung 1-4. Cloud Hosted ist wo, Cloud Native ist wie

Wenn ich von "Cloud Native" spreche, meine ich damit den Entwicklungsstil, die Anwendungsarchitektur und die Abstraktion, die durch die Cloud-APIs bereitgestellt werden, und nicht den Hosting-Standort.

In diesem Buch geht es in erster Linie um die Erstellung von Cloud Native Applications mit Google Cloud, die sowohl die Prinzipien von Cloud Hosted als auch von Cloud Native umfasst (siehe Abbildung 1-4, unten rechts). Viele der hier vermittelten Informationen gelten aber auch für private und hybride On-Premises-Clouds, insbesondere für solche, die auf Containern und Kubernetes basieren, wie Red Hat OpenShift, VMWare Tanzu und Google Anthos(unten links in Abbildung 1-4).

Das Konzept von Cloud Native enträtseln

Der Begriff "Cloud Native" ließ mich früher erschaudern, weil ich das Gefühl hatte, dass seine Bedeutung von Softwareanbietern verwässert wurde, die ihn lediglich als Gütesiegel dafür nutzten, dass ihre Anwendungen cloudfähig und modern sind. Er erinnerte mich an andere Schlagworte wie "agil" oder "DevOps", die im Laufe der Zeit von Unternehmen, die etwas zu verkaufen haben, umgestaltet wurden.

Die Cloud Native Computing Foundation (CNCF), ein Projekt der Linux Foundation, das gegründet wurde, um die Bemühungen der Tech-Industrie zur Förderung von Cloud-Native-Technologien zu unterstützen, liefert jedoch eine präzise Definition:

Cloud-native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und hybriden Clouds zu entwickeln und zu betreiben. Container, Service Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs sind Beispiele für diesen Ansatz.

Diese Techniken ermöglichen lose gekoppelte Systeme, die widerstandsfähig, verwaltbar und beobachtbar sind. In Kombination mit robuster Automatisierung ermöglichen sie es Ingenieuren, mit minimalem Aufwand häufig und vorhersehbar Änderungen vorzunehmen.

Als ich mich anfangs für die Cloud Native-Technologie einsetzte, habe ich sie gemeinhin als eine Kombination aus Microservices, Containern, Automatisierung und Orchestrierung bezeichnet. Das war jedoch ein Fehler, denn obwohl dies wichtige Komponenten einer Cloud Native-Lösung sind, handelt es sich dabei nur um die technologischen Aspekte, die im ersten Teil der CNCF-Definition genannt werden. Der Irrtum, Cloud Native sei eine rein technologische Veränderung, ist einer der Hauptgründe, warum viele Cloud Native-Initiativen fehlschlagen.

Die Einführung von Technologien wie Kubernetes kann aufgrund der steilen Lernkurve und der zusätzlichen Komplexität, die sie für Entwickler/innen mit sich bringen, ziemlich störend sein. Wenn Entwickler/innen einfach nur einen Kubernetes-Cluster erhalten und ihn verwalten sollen, sind Probleme vorprogrammiert. Ein weit verbreiteter Irrglaube ist, dass Cloud Native mit Containern oder Kubernetes beginnt und endet, aber das ist weit von der Wahrheit entfernt.

Außerdem gibt es Probleme mit den Kosten und der Sicherheit. Beide Aspekte verändern sich mit der Cloud erheblich, vor allem in einem Cloud Native Szenario. Entwickler/innen müssen innerhalb angemessener Grenzen arbeiten, um kostspielige Fehler oder Sicherheitsverletzungen zu vermeiden, die den Ruf eines Unternehmens gefährden könnten.

Entscheidend in der CNCF-Definition ist der zweite Teil - die Techniken. Diese spiegeln einen Entwicklungsstil wider, der die Stärken der Cloud nutzt, aber auch ihre Grenzen anerkennt.

Bei Cloud Native geht es darum, anzuerkennen, dass Hardware fehlschlagen kann, Netzwerke unzuverlässig sein können und die Nachfrage der Nutzer/innen schwankt. Außerdem müssen sich moderne Anwendungen ständig an die Anforderungen der Nutzer anpassen und sollten daher mit dieser Flexibilität entwickelt werden. Das Konzept der Cloud Native bedeutet auch, die Grenzen der Cloud zu berücksichtigen und ihre Vorteile zu nutzen.

Die Umstellung auf Cloud-Native bedeutet, dass die Anwendungen so gestaltet werden, dass sie die Abstraktionen der APIs der Cloud-Provider optimal nutzen. Das bedeutet, dass man nicht mehr in Hardwareelementen wie Servern, Festplatten und Netzwerken denkt, sondern in höheren Abstraktionen wie Rechen-, Speicher- und Bandbreiteneinheiten.

Wichtig ist, dass Cloud Native darauf ausgerichtet ist, die wichtigsten Probleme zu lösen:

• Entwicklung von Anwendungen, die leicht zu ändern sind

• Anwendungen schaffen, die effizienter und zuverlässiger sind als die Infrastruktur, auf der sie laufen

• Einführung von Sicherheitsmaßnahmen, die auf einem Null-Vertrauensmodell basieren

Das ultimative Ziel von Cloud Native ist es, kurze Feedback-Zyklen, keine Ausfallzeiten und robuste Sicherheit zu erreichen.

Der Begriff "Cloud Native" lässt mich also nicht mehr zurückschrecken, sondern steht für einen Entwicklungsstil, der die Grenzen der Cloud überwindet und ihr volles Potenzial ausschöpft.

Cloud Native fungiert im Wesentlichen als Katalysator, der das anfängliche Versprechen des Cloud Computing einlöst: beschleunigte Entwicklung, Kosteneinsparungen und erweiterte Möglichkeiten.

Umfassende Cloud Native Architektur

Die Cloud Native Architecture basiert auf einer Reihe von Grundsätzen, die darauf abzielen, die Stärken der Cloud zu nutzen und ihre Grenzen zu umgehen. Im Gegensatz zur traditionellen Architektur, die Veränderungen, Ausfälle und Sicherheitsbedrohungen als Ausnahmen behandelte, sieht die Cloud Native Architecture sie als unvermeidliche Normen vor.

Die Schlüsselkonzepte in Abbildung 1-5 bilden die Grundlage der nativen Cloud-Architektur.

Abbildung 1-5. Prinzipien der Cloud Native Architektur

Lass uns jedes dieser Konzepte untersuchen:

Unabhängigkeit der Komponenten

Eine Architektur ist lose gekoppelt, wenn die einzelnen Systemkomponenten unabhängig voneinander entwickelt und geändert werden. So können verschiedene Teams separate Komponenten entwickeln, ohne dass es zu Verzögerungen durch gegenseitige Abhängigkeiten kommt. Wenn sie eingesetzt werden, können die Komponenten individuell skaliert werden. Sollte eine Komponente fehlschlagen, bleibt das Gesamtsystem funktionsfähig.

Eingebaute Widerstandsfähigkeit

Ein widerstandsfähiges System funktioniert nahtlos und erholt sich automatisch, wenn sich die zugrunde liegende Infrastruktur ändert oder einzelne Komponenten ausfallen. Cloud-native Systeme sind von Natur aus so konzipiert, dass sie mit Ausfällen umgehen können. Diese Ausfallsicherheit kann durch den Betrieb mehrerer Instanzen einer Komponente, die automatische Wiederherstellung von fehlgeschlagenen Komponenten oder eine Kombination aus beiden Strategien erreicht werden.

Transparente Beobachtbarkeit

Da ein natives Cloud-System aus mehreren Komponenten besteht, kann das Verständnis des Systemverhaltens und die Fehlersuche sehr komplex sein. Deshalb ist es wichtig, dass das System so konzipiert ist, dass man seinen Zustand anhand der externen Ausgaben klar erkennen kann. Diese Beobachtbarkeit kann durch umfassende Protokollierung, detaillierte Metriken, effektive Visualisierungstools und proaktive Warnsysteme erleichtert werden.

Deklarative Verwaltung

In einer nativen Cloud-Umgebung wird die zugrundeliegende Hardware von jemand anderem verwaltet und es werden Abstraktionsschichten darüber gelegt, um den Betrieb zu vereinfachen. Cloud-native Systeme bevorzugen einen deklarativen Ansatz für die Verwaltung, bei dem das gewünschte Ergebnis(was) Vorrang vor den spezifischen Schritten zum Erreichen des Ziels(wie) hat. Dieser Managementstil erlaubt es den Entwicklern, sich mehr auf die geschäftlichen Herausforderungen zu konzentrieren.

Zero-Trust-Sicherheit

Da alles in der öffentlichen Cloud gemeinsam genutzt wird, ist eine Standardeinstellung von Zero Trust unerlässlich. Cloud-native Systeme verschlüsseln Daten sowohl im Ruhezustand als auch bei der Übertragung und überprüfen jede Interaktion zwischen den Komponenten streng.

In den folgenden Kapiteln werde ich untersuchen, wie verschiedene Werkzeuge, Technologien und Techniken diese Konzepte unterstützen können.

Aufbau einer Cloud Native Plattform

Cloud-Provider bieten eine breite Palette von Tools und Technologien an. Damit die Cloud-Native-Architektur gedeihen kann, ist es wichtig, diese Werkzeuge zu kombinieren und sie mit Cloud-Native-Techniken anzuwenden. Dieser Ansatz legt den Grundstein für eine Plattform, die eine effiziente Entwicklung von Cloud Native Applications ermöglicht.

Labor, Fabrik, Zitadelle und Observatorium

Bei der Konzeption einer nativen Cloud-Plattform solltest du dir vier wichtige "Einrichtungen" auf der Cloud vorstellen: das Labor, die Fabrik, die Zitadelle und das Observatorium, wie in Abbildung 1-6 dargestellt. Jede dieser Einrichtungen erfüllt einen bestimmten Zweck, um Produktivität, Effizienz und Sicherheit zu fördern:

Labor

Das Labor maximiert die Produktivität der Entwickler, indem es eine reibungslose Umgebung bietet, die mit den notwendigen Werkzeugen und Ressourcen für die Innovation und Entwicklung von Anwendungen ausgestattet ist. Es sollte eine sichere Umgebung schaffen, die Experimente und schnelles Feedback ermöglicht.

Fabrik

In der Fabrik wird Effizienz großgeschrieben. Sie durchläuft die Anwendung, die ursprünglich im Labor erstellt wurde, in verschiedenen Phasen der Montage und strengen Tests. Das Ergebnis ist eine sichere, skalierbare und wartungsarme Anwendung, die soforteingesetzt werden kann.

Zitadelle

Die Zitadelle ist eine befestigte Umgebung, in der die Anwendung sicher und effektiv läuft und vor möglichen Angriffen geschützt ist.

Sternwarte

Das Observatorium dient als Überwachungszentrale für alle Dienste und Anwendungen, die in der Cloud laufen.

Abbildung 1-6. Entwicklung von effektiven Cloud-Einrichtungen

Ein reibungsloser Übergang der Anwendungen vom Labor über die Fabrik bis in die Zitadelle ist entscheidend. Derselbe unveränderliche Code sollte automatisch zwischen verschiedenen Einrichtungen transportiert werden.

Die Notwendigkeit von mehr als nur einer Fabrik

In den 90er Jahren, als ich darüber nachdachte, was ich an der Universität studieren sollte, fand ich Inspiration in einer Folge der BBC-Fernsehsendung Troubleshooter. Der imposante Sir John Harvey-Jones besuchte die angeschlagene Oldtimerfirma Morgan und schlug ihr vor, ihre veralteten Fertigungsmethoden durch eine moderne Fabrik zu ersetzen, um die Produktion und die Produktkonsistenz zu verbessern. Von da an war ich von der Idee, die Effizienz von Unternehmen zu verbessern, gefesselt.

Doch ein Jahrzehnt später zeigte eine Folge, dass Morgan sich über Sir Johns Ratschläge hinwegsetzte und stattdessen seine einzigartige Handwerkskunst als Verkaufsargument nutzte. Bemerkenswerterweise hat die Fernsehsendung selbst ihre Handwerkskunst gefördert und neue Kunden angezogen.

Für viele Unternehmen ist die Aussicht auf die Einrichtung einer Factory eine verlockendeLösung, um die oft als chaotisch empfundene Cloud-Landschaft zu rationalisieren. Als Ingenieur fühle ich mich natürlich zu einer solchen systematischen Ordnung hingezogen. Wenn man die Entwicklung jedoch ausschließlich auf eine automatisierte Produktionslinie beschränkt und reglementiert, besteht die Gefahr, dass Innovation und Handwerkskunst, die ein Produkt oft auszeichnen, auf der Strecke bleiben. Einrein fabrikmäßiger Ansatz könnte die kreative Freiheit untergraben, die durch die On-Demand-Cloud ermöglicht wird und die von den Digital Natives geschickt genutzt wird.

Um das volle Potenzial der Cloud zu nutzen, reicht es nicht aus, eine Fabrik zu haben, in der die Tests automatisiert und die Qualitätskonsistenz sichergestellt werden. In diesem Raum können Entwickler/innen in einer sicheren Umgebung und mit einer breiten Palette von Werkzeugen ein Produkt entwickeln und schnell innovieren, bevor sie es in die Fabrik überführen.

Sobald die Fabrik gründlich getestete und vertrauenswürdige Anwendungen produziert hat, ist eine dritte Einrichtung, die Zitadelle, notwendig, in der die Anwendung sicher in einer Produktionsumgebung funktionieren kann.

Das Potenzial für Entwickler

Im Laufe meiner Karriere als Entwickler habe ich sowohl technische als auch bürokratische Hürden erlebt, die meine Produktivität behindert und mit der Zeit meine Moral beeinträchtigt haben. Ein klassisches Beispiel ist das wochenlange Warten auf die Genehmigung oder Bereitstellung einer neuen virtuellen Maschine oder einfach das Warten auf eine Genehmigung.

Als ich vor einigen Jahren begann, die öffentliche Cloud für meine persönlichen Projekte zu nutzen, war ich von dem Unterschied verblüfft. Es fühlte sich an, als ob man ungehindert laufen könnte, anstatt durch den Dreck zu waten. Da die Cloud-Plattformen in den letzten Jahren immer ausgereifter geworden sind, ist diese Erfahrung nur noch besser geworden.

Marie Kondo, die bekannt dafür ist, für Ordnung zu sorgen, unterstreicht auch die Bedeutung von Freude. Für Entwickler/innen ist Freude kein Hirngespinst, sondern kann in einer reibungslosen Umgebung verwirklicht werden, die es ihnen ermöglicht, in einem Zustand des Flow zu arbeiten. Mit einer Cloud Native Plattform, die das Entwicklererlebnis in den Vordergrund stellt, kannst auch du diese Erfahrung genießen.

Ausgestattet mit der Unterstützung eines Labors, einer Fabrik, einer Zitadelle und eines Observatoriums kann eine Einzelperson, die in einem Café mit einem Laptop und einer Internetverbindung sitzt, eine Anwendung entwickeln und bereitstellen, die auf Millionen von Nutzern skaliert werden kann, genau wie die größte multinationale Organisation. Um diese Aufgabe für dich noch einfacher zu machen, liefern sich zahlreiche Cloud-Giganten einen spannenden Wettbewerb.

Als Digital Native-Individuum bist du nicht an ein Rechenzentrum oder herkömmliche Anwendungen gefesselt. Du kannst sofort mit der Entwicklung im Cloud-Native-Stil beginnen. Wenn du die Vorteile eines Digital Natives genießt, kannst du entweder diesen Weg weitergehen oder dein Fachwissen einem Unternehmen zur Verfügung stellen, das einen cloud-nativen Entwicklungsstil einführen möchte. In jedem Fall werden deine Fähigkeiten sehr gefragt und wertvoll sein.

Ich erinnere mich an die Worte eines Konferenzsprechers aus den späten 2000er Jahren, als Smartphones begannen, den Markt zu dominieren. Er beschrieb Mobiltelefonhersteller und Netzbetreiber als in einem Krieg verwickelt, in dem die Entwickler mobiler Apps als Munition dienten. Heute, wo Unternehmen das volle Potenzial der Cloud ausschöpfen wollen, sind Cloud Native Developer die neue Munition.

Dieses Buch fasst meine Erfahrungen zusammen, die ich im Laufe der Jahre gesammelt habe, um dir zu helfen, die gleiche Freude zu erleben, die ich als Cloud-Native-Entwickler erlebt habe - ein Begriff, den ich mit größter Aufrichtigkeit verwende. Es soll dir einen leicht zugänglichen und kostengünstigen Weg bieten, die Produktivität der Cloud Native-Entwicklung als Einzelperson zu erleben, indem du eine Entwicklererfahrung (DX) schaffst, die wirklich für dich funktioniert.

Außerdem bietet es genügend Einblicke in die Belange von Unternehmen, um die Cloud Native Development erfolgreich in einer skalierten Umgebung einzuführen. Wenn du bei der Arbeit das gleiche Maß an Produktivität erreichst wie bei deinen privaten Projekten, kannst du diese Freude auch am Arbeitsplatz erleben.

Zusammenfassung

Cloud Native steht für einen architektonischen Ansatz und eine Entwicklungsmethodik, die das Potenzial der Cloud voll ausschöpft. Sie zeichnet sich durch spezielle Techniken, Tools und Technologien aus, die die Stärken des Cloud Computing verbessern und die Schwächen abmildern sollen. Wichtig ist, dass sich der Anwendungsbereich von Cloud Native nicht auf die Google Cloud oder sogar die öffentliche Cloud beschränkt. Er umfasst ein breites Spektrum an Methoden, die überall dort anwendbar sind, wo cloudähnliche Abstraktionen vorhanden sind.

Um im Cloud-Native-Ökosystem erfolgreich zu sein, müssen Entwickler das Potenzial von vier verschiedenen, aber voneinander abhängigen Einrichtungen nutzen: ein Labor für die innovative Erforschung, eine Fabrik für die rationalisierte Produktionsautomatisierung, eine Zitadelle für die robuste Verteidigung von Live-Anwendungen und ein Observatorium für eine umfassende Systemüberwachung.

Der Rest dieses Buches wird dich durch diese Cloud Native-Methoden führen und dir zeigen, wie du ein Labor, eine Fabrik, eine Zitadelle und ein Observatorium mit Google Cloud erstellen und optimieren kannst. Das Ziel ist es, dich mit dem Wissen und den Strategien auszustatten, die deine Chancen auf einen Cloud Native Erfolg maximieren. Bevor du dich auf diese Reise begibst, wollen wir zunächst untersuchen, warum unter anderem die Google Cloud eine besonders förderliche Umgebung für die Cloud Native Entwicklung bietet.