Einführung in cloudeigene Anwendungen

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook, Architecting Cloud Native .NET Applications for Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Ein weiterer Tag, im Büro, arbeiten an "der nächsten großen Sache".

Ihr Handy klingelt. Es ist Ihr freundlicher Recruiter - der, der täglich mit spannenden neuen Möglichkeiten anruft.

Aber diesmal ist es anders: Start-up, Equity und viele Finanzierungen.

Die Erwähnung der Cloud, Microservices und Spitzentechnologie bringt Sie an Ihre Grenzen.

Einige Wochen später sind Sie nun als neuer Mitarbeiter in einer Designsitzung, in der eine bedeutende E-Commerce-Anwendung entworfen wird. Sie werden mit den führenden eCommerce-Websites konkurrieren.

Wie werden Sie es erstellen?

Wenn Sie die Anleitungen aus den letzten 15 Jahren befolgen, erstellen Sie wahrscheinlich das in Abbildung 1.1 dargestellte System.

Abbildung 1-1. Traditionelles monolithisches Design

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

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

Nicht alles ist schlecht. Monolithen bieten einige unterschiedliche Vorteile. Folgendes verläuft bei ihnen beispielsweise recht einfach...

• Bauen
• Test
• Einsetzen
• Fehlersuche
• Vertikal skalieren

Viele erfolgreiche Apps, die heute existieren, wurden als Monolithen erstellt. Die App ist ein Treffer und entwickelt sich nach der Iteration weiter und fügt weitere Funktionen hinzu.

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

• Die App ist so überwältigend kompliziert geworden, dass niemand sie versteht.
• Sie befürchten Änderungen - jede Änderung hat unbeabsichtigte und kostspielige Nebenwirkungen.
• Neue Features/Fixes werden schwierig, zeitaufwendig und teuer zu implementieren.
• Jede Version wird so klein wie möglich und erfordert eine vollständige Bereitstellung der gesamten Anwendung.
• Eine instabile Komponente kann das gesamte System abstürzen.
• Neue Technologien und Frameworks sind keine Option.
• Es ist schwierig, agile Bereitstellungsmethoden zu implementieren.
• Architekturerosion setzt ein, während sich die Codebasis mit nie endenden schnellen Lösungen verschlechtert.
• Schließlich kommen die Berater ein und sagen Ihnen, sie neu zu schreiben.

Klingt vertraut?

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

Abbildung 1-2. Cloudeigenes Design

Beachten Sie, wie die Anwendung in einer Reihe kleiner isolierter Microservices dekompiliert wird. Jeder Dienst ist eigenständig und kapselt seinen eigenen Code, Daten und Abhängigkeiten. Jede wird in einem Softwarecontainer bereitgestellt und von einem Container-Orchestrator verwaltet. Statt einer großen relationalen Datenbank besitzt jeder Dienst einen eigenen Datenspeicher, dessen Typ sich je nach den Datenanforderungen unterscheidet. Beachten Sie, dass einige Dienste von einer relationalen Datenbank abhängen, andere aber von NoSQL-Datenbanken. Ein Dienst speichert seinen Status 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 wichtigsten Back-End-Dienste verantwortlich ist und viele grenzüberschreitende Bedenken erzwingt. Am wichtigsten ist, dass die Anwendung die Skalierbarkeits-, Verfügbarkeits- und Resilienzfunktionen, die in modernen Cloudplattformen zu finden sind, voll ausnutzen.

Cloudnatives Computing

Hmm... Wir haben gerade den Begriff Cloud Native verwendet. Ihr erster Gedanke könnte sein: "Was bedeutet das genau?" Ein weiteres Branchen-Buzzword, das von Softwareanbietern verzehängt wurde, um mehr Inhalte zu vermarkten?"

Glücklicherweise ist es ganz anders, und hoffentlich wird dieses Buch Ihnen helfen, Sie zu überzeugen.

Innerhalb kurzer Zeit ist Cloud Native zu einem treibenden Trend in der Softwarebranche geworden. Es ist eine neue Möglichkeit, große, komplexe Systeme zu konstruieren. Der Ansatz nutzt die modernen Softwareentwicklungsmethoden, -technologien und -cloud-Infrastruktur vollständig. Cloud native ändert die Art und Weise, wie Sie Systeme entwerfen, implementieren, bereitstellen und operationalisieren.

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 von über 400 großen Unternehmen. Das Ziel seiner Charta ist es, Cloud-native Computing in Technologie und Cloud-Stacks allgegenwärtig zu machen. Als einer der einflussreichsten Open-Source-Gruppen hosten sie viele der am schnellsten wachsenden Open Source-Projekte in GitHub. Zu diesen Projekten gehören Kubernetes, Prometheus, Helm, Envoy und gRPC.

Die CNCF fördert ein Ökosystem von Open Source und Anbieterneutralität. Im Anschluss an diese Führung stellt dieses Buch cloudeigene Prinzipien, Muster und bewährte Methoden dar, die technologieagnostisch sind. Gleichzeitig besprechen wir die Dienste und Infrastruktur, die in der Microsoft Azure-Cloud zum Erstellen von cloudeigenen Systemen zur Verfügung stehen.

Was genau ist Cloud Native? Lehnen Sie sich zurück, entspannen Sie sich und lassen Sie uns helfen, diese neue Welt zu erkunden.

ZurückWeiter