© DrHitch/Shutterstock.com
Shortcuts
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.

Shortcut Autorenteam


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 Die Anatomie eines Cloud-Native-StacksEin 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).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 ...

Shortcuts
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.

Shortcut Autorenteam


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 Die Anatomie eines Cloud-Native-StacksEin 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).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 ...

Neugierig geworden?


    
Loading...

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