Einführung in cloudbasierte Anwendungen

Ein weiterer Tag im Büro, an dem an „der nächsten großen Sache“ gearbeitet wird.

Ihr Smartphone klingelt. Es ist Ihr freundlicher Personalberater – derjenige, der Sie täglich anruft, um Ihnen neue Möglichkeiten vorzustellen.

Aber dieses Mal ist es anders: Start-up, Eigenkapital und umfangreiche Finanzierung.

Die Erwähnung von Cloud, Microservices und modernster Technologie lässt Sie aus dem Häuschen geraten.

Spulen Sie ein paar Wochen vor und Sie sind jetzt ein neuer Mitarbeiter in einer Konzeptionssitzung, in der Sie eine große eCommerce-Anwendung entwerfen. Sie werden mit den führenden eCommerce-Websites konkurrieren.

Wie werden Sie sie erstellen?

Wenn Sie den Anleitungen der letzten 15 Jahre folgen, werden Sie höchstwahrscheinlich das in Abbildung 1.1 gezeigte System erstellen.

(Abbildung 1-1) . Traditionelles monolithisches Design

Sie erstellen eine große Kernanwendung, die Ihre gesamte Domänenlogik enthält. Sie enthält Module wie „Identität“, „Katalog“, „Bestellung“ und vieles mehr. Sie kommunizieren direkt innerhalb eines einzelnen Serverprozesses miteinander. Die Module teilen sich eine große relationale Datenbank. Der Kern macht Funktionen über eine HTML-Schnittstelle und eine mobile App verfügbar.

Herzlichen Glückwunsch! Sie haben gerade eine monolithische Anwendung erstellt.

Nicht alles ist schlecht. Monolithische Anwendungen bieten einige deutliche Vorteile. Folgendes verläuft bei ihnen beispielsweise recht einfach...

• build
• test
• Bereitstellen
• Problembehandlung
• Vertikales Skalieren

Viele erfolgreiche Apps, die heute existieren, wurden als monolithische Anwendungen erstellt. Die App ist ein Hit und wird ständig weiterentwickelt und um weitere Funktionen ergänzt.

Irgendwann beginnen Sie jedoch, sich unwohl zu fühlen. Sie verlieren die Kontrolle über die Anwendung. Mit der Zeit wird das Gefühl immer intensiver und Sie gelangen schließlich in einen Zustand, der als Fear Cycle bekannt ist:

• Die App ist so überwältigend kompliziert geworden, dass ihn keine Einzelperson mehr versteht.
• Sie haben Angst davor, Änderungen vorzunehmen – jede Änderung hat unbeabsichtigte und kostspielige Nebeneffekte.
• Die Implementierung neuer Features/Fixes ist kompliziert, zeitaufwändig und teuer.
• Jedes Release wird so klein wie möglich und erfordert eine vollständige Bereitstellung der gesamten Anwendung.
• Eine instabile Komponente kann das gesamte System zum Absturz bringen.
• Neue Technologien und Frameworks sind keine Option.
• Es ist schwierig, agile Bereitstellungsmethoden zu implementieren.
• Die architektonische Erosion setzt ein, wenn sich die Codebasis durch immer neue „Schnellkorrekturen“ verschlechtert.
• Schließlich schalten sich die Berater ein und sagen Ihnen, dass Sie die Anwendung neu schreiben sollen.

Kommt Ihnen das bekannt vor?

Viele Organisationen haben sich mit diesem monolithischen Angstzyklus befasst, indem sie einen cloudnativen Ansatz zum Erstellen von Systemen einführen. Abbildung 1-2 zeigt das gleiche System, das unter Anwendung von cloudnativen Techniken und Methoden erstellt wurde.

Abbildung 1–2. Cloudnativer Entwurf

Beachten Sie, wie die Anwendung in eine Reihe von kleinen, isolierten Microservices zerlegt wird. Jeder Dienst ist in sich abgeschlossen und kapselt seinen eigenen Code, seine eigenen Daten und seine eigenen Abhängigkeiten. Jeder Dienst wird in einem Softwarecontainer bereitgestellt und von einem Containerorchestrator verwaltet. Statt einer großen relationalen Datenbank besitzt jeder Dienst einen eigenen Datenspeicher, dessen Typ je nach den Datenanforderungen variiert. Beachten Sie, dass einige Dienste von einer relationalen Datenbank abhängen, andere jedoch von NoSQL-Datenbanken. Ein Dienst speichert seinen Zustand in einem verteilten Cache. Beachten Sie, dass der gesamte Datenverkehr über einen API-Gatewaydienst geleitet wird, der für das Weiterleiten des Datenverkehrs an die zentralen Back-End-Dienste und die Durchsetzung vieler übergreifender Belange verantwortlich ist. Vor allem aber nutzt die Anwendung die Vorteile der Skalierbarkeit, Verfügbarkeit und Ausfallsicherheit moderner Cloudplattformen voll aus.

Cloudnatives Computing

Hmm... Wir haben gerade den Begriff Cloudnativ verwendet. Ihr erster Gedanke könnte sein: „Was bedeutet das genau? Ein weiteres Modewort der Branche, das von Softwareanbietern erfunden wurde, um mehr Produkte zu vermarkten?“

Zum Glück ist es ganz anders, und ich hoffe, dieses Buch wird Sie überzeugen.

Innerhalb kurzer Zeit hat sich „Cloudnativ“ zu einem entscheidenden Trend in der Softwarebranche entwickelt. Es ist eine neue Möglichkeit, große, komplexe Systeme zu konstruieren. Der Ansatz nutzt die Vorteile moderner Softwareentwicklungspraktiken, Technologien und Cloudinfrastrukturen voll aus. „Cloudnativ“ verändert die Art und Weise, wie Sie Systeme entwerfen, implementieren, bereitstellen und betreiben.

Im Gegensatz zu dem ständigen Hype, der unsere Branche antreibt, ist „cloudnativ“ ein echter Trend. Betrachten Sie die Cloud Native Computing Foundation (CNCF), ein Konsortium aus über 400 großen Unternehmen. Seine Aufgabe ist es, cloudnatives Computing über Technologie- und Cloudstapel hinweg zu etablieren. Als eine der einflussreichsten Open-Source-Gruppen beherbergt sie viele der am schnellsten wachsenden Open-Source-Projekte auf GitHub. Zu diesen Projekten gehören Kubernetes, Prometheus, Helm, Envoy und gRPC.

Die CNCF fördert ein Ökosystem von Open-Source und Herstellerneutralität. In diesem Buch werden daher cloudnative Prinzipien, Muster und bewährte Methoden vorgestellt, die technologieunabhängig sind. Gleichzeitig erörtern wir die Dienste und die Infrastruktur, die in der Microsoft Azure-Cloud für den Aufbau von cloudnativen Systemen zur Verfügung stehen.

Was genau ist „cloudnativ“? Lehnen Sie sich zurück, entspannen Sie sich und lassen Sie uns Ihnen helfen, diese neue Welt zu entdecken.