Eine kurze Geschichte von Cloud Native
Je nachdem, wen Sie fragen, kann der Begriff “Cloud Native” viele verschiedene Bedeutungen haben. Vor zehn Jahren wurde der Begriff “Cloud Native” von Unternehmen wie Netflix geprägt, die Cloud-Technologien nutzten und sich von einem Versandhaus zu einem der weltweit größten Netzwerke für die Bereitstellung von Inhalten auf Abruf entwickelten. Netflix leistete Pionierarbeit für das, was wir heute als Cloud Native bezeichnen, indem es die Art und Weise, wie wir alle Softwareentwicklung betreiben wollen, neu erfand, transformierte und skalierte. Hier ist eine VPN für Netflix um ihre Sicherheit im Internet zu erhöhen. Angesichts des phänomenalen Erfolgs von Netflix und seiner Fähigkeit, seinen Kunden mehr Funktionen schneller zur Verfügung zu stellen, wollen Unternehmen wissen, wie die Cloud Native-Technologie Netflix zu einem so großen Wettbewerbsvorteil verholfen hat.
Warum ist Cloud Native also so wichtig?
Im Kern ist der Begriff Cloud Native eine Möglichkeit, die Geschwindigkeit Ihres Unternehmens zu erhöhen und eine Methode, Ihre Teams so zu strukturieren, dass sie die Vorteile der Automatisierung und Skalierbarkeit nutzen können, die Cloud Native Technologien wie Kubernetes bieten.
Cloud-native Entwicklung und Architektur: Wie sieht sie aus?
Monolith vs. Microservices-Architekturen
Nach einer katastrophalen Veröffentlichung mit einem falsch gesetzten Semikolon stellte Adrian Cockcroft, ehemaliger Cloud-Architekt von Netflix, die gesamte Architektur von einem Monolithen auf Microservices um.
Das Problem einer monolithischen Architektur besteht darin, dass neue Funktionen, die entwickelt und getestet werden, nur mit großem Aufwand in die Produktion übernommen werden können:
-
Mehrere Teams müssen ihre Codeänderungen koordinieren.
-
Die Bereitstellung mehrerer Funktionen auf einmal erforderte eine Menge Integrations- und Funktionstests im Vorfeld.
-
Die Entwicklungsteams waren auf die Verwendung von ein oder zwei Sprachen beschränkt.
Die Umstellung auf Microservices ermöglichte es den Netflix-Entwicklern, ihren Kunden neue Funktionen viel schneller zur Verfügung zu stellen.
Monolithische Architektur vs. Microservices-Architektur
Microservices führen zu einer lose gekoppelten serviceorientierten Architektur mit begrenzten Kontexten. Das heißt, wenn jeder Dienst gleichzeitig aktualisiert werden muss, handelt es sich nicht um eine “lose Kopplung”, und wenn Sie zu viel über die umliegenden Dienste wissen müssen, haben Sie keine “begrenzten Kontexte”. Siehe auch den ursprünglichen Blog von Martin Fowler und James Lewis, in dem die Definition diskutiert wird: “Microservices: eine Definition dieses neuen Architekturbegriffs”.
Microservices, Docker und Kubernetes
Docker-Container eignen sich sehr gut für Microservices. Indem Sie Ihre Microservices in separaten Containern ausführen, können sie alle unabhängig voneinander und sogar in verschiedenen Sprachen bereitgestellt werden, wenn Sie dies wünschen. Die Containerisierung beseitigt das Risiko von Reibungen oder Konflikten zwischen Sprachen, Bibliotheken oder Frameworks. Da Container portabel sind und isoliert voneinander arbeiten können, ist es sehr einfach, eine Microservices-Architektur mit Containern zu erstellen und sie bei Bedarf in eine andere Umgebung zu verschieben.
Container-Orchestrierung
Sobald Sie eine große Anzahl von Microservices haben, die alle in Docker-Containern laufen, brauchen Sie eine Möglichkeit, diese Container zu verwalten oder zu orchestrieren, damit sie als Anwendung Sinn ergeben. Hierfür benötigen Sie einen Orchestrator (Cluster-Manager) wie Kubernetes oder Docker Swarm oder andere.
Früher musste man sich entscheiden, welchen Orchestrator man verwenden wollte, aber jetzt sind die Orchestrierungskriege entschieden und Kubernetes von Google hat sich durchgesetzt. Alle großen Cloud-Anbieter unterstützen Kubernetes mit einfach zu installierenden Lösungen.
Das Wesentliche an dieser Diskussion ist, dass die meisten Unternehmen, wenn sie wettbewerbsfähig sein wollen, ihre Anwendungen um Microservices herum aufbauen und sie in einem Kubernetes-Cluster ausführen müssen – obwohl einige Unternehmen auch Docker-Container auf anderen Orchestrierern ausführen.
Bereitstellungen automatisieren
Wenn die Anwendungen in Containern laufen und in Kubernetes orchestriert werden, besteht der nächste Schritt darin, die Bereitstellung zu automatisieren. Ein kontinuierlich automatisierter Fluss von Funktionen unterscheidet DevOps von anderen Softwareentwicklungsphilosophien und -praktiken wie dem Wasserfallmodell, bei dem die Entwicklung in einer geordneten Abfolge von Phasen erfolgt.
Kontinuierlich bedeutet nicht, dass Ingenieure rund um die Uhr an der Aktualisierung des Codes arbeiten oder dass sie bei jeder Änderung einer Codezeile eine Aktualisierung bereitstellen. Kontinuierlich in diesem Sinne bedeutet, dass Softwareänderungen und neue Funktionen regelmäßig über eine automatisierte Pipeline für kontinuierliche Integration und kontinuierliche Bereitstellung (CICD) bereitgestellt werden. Weitere DevOps-Strategien für den Aufbau von CICD-Pipelines finden Sie in dem eBook: Der praktische Leitfaden zu GitOps.
Überwachung
Mit Containern und Microservices müssen Überwachungslösungen mehr Dienste und Server als je zuvor verwalten. Es müssen nicht nur mehr Objekte verwaltet werden, sondern Cloud-native Anwendungen erzeugen auch eine Menge zusätzlicher Daten, die überwacht werden müssen.
Das Sammeln von Daten aus einer Umgebung, die aus so vielen beweglichen Teilen besteht, ist komplex. Prometheus ist die beste moderne Lösung für diese dynamischen Cloud-Umgebungen. Es wurde speziell für die Überwachung von Anwendungen und Microservices entwickelt, die in Containern in großem Umfang ausgeführt werden, und ist nativ für containerisierte Umgebungen. Siehe den Artikel – Kubernetes-Überwachung mit Prometheus.
Kulturelle Veränderungen
Der Erfolg der Implementierung von nativer Cloud-Technologie und DevOps-Best-Practices in Ihrem Unternehmen hängt stark von der bestehenden Unternehmenskultur ab. Interne Teams müssen nicht nur lernen, funktionsübergreifende Methoden zu übernehmen, die sicherstellen, dass die Software in einem kontinuierlichen Rhythmus iteriert wird, sondern auch, dass sie die Geschäftsziele des Unternehmens ergänzt. Die eigentliche Umstellung auf Cloud Native mag der einfachste Teil Ihrer Reise sein; diese Änderungen durchzusetzen und sie im gesamten Unternehmen zu verbreiten, könnte jedoch der schwierigste Teil des Prozesses sein.
