Aliaksandr Marko - stock.adobe.c
So stellen Admins sich auf einen Wechsel zu Cloud-native ein
Cloud-native beginnt mit den Entwicklungsmethoden. Doch danach müssen Adminsitratoren die resultierenden Architekturen und Anwendungen verwalten. Wir erklären, worauf es ankommt.
Cloud-native Entwicklungstechniken werden viel diskutiert, dabei kommen aber die Auswirkungen auf den Alltag der Administratoren häufig zu kurz. Was müssen sie beachten, wenn ihr Unternehmen auf Cloud-native Entwicklung umstellen?
Cloud-nativ beschreibt zunächst einfach nur Anwendungen, die Cloud-Vorteile wie die folgenden nutzen
- Elastizität bei variabler Belastung;
- Resilienz bei Fehlern;
- Wiederverwendbarkeit von Komponenten; und
- Hosting-Unabhängigkeit zur Unterstützung von Hybrid- und Multi-Cloud-Bereitstellungen.
Um diese Vorteile zu erzielen, müssen sowohl die Softwareentwicklung als auch die Cloud-Infrastruktur dazu beitragen – einschließlich der Middleware-Tools.
Cloud-native Technologie ist eine symbiotische Mischung aus Entwicklungspraktiken, Middleware, Servern und Netzwerktechnologie. Es verlagert das Denken von der Anwendungsbereitstellung hin zur Bereitstellung von Funktionskomponenten, die in Anwendungen zusammengestellt werden. Diese veränderte Denkweise muss Änderungen der Entwicklungspraktiken und der Gesamtkonzeption von Administratoren betreuten Infrastruktur oder Ressourcen nach sich ziehen.
Betrachten Sie Ihren Cloud-Anbieter sorgfältig
Die erste – und vielleicht größte – Auswirkung auf den Betrieb eines Cloud-nativen Modells besteht darin, dass Sie für die Cloud-Plattform und nicht für Anwendungen planen müssen. Damit Cloud-native Ansätze funktionieren, müssen Anwendungen einen gemeinsamen Satz von Tools verwenden, die Bereitstellung und Aktualisierung konsistent unterstützen, unabhängig davon, wo Komponenten ausgeführt werden. Die Anforderungen dieser Tools an die Software müssen dann an das Entwicklerteam weitergeleitet werden, damit die zu entwickelnde Anwendung auf Ihre Plattform passt.
Anwendungen erfordern eine DevOps-Forward-Kommunikation zwischen Entwicklern und Administratoren, während Cloud-native Umgebungen OpsDev- oder Ops-zentriertes Denken erfordern. Führen Sie die folgenden zwei Schritte aus, um einen Cloud-nativen Betriebsplan zu implementieren:
1. Entscheiden Sie sich für einen Mechanismus für den Microservice-Zugriff.
Es gibt zwei grundsätzliche Möglichkeiten hierfür: API-Gateways oder Broker und Service Mesh. API-Gateways sind den meisten Unternehmen bekannt, die Service-Mesh-Technologie ist jedoch flexibler und verlangt auf lange Sicht wahrscheinlich den geringsten Aufwand bei der Verwaltung. Je stärker ein Unternehmen sich hin zu Cloud-native entwickelt – und je schneller das vonstattengeht, desto wahrscheinlicher ist es, dass ein Service Mesh erforderlich wird.
2. Maximieren Sie die Ressourcenäquivalenz.
Wie jede Software haben auch Microservices Software- und Hardwareanforderungen. In Cloud-nativen Bereitstellungen werden häufig Orchestrierungsfeatures wie die Knotenaffinitäten sowie Taints und Toleranzen von Kubernetes verwendet, um Microservices in Richtung geeigneter Hostingpunkte zu lenken. Die Zusammenarbeit von OpsDev zielt darauf ab, eine angemessene Anzahl von Hosting-Klassen zu etablieren, in die alle Microservices passen. Ohne diese Vorrichtung ist der Prozess zum Steuern von Pods zu Knoten komplex, teuer und fehleranfällig.
Damit hören die Bemühungen um eine Maximierung der Ressourcenäquivalenz jedoch noch lange nicht auf. Hybrid- und Multi-Cloud-Bereitstellungen erfordern Ressourcentools, die über verschiedene Hosting-Plattformen hinweg funktionieren. Diese Plattformunterschiede sollten sich nicht auf Hosting-Entscheidungen auswirken, da sonst der Ressourcenpool Ihres Unternehmens unterschiedliche Leistungsmerkmale in den verschiedenen Domänen bietet.
Wählen Sie Cloud-Dienste und -Funktionen – und lokale Hosting-Funktionen – mit dem Ziel der Einheitlichkeit. Master-Orchestratoren wie Google Anthos oder AWS Outposts, sind in der Lage, die Bereitstellung in allen Clouds und Rechenzentren zu verwalten.
Netzwerkarchitektur ist der Schlüssel
Die Vernetzung ist das letzte Thema, das bei der Ressourcengleichheit angegangen werden muss. Unternehmen verfügen fast immer über VPNs, die Benutzer mit den APIs verbinden, um den Zugriff auf Anwendungen zu ermöglichen. Diese VPNs erstellen einen Benutzeradressraum, der gewartet werden muss, um so statisch wie möglich zu bleiben. Öffentliche Cloud-Dienste und Anwendungshosting basieren normalerweise auf einem privaten Adressraum, der die Kommunikation zwischen Anwendungskomponenten ermöglicht.
Im Zusammenhang mit Cloud-natives bezeichnet man das als eine Microservices-Architektur. Wenn Anwendungskomponenten außerhalb des eigenen Adressraums der Anwendung kommunizieren, kann eine Adressänderung erforderlich sein, um eine Verbindung herzustellen.
Wenn die Menge des Datenverkehrs zwischen den Komponenten zunimmt, verkompliziert dies meistens das Konnektivitätsmanagement. Ein privater Adressraum oder ein abgetrennter Teil des Firmen-VPN verbindet alle Cloud-nativen Komponenten über ein API-Gateway oder ein Service Mesh. Dieser neue Komponentenadressraum kann dann mit dem Benutzeradressraum verknüpft werden, in dem Benutzer-APIs mit in Spiel kommen.
Da mit dem Aufbau einer konsistenten Plattform für Cloud-native Anwendungen in Hybrid- und Multi-Cloud-Umgebungen eine große Zahl kleinteiliger Strukturen verbunden ist, ist es wichtig, das Adressierungs-Framework herauszuarbeiten. Dokumentieren Sie außerdem die Hosting-Klassen, für die Ihr IT-Team betrieblichen Support anbieten möchte, und wie Affinitäten, Taints und Toleranzen Pods richtig zu Knoten lenken.
Pflegen Sie einen offenen Dialog mit dem Entwicklungsteam und setzen Sie den OpsDev-Flow fort, wenn neue Anwendungsmodelle entstehen. Ein Cloud-nativer Plan ist eine Technologiepartnerschaft, aber in erster Linie eine organisatorische. Ohne einen effektiven und konstanten Austausch zu Plänen und Möglichkeiten ist jedes Cloud-native Projekt mit einem noch so erfolgsversprechenden Start langfristig zum Scheitern verurteilt.
