Spring Cloud (Netflix OSS) vs. Kubernetes

In der Praxis hat sich das Spring Framework als das Microservices Framework durchgesetzt. Pivotal (das Unternehmen hinter Spring) bietet mit dem Spring Cloud Projekt eine supportete Version des Netflix OSS Stacks. Dieses wiederum bietet eben jene zur Umsetzung von Microservices benötigten Technologien:

  • Zuul (API Gateway, Edge Service)
  • Eureka (Service Discovery)
  • Ribbon (IPC Library + Load Balancer)
  • etc.

Darüber hinaus liefert Spring Cloud Config den dedizierten Konfigurations-Service, der mit Hilfe eines Git-Repositories automatisch (und vor allem versioniert) unsere SpringBoot-Services für die verschiedenen Umgebungen (Dev, Test, Pilot, Prod, …) konfiguriert.

Metriken zum Zustand der Spring Boot-Applikationen erhalten wir über die Actuator Endpunkte, die bei Bedarf über die (gute alte) application.properties enabled werden können.

Weitere Projekte zu den Themen Messaging, Security (SSO), Resilience, Logging, Monitoring und Tracing bietet Spring Cloud selbstverständlich ebenfalls, sodass sich eine recht homogene Entwicklungslandschaft zum Entwickeln und Betreiben von Microservices Architekturen nutzen lässt.

 

Anmerkung:

Wer mehr über den Spring Cloud Stack wissen möchte, dem wird die „Microservice in der Praxis“ Schulung ans Herz gelegt. Dort werden angesprochene Themen und weitere behandelt. Wer neu im Spring Universum ist, dem sei die dreitägige Spring Boot Schulung empfohlen.
Ich persönlich war lange Fan des Spring Cloud (respektive Netflix OSS) Stacks. Spring Cloud hat nur einen großen Nachteil. Jeder dieser einzelnen Services (Zuul, Eureka, etc „¦) die man in einer Microservices Architektur benötigt, muss jedoch auch betrieben werden. So kommen für diese Laufzeitumgebungs-/Infrastruktur-Services Themen wie Ausfallsicherheit (und daraus resultierendes Clustering) und/oder Monitoring ins Spiel und machen die Dinge in meinen Augen unnötig komplex.

Wünschenswert ist eine Laufzeitumgebung, die Microservice Architekturen nativ unterstützt und die Entwicklung bzw. den Betrieb (mit Augen auf DevOps kaum von einander zu unterscheiden 😉 ) von dem künstlich aufgesetzten Infrastruktur-Pain befreit.

 

Hier sind wir also bei Kubernetes als Orchestrierer und Istio als Service Mesh angelangt. Doch eins nach dem anderen.

Auf der offiziellen Webseite https://kubernetes.io/de/ wird folgendes über das Produkt geschrieben:

„Kubernetes (K8s) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.“
Also die Rede ist von „containerisierten Anwendungen“, meint also Applikationen werden in Docker Containern betrieben. Keine Sorge zur Beunruhigung: Docker ist mittlerweile der de facto Industriestandard. Ich war der Meinung, es gäbe eigentlich kaum nennenswerte Alternativen, musste mich jedoch von einem Kollegen eines Besseren belehren lassen. HashiCorp Nomad ist ebenfalls eine Art Orchestrierer & Skalierer für legacy Applikationen (Nicht- Container-Applikationen), Batch Jobs und Container-Applikationen.

Im Übrigen: Auch Spring Boot / Cloud Anwendungen werden häufig in einer Docker Umgebung betrieben, wenn nicht gerade eine Pivotal Cloud Foundary (PCF) Platform zur Verfügung steht. Dort könnte man Spring Boot Anwendung mehr oder weniger nativ betreiben.
Zurück zu Kubernetes: Google (Unternehmen hinter Kubernetes) wirbt weiterhin mit Skalierung von Anwendungen. Das ist gegenüber dem Plain-Old-Docker-Dienst ein weiteres Alleinstellungsmerkmal. Kubernetes kann anhand von Metriken einzelner Services automatisch neue Service-Instanzen starten. So lassen sich Lastspitzen zu Peek-Zeiten abfangen und ausbalancieren. Dies liegt außerhalb der Möglichkeit von Spring Cloud (ohne PCF Platform). Umgekehrt benötigen wir neben automatischer Skalierung und Verwaltung von besagten containerisierten Applikationen eben auch Dinge wie einen ApiGateway als Router/Filter für Http-Anfragen, EdgeService im Generellen für Autorisierung und Single-Point of Contact, als auch Service Discovery zum Auffinden von Services anhand von Namen anstatt IP-Adresse und Port.

Istio wird (wie Kubernetes Features ebenso) als Docker Container auf der virtuellen Maschine gestartet und implementiert für Microservices Applikationen ein sogenanntes SideCar. Dieses SideCar ist ein eigenständiger Container innerhalb des Pods des Microservices und nimmt Http-Anfragen entgegen und leitet sie an den eigentlichen Container entsprechend weiter. Wer mehr über SideCars wissen möchte, dem sei das Buch „Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services“ von Brendan Burns empfohlen.
„Was ist eigentlich mit CLOUD?“

Das Eine schließt das Andere nicht aus. Im Gegenteil: Die meisten Cloud Provider bieten Managed Kubernetes Cluster an. Diese weitere Abstraktionsschicht verschafft Portabilität und etwas Unabhängigkeit zwischen den Cloud Providern.

 

Fazit:

Spring Boot respektive Spring Cloud stellen eine solide Grundlage für Microservices Architekturen dar. Auch einige unserer Kunden vertrauen und implementieren auf Basis dieses Technologie-Stacks. Berücksichtigt man betriebliche Aspekte, sind weitere infrastrukturelle Umgebungen nötig. Dazu wurde Kubernetes samt Istio kurz vorgestellt.

In dem nächsten Artikel gehe ich konkreter auf die Kubernetes / Istio API ein und bringe KNative als weiteres Feature zum Betreiben von Serverless Applikationen auf Kubernetes ins Rennen. Zusätzlich stelle ich eine Microservices Demo Applikation (Bee-Amazing – next generation webshop) auf Basis von Spring Boot, Thymeleaf (als Frontend), Mongo DB zur Persistierung und natürlich Kubernetes vor.

Alle Beiträge von pascalstieber

Schreibe einen Kommentar