Der ultimative Cloud Native Tech Stack für 2022

Die moderne Cloud-native Technologielandschaft ist sehr vielfältig, aber dies sind die Tools und Technologien, die wir schätzen und am häufigsten verwenden!

CloudUPDATED ON Dezember 8, 2021

John Adam K&C head of marketing

Author

cover image for blog on theme of cloud native tech stacks

Der Cloud-native Tech-Stack ist in den letzten Jahren aufgeblüht und bietet nun eine Auswahl, die ein wenig mehr dem entspricht, was wir von Webentwicklungs-Stacks gewöhnt sind. Von Containerisierung und Orchestrierung bis hin zu Überwachung, Protokollierung, Sicherheit und app-spezifischen Anforderungen wie Streaming und Messaging gibt es jetzt fast eine Auswahl an Technologien und Tools.

Die Wahl, was in den Cloud-nativen Tech-Stack für die Entwicklung einer bestimmten Anwendung aufgenommen wird, variiert oft von Projekt zu Projekt und hängt von den spezifischen Bedürfnissen, Prioritäten und Eigenschaften ab.

Jeder moderne Laptop bietet dieselben Kernfunktionen, aber seine eigenen einzigartigen Spezifikationen, Qualitäten und Merkmale. Und jede öffentliche Cloud-Plattform bietet ebenfalls “ Must-Have“-Dienste und -Funktionen, hat aber ihre eigenen einzigartigen Angebote oder Eigenschaften, die sie zur optimalen oder bevorzugten Wahl für eine bestimmte Arbeitslast machen. Ebenso wird eine Auswahl innerhalb des Cloud-nativen Technologie-Stacks für ein Projekt am besten geeignet sein, aber bei einer anderen Gelegenheit einer besser geeigneten Alternative Platz machen.

Dennoch haben wir bei K&C unsere Präferenzen, wenn es um die Technologien und Tools geht, die wir bei der Cloud-Native-Entwicklung einsetzen. Die Tools und Technologien, auf die wir uns am häufigsten verlassen, es sei denn, die besonderen Anforderungen eines Projekts bedeuten, dass eine andere Wahl besser geeignet ist.

Dies ist unser ultimativer nativer Cloud-Tech-Stack für 2022!

Agile und DevOps-Entwickler, Teamverstärkung und Berater

Nach Ihren individuellen Bedürfnissen!

Docker für die Containerisierung

Die Rolle von Docker in einer Cloud-nativen DevOps-Architektur ist einfach – es macht die Containerisierung einfach. Das Schöne an Containern ist, dass ein gut abgestimmtes Containersystem 400 % bis 600 % mehr Serveranwendungsinstanzen als VMs auf derselben Hardware ermöglicht. Und sie eignen sich für die DevOps-Methodik der kontinuierlichen Integration und des kontinuierlichen Deployments (CI/CD), auf die wir gleich noch zu sprechen kommen werden.

Docker ermöglicht es unseren Entwicklern, jede Anwendung als leichtgewichtigen, portablen, autarken Container zu verpacken, auszuliefern und auszuführen, um sie praktisch (Wortspiel beabsichtigt!) überall auszuführen.

Die Zusammenarbeit von Docker mit anderen großen Container-Anbietern wie Canonical, Google, Red Hat und Parallels bei der Open-Source-Schlüsselkomponente libcontainer hat auch zu einer sehr praktischen Standardisierung von Containern geführt.

Cloud Native Tech Stack Docker For Containerisation

Docker Alternativen

Es gibt keine wirklichen Alternativen zu dem, was Docker in den Cloud-nativen Tech-Stack einbringt. Andere LXC-basierte Container-Implementierungen wie CoreOS von Redhat, Rkt oder LXD von Canonical sind keine Konkurrenten, sondern Weiterentwicklungen von LXC.

Kubernetes für die Orchestration

Kubernetes ist ein herstellerunabhängiges Cluster- und Container-Verwaltungstool, das eine „Plattform für die Automatisierung der Bereitstellung, Skalierung und des Betriebs von Anwendungscontainern in Host-Clustern“ bietet und aus einer 2014 von Google ins Leben gerufenen Open-Source-Initiative hervorgegangen ist. Der Internetgigant nutzt Kubernetes selbst seit 10 Jahren für den Betrieb großer Systeme – ein mehr als ausreichender Beweis für die Wirksamkeit des Tools.

Kubernetes ist ein integraler Bestandteil unseres Cloud-nativen Technologie-Stacks und vereinfacht den Betrieb und die Architektur mit dem Ergebnis, dass die Kosten für eine Cloud-native Strategie gesenkt werden – insbesondere im Kontext von Multi- oder Hybrid-Cloud-Infrastrukturen.

Wie bei den virtuellen Maschinen, die sie ersetzen, besteht auch bei Containern das Problem darin, dass sie im Auge behalten werden müssen. Verwaiste Container, die keinen Beitrag zu einer Anwendung leisten, können die Rechnungen für CPU und Speicher in der Cloud in die Höhe treiben. Möglicherweise benötigen sie auch mehr Arbeitsspeicher, CPU oder Speicherplatz oder sie müssen abgeschaltet werden, wenn die Last nachlässt. All dies erfordert eine Container-Orchestrierung – und genau das ist es, was Kubernetes für die Cloud-native Entwicklung mitbringt.

Die Rolle von Kubernetes besteht darin, eine weitere Abstraktionsebene zwischen Maschinen, Containern, Speicher und Netzwerken und ihrer physischen Implementierung hinzuzufügen, indem es eine einheitliche Schnittstelle für die Bereitstellung von Containern für alle Arten von Clouds, virtuellen und physischen Maschinen bietet.

Kubernetes Architektur

Cloud Native Tech Stack Kubernetes for Container Orchestration

 

Kubernetes Alternativen

Amazon ECS kann eine Alternative zu Kubernetes für eine Cloud-native Architektur bilden, die jedoch ausschließlich AWS als Anbieter nutzt. Eine anbieterunabhängige Alternative ist Docker Swarm. Wie Kubernetes ist Swarm produktionsreif und hat eine ähnliche Rolle und ähnliche Funktionen, allerdings mit einem anderen Ansatz. Docker Swarm verfügt über dieselbe API und Struktur wie Docker selbst, während Kubernetes eher ein generalistisches Tool ist und mit anderen Container-Engines zusammenarbeiten kann, was eine größere Flexibilität ermöglicht.

Entwickler, die Kubernetes verwenden, müssen einen neuen Befehlssatz erlernen, der jedoch präzisere Befehle für die Domain- und Clusterverwaltung ermöglicht. Es ist einfacher, Testcluster mit Swarm zu erstellen und bereitzustellen. Kubernetes bietet jedoch dank seiner Namespace-Trennung eine einheitliche Möglichkeit, einen einzelnen Cluster für die Produktion, das Staging und die Entwicklung zu verwenden, was bedeutet, dass es in den meisten Fällen nicht notwendig ist, einen Cluster speziell für Tests zu erstellen.

Swarm hat die Funktionen im Laufe der Jahre schnell verbessert, doch wir sind nach wie vor der Meinung, dass Kubernetes für erfahrene Entwickler mehr Flexibilität und Präzision bietet.

Prometheus für das Kubernetes Monitoring (Überwachung)

Prometheus ist die Zeitserien-Datenbank- und Monitoring-Lösung unserer Wahl in unserem Cloud-nativen Tech-Stack. Die Überwachung von Anwendungen und ihren Servern ist ein integraler Bestandteil des DevOps-Prozesses geworden. Anwendungsausnahmen, Server-CPU- und Speichernutzung, Speicherspitzen und Dienste, die innerhalb einer Anwendung nicht reagieren, müssen im Zusammenhang mit der Leistungs- und Cloud-Kostenverwaltung sorgfältig überwacht werden.

Die wichtigsten Funktionen und Vorteile von Prometheus sind:

Dimensionale Datenmodellierung – Zeitreihen werden durch einen Metriknamen und Schlüssel-Wert-Paare identifiziert.

Abfragen – Zeitreihendaten werden gesammelt und in Ad-hoc-alerts, Diagrammen und Tabellen organisiert.

Visualisierung – mehrere Datenvisualisierungsmodi sind ein großes Plus von Prometheus zusammen mit dem integrierten Expression Browser, der Grafana-Integration und einer Konsolenvorlagensprache.

Speichereffizienz – Das benutzerdefinierte Format von Prometheus bietet effiziente Zeitseriendaten, die sowohl im Speicher als auch auf der lokalen Festplatte gespeichert werden. Funktionales Sharding und Föderation ermöglichen eine optimale Skalierung.

Betriebliche Einfachheit – Die Server sind unabhängig, was die Zuverlässigkeit durch lokale Speicherung verbessert. Go-Binärdateien sind statisch verknüpft und die Bereitstellung ist ein einfacher Prozess.

Alerting – Alerts sind präzise, erhalten dimensionale Daten und basieren auf der flexiblen PromQL von Prometheus.

Mehrere Client-Bibliotheken – Client-Bibliotheken erleichtern die Instrumentierung von Diensten. >Derzeit werden mehr als 10 Bibliotheken unterstützt, und auch benutzerdefinierte Bibliotheken lassen sich einfach integrieren.

Integration – Daten von Drittanbietern wie Docker, StatsD, HAProxy, JMX-Metriken und Systemstatistiken werden über vorhandene Exporter in Prometheus eingebunden.

Prometheus Operator

Mit Prometheus Operator können Überwachungsinstanzen als Kubernetes-Ressourcen definiert und verwaltet werden Es gibt eine geringe Schwelle für die effektive Definition der Überwachung Ihrer Anwendungen durch den Operator, sofern Sie bereits wissen, wie man Kubernetes verwaltet.

Kubernetes Monitoring mit Prometheus – Architektur

Prometheus for Monitoring Cloud Native Tech Stack

Prometheus Alternativen

Graphite und InfluxDB sind Alternativen zu Prometheus in einer Cloud-nativen oder dynamischen Umgebung, obwohl keine einzige Alternative die gleiche Vielfalt an Funktionalitäten, Merkmalen und Anwendungen wie Prometheus bietet. Außerdem sind sie im Allgemeinen schwieriger zu integrieren. Jede hat jedoch ihre Stärken.

Graphite kann beispielsweise die bessere Wahl für eine Clusterlösung sein, die Verlaufsdaten langfristig speichern kann. Die Stärken von InfluxDB liegen in der Ereignisprotokollierung, der langfristigen Datenspeicherung und einer konsistenten Sicht auf die Daten zwischen den Replikaten.

Aber abgesehen von speziellen Anwendungsfällen, bei denen diese Anforderungen Vorrang haben sollten, ist Prometheus das Monitoring-Tool der Wahl im nativen Cloud-Technologie-Stack von K&C.

Istio als unser Kubernetes-Service-Mesh

Das Istio-Service-Mesh, ein weiteres Open-Source-Projekt von Google, das für die Zusammenarbeit mit Kubernetes entwickelt wurde, bändigt die Komplexität der Verwaltung von Netzwerken, die zur Verbindung von Microservices verwendet werden. Eine Microservices-Architektur löst zwar viele der Probleme, die sich aus der Cloud und insbesondere der Multi-Cloud-Bereitstellung ergeben, bringt aber auch neue Herausforderungen mit sich.

Entwicklung, Updates und Skalierung werden durch die Aufteilung einer Anwendung in Microservices erleichtert. Aber diese Microservices sind bewegliche Teile eines größeren Ganzen und müssen miteinander verbunden und gesichert werden. Die Verwaltung von Netzwerkdiensten wie Lastausgleich, Verkehrsmanagement, Authentifizierung und Autorisierung wird komplex. Der vernetzte Raum zwischen den Microservices innerhalb eines Kubernetes-Clusters ist das Service-Mesh, dessen Aufgabe es ist:

  1. Entlastung der Dienste von der Notwendigkeit, sich mit den Details der effektiven Verwaltung des Netzverkehrs wie Lastausgleich, Routing, Wiederholungen zu befassen.
  2. Bereitstellung einer Abstraktionsebene für Administratoren, die die Umsetzung von Entscheidungen auf hoher Ebene in Bezug auf den Netzwerkverkehr eines Clusters vereinfacht, z. B. Richtlinienkontrollen, Metriken und Protokollierung, Diensterkennung, sichere Kommunikation zwischen Diensten usw.

Die Datenebene von Istio kümmert sich um den Netzwerkverkehr zwischen den Diensten im Mesh und dem Kontrollbereich Istio verwaltet und sichert die Datenebene.

Istio Architektur (Quelle)

Istio as the Service Mesh In Cloud Native Technology Stack

Die Abstraktion ist der Hauptvorteil von Istio. Abstraktion bedeutet, dass programmatische Änderungen am Mesh über Istio-Befehle durchgeführt werden können, was bedeutet, dass die Dienste selbst nicht neu entwickelt werden müssen, wenn sich Netzwerkrichtlinien oder Quoten ändern. Auch die Netzwerkbereiche zwischen den Diensten müssen nicht direkt aktualisiert werden.

Weitere Vorteile von Istio sind, dass nicht-destruktive Änderungen an der Netzwerkkonfiguration des Clusters von oben nach unten ausgerollt und leicht zurückgenommen werden können. Darüber hinaus bietet Istio detaillierte Statistiken und Berichte darüber, was zwischen Containern und Clusterknoten vor sich geht. Das bedeutet, dass alle kontraproduktiven Aktualisierungen schnell erkannt werden.

Und schließlich ist Istio zwar am direktesten und tiefsten mit Kubernetes integriert, aber dank seiner offenen Standards ist es plattformunabhängig und kann auch mit anderen Orchestrierungssystemen verwendet werden.

Istio Alternativen

Die wichtigsten Alternativen zu Istio als Dienstnetz sind Linkerd, Envoy und Consul von Hashicorp. Consul Connect ist einfach, flexibel und wird von Hashicorp stark unterstützt. Wir verwenden es oft als Alternative zu Istio in Projekten, in denen der Kunde Hashicorp-Produkte bevorzugt oder unsere Entwickler es für den jeweiligen Anwendungsfall präferieren.

Linkerd ist ebenfalls einfach und wird von seinen Entwicklern Bouyant gut unterstützt. Obwohl es an sich nichts auszusetzen gibt, bevorzugen wir die inhärente Kompatibilität von Istio mit Kubernetes. Das und gut implementierte Funktionen (sowie die Tatsache, dass Istio unserer Meinung nach bestens positioniert ist, um den Markt anzuführen, und daher in höherem Maße zukunftssicher ist) bedeuten, dass Istio seinen Platz in unserem Dream Team Cloud Native Tech Stack für 2022 sicher hat.

Jenkins für CI/CD-Automatisierung

Bei der CI/CD-Automatisierung ist die Wahl schwieriger. Wir verwenden sowohl Jenkins als auch GitLab, wobei die Präferenz auf das jeweilige Projekt zurückzuführen ist. Als allgemeine Faustregel gilt, dass wir uns bei größeren Projekten meist für Jenkins und bei mittleren und kleineren Projekten für GitLab entscheiden.

Jenkins ermöglicht die Automatisierung von Continuous Integration und Continuous Delivery (CI/CD) über Kombinationen von Sprachen und Quellcode-Repositories hinweg. Es ist zwar immer noch notwendig, Skripte für die verschiedenen Schritte des Prozesses zu schreiben, aber Jenkins beschleunigt und sichert die Pipelines von Build-, Test- und Deployment-Tools.

Jenkins beseitigt das DevOps-Problem, dass einzelne Entwickler vor der Übergabe ihres Codes auf einem lokalen Rechner bauen und testen müssen. Dies ist ein großes Problem, wenn ein Team von Entwicklern neuen Code festschreibt. Ihre Änderungen werden isoliert und nicht in Kombination getestet. Das konnte oft zu Problemen führen, wenn mehrere Aktualisierungen, die alle isoliert erstellt und getestet wurden, übertragen werden mussten.

Jenkins ist ein Open-Source-Automatisierungsserver in und für Java, der es DevOps-Teams ermöglicht, die kombinierten Auswirkungen von Codeänderungen zu testen, bevor sie in das Live-Repository übertragen werden. Jenkins wird mit 1.600 Plug-ins für Plattformen, Benutzeroberfläche, Verwaltung, Quellcode-Management und Build-Management geliefert.

Jenkins unterstützt auch Versionskontrollwerkzeuge wie Subversion, Git, Mercurial und Maven.

Wenn Jenkins mit Docker integriert ist, wird die Anwendung in einem Docker-Container ausgeführt. Jenkins erstellt das Docker-Image mit Ihrer Anwendung und stellt es entweder in einer öffentlichen oder privaten Docker-Registry bereit.

Jenkins eignet sich hervorragend für große Projekte mit einem hohen Maß an Anpassung. Sein größter Nachteil ist, dass es auf einem Server ausgeführt werden muss, der Aufmerksamkeit, Updates und Wartung erfordert.

Jenkins Pros

  • Selbst gehostet, d. h. volle Kontrolle über die Arbeitsbereiche
  • Workspace-Kontrolle unterstützt durch einfaches Debugging von Läufern
  • Starke Verwaltung von Anmeldeinformationen
  • Umfangreiche Plugin-Bibliothek

Jenkins Cons

  • Die Einrichtung und Wartung des Servers kann für kleine Projekte zu einem unerschwinglichen Aufwand werden.
  • Komplexe Plugin-Integration
  • Für jede Umgebung wird eine neue Pipeline benötigt, z. B. Produktion/Testing

Jenkins Architektur

Istio as the Service Mesh In Cloud Native Technology Stack

GitLab als Jenkins-Alternative

GitLab ist mittlerweile eine ernstzunehmende Alternative zu Jenkins und kann das von uns bevorzugte Tool für bestimmte, meist kleinere Projekte sein. GitLab bietet sich für kleine bis mittelgroße Projekte dank der kurzen Einrichtungszeit und der Flexibilität bei der einfachen Integration neuer Jobs an. In der agilen Entwicklung sind die Granularität der grafischen Oberfläche GitLabs und die flexible Anpassung besondere Vorteile.

Für große Projekte kann die Struktur aufgrund der Granularität und der zentralen Konfiguration in der gitlab-ci.yml jedoch schnell problematisch werden.

Gitlab Pros

  • Starke Docker-Integration
  • Parallele Auftragsausführung in Phasen
  • Pipeline mit gerichteten azyklischen Graphen
  • Das Hinzufügen von Aufträgen ist einfach
  • Zusammenführungsanfragen sind integriert
  • Gleichzeitige Läufer ermöglichen Skalierbarkeit

Gitlab Cons

  • Artefakte müssen für jeden einzelnen Auftrag definiert sowie hoch- und runtergeladen werden.
  • Das Testen des zusammengefassten Zweigs kann nicht vor der eigentlichen Zusammenführung erfolgen.
  • Keine Unterstützung für Stufen innerhalb von Stufen

Natürlich gibt es noch viele andere Technologien und Tools, die wir mehr oder weniger häufig bei der Entwicklung in der Cloud für die Cloud einsetzen. Aber diese sind der Kern der meisten Cloud-Entwicklungsprojekte, an denen wir bei K&C arbeiten. Wenn Sie ein anstehendes Cloud-natives Entwicklungsprojekt besprechen möchten, nehmen Sie gerne Kontakt mit uns auf.

K&C - Wir schaffen innovative Tech-Lösungen seit über 20 Jahren.

Kontaktieren Sie uns, um Ihre individuellen Bedürfnisse oder Ihr nächstes Projekt zu diskutieren.