© DrHitch/Shutterstock.com
Cloud Computing

1 Der Cloud-Native-Stack: Mesos, Kubernetes und Spring Cloud


Cloud-Größen wie Google, Twitter und Netflix haben die Kernbausteine ihrer Infrastruktur quelloffen verfügbar gemacht. Das Resultat aus vielen Jahren Cloud-Erfahrung ist heute frei zugänglich, jeder kann seine eigenen Cloud-nativen Anwendungen entwickeln – Anwendungen, die in der Cloud zuverlässig laufen und fast beliebig skalieren. Die einzelnen Open-Source-Bausteine wachsen zu einem großen Ganzen zusammen, dem Cloud-Native-Stack.

Mit dem Cloud-Native-Stack kann eine Cloud-native Anwendung als Microservices-System entwickelt und betrieben werden. Für hochskalierbare Cloud-Anwendungen ist dieser Stack heute Pflicht, aber letztlich ist jede verteilte Anwendung ein Kandidat für die neue Technologie. In diesem Kapitel beschreiben wir die Anatomie des Cloud-Native-Stacks, nennen Vor- und Nachteile und skizzieren die wichtigsten Konzepte. Am Ende werden Sie entscheiden, ob auch Ihre Anwendung Cloud-native werden soll.

2015 hat sich mit der Cloud Native Computing Foundation [1] ein Gremium rund um Google auf den Schultern der Linux Foundation gebildet, das einen Stack für Cloud-native Anwendungen entwickeln und populär machen will. Sie definiert drei wesentliche Eigenschaften von Cloud-nativen Anwendungen: Sie sind aus Microservices aufgebaut und damit ein verteiltes System aus Microservices. Die Microservices werden in Containern paketiert sowie verteilt, und die Container werden auf den Knoten der Cloud dynamisch zur Ausführung gebracht.

Dies ist nichts anderes als die konsequente Anwendung des Prinzips der Komponentenorientierung bis in den Betrieb: Microservices sind Komponenten mit HTTP-Schnittstellen. Packt man sie in einen Container, so wird die Komponente auch eine eigenständige Einheit im Betrieb:

  • eine eigenständige Releaseeinheit
  • eine eigenständige Deployment-Einheit
  • eine isolierte Laufzeiteinheit
  • eine eigenständige Skalierungseinheit

DevOps wird erst durch diese bis in den Betrieb getragene Komponentenorientierung möglich. Die Kluft zwischen Softwarearchitektur und Betriebsarchitektur verschwindet; beide Welten verwenden denselben Komponentenbegriff. Dies ist ein wesentlicher Grund für die Popularität Cloud-nativer Anwendungen. Doch wie baut man so etwas? Mit einem Cloud-Native-Stack!

Die Anatomie eines Cloud-Native-Stacks

Ein Cloud-Native-Stack ist die Basis von Cloud-nativen Anwendungen. Auf diesem Stack werden Cloud-native Anwendungen entwickelt und betrieben. Es sind mehrere konkrete Cloud-Native-Stacks verfügbar, jedoch lässt sich bei allen eine gemeinsame Anatomie erkennen: Sie bestehen aus drei Schichten sowie Diensten für verteilte Anwendungen, die über alle Schichten hinweg genutzt werden (Abb. 1.1).

image

Abbildung 1.1: Die Anatomie eines Cloud-Native-Stacks

Der Cluster Scheduler hat als erste Schicht die Aufgabe, die einzelnen Container auf Cloud-Knoten zuverlässig und ressourcenschonend auszuführen. Er allokiert Ressourcen und steuert die Ausführung von Containern auf diesen Ressourcen. Ressourcen können sein: virtuelle Maschinen auf einem Rechner, öffentliche oder private Infrastructure-as-a-Service-Clouds oder klassische Serverracks. Der Cluster Scheduler ermittelt die notwendigen Ressourcen über einen geeigneten Scheduling-Algorithmus, allokiert sie für einen bestimmten Zeitraum und führt den Container aus. Re-Scheduling erfolgt bei Bedarf, z. B. beim Ausfall einer Ressource oder beim Freiwerden von alternativen, passenderen Ressourcen. Dann wird die Ausführung eines Containers auf eine andere Ressource verlagert.

Der Cluster Orchestrator als zweite Schicht steuert und überwacht die Ausführung aller Container einer Anwendung. Er verwaltet ganze Anwendungen, während der Cluster Scheduler nur einzelne Container kennt. Die Orchestrierung von Cloud-nativen Anwendungen hat den Anspruch, alle Betriebsprozeduren einer Anwendung zu automatisieren: von Roll-out, Upgrade und der Skalierung bis hin zur Kompensation von Fehlersituationen – getreu dem Motto: „How would you design your infrastructure if you couldn’t login? Ever.“ (Kelsey Hightower, Developer Advocate Google Coud Platform).

Der Cluster Orchestrator beauftragt den Cluster Scheduler mit der Ausführung der einzelnen Container einer Anwendung. Dies ist eine kontinuierliche Aktivität, denn der Orchestrierer muss ständig reagieren, z. B. auf Fehler, Skalierungsbedarf oder Roll-outs.

Die dritte Schicht ist das Microservices-Framework. Es stellt die technische Infrastruktur bereit, auf der Microservices implementiert und ausgeführt werden. Eine Cloud-native Anwendung ist ein verteiltes System aus Microservices. Die Forderungen lauten: Das System muss erstens elastisch und horizontal skalieren, also je nach Bedarf in beliebige...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang