text: Allerdings geht mit den hunderten oder tausenden von verschiedenen Services eine andere Komplexität einher, die es zu bewältigen gilt: die Orchestrierung und Konfiguration der verschiedenen Services. Bei einer Handvoll von Services, deployt in wöchentlichen Zyklen, kann man sich eventuell noch mit DNS-Einträgen oder dem händischen Zuweisen von Ressourcen aushelfen. Bei Anpassungen im Minutentakt braucht es allerdings automatische Lösungen.
  In diesem Tutorial zeigen wir, welchen grundlegenden Prinzipien man beim Bau von Microservices folgen sollte und welche Frameworks in der Spring-Boot- bzw. Spring-Cloud-Welt dabei helfen. Veranschaulichen wollen wir die Möglichkeiten anhand kleiner Beispiele in Kubernetes und Pivotal Cloud Foundry.
  Alle hier verwendeten Code-Beispiele und Artefakte können unter https://github.com/michaelgruczel/article-spring-boot-cloud-native-code-samples gefunden werden. Wenn in einem Beispiel auf einen Ordner source/chat-app verwiesen wird, dann ist die folgende Adresse gemeint: https://github.com/michaelgruczel/article-spring-boot-cloud-native-code-samples/tree/master/source/chat-app. Wer die Beispiele selber direkt in PCF und/oder Kubernetes ausführen möchte, ist eingeladen, das Repository auszuchecken oder den Inhalt herunterzuladen.
  Ich habe mich entschieden, die Konzepte in diesem Tutorial innerhalb von Kubernetes und PCF zu demonstrieren, um die Ideen und Frameworks innerhalb einer PaaS- und einer CaaS-Lösung aufzeigen zu können. Persönlich bin ich davon überzeugt, dass die meisten Firmen sich für eine PaaS oder CaaS entscheiden sollten, um die Aufwände für den Betrieb einer IaaS-Lösung in den Teams gering zu halten. Die hier aufgezeigten Frameworks und Konzepte funktionieren in einer IaaS-Umgebung oder auf reiner Hardware aber ebenso.
  Das Tutorial ist in einer Art geschrieben, die es dem Leser ermöglicht, die Beispiele selber Schritt für Schritt in PCF und/oder Kubernetes auszuführen. Ich empfehle, jeweils die Erklärungen zu beiden Plattformen zu lesen, selbst wenn nur eine davon zur Nachahmung herangezogen wird.
  Cloud Foundry (Open Source) ist eine der verbreitetsten PaaS-Lösungen (vermutlich zusammen mit Open Shift). Für die Beispiele in diesem Tutorial verwende ich die kostenpflichtige Pivotal-Variante, weil ich mir damit ein wenig Code ersparen kann. Die gleichen Lösungen sind prinzipiell aber auch in der Open-Source-Variante mit etwas mehr Aufwand realisierbar. Zum Ausprobieren der Beispiele in PCF empfehle ich die Registrierung eines freien Testaccounts (mit einem freien Budget von 87$) auf https://run.pivotal.io/.
  Zudem stelle ich die Beispiele innerhalb von Kubernetes vor. Kubernetes ist eine der komplettesten CaaS-Lösungen am Markt und auch eine sehr häufig verwendete. Auch hier empfehle ich zur Nachahmung einen freien Account, einzurichten beim Google-Cloud-Container-Engine-Angebot unter https://cloud.google.com/container-engine/.
  Beide Lösungen kann man aber auch lokal in virtuellen Maschinen in einem reduzierten Umfang ausprobieren oder die Plattformen selber irgendwo installieren.
  Einige der wichtigsten Prinzipien zur Erstellung einer Microservice-Architektur können von den Regeln der „Twelve-factor App“ (https://12factor.net/de/) abgeleitet werden. Einer der Faktoren fordert das explizite Deklarieren und Isolieren von Abhängigkeiten. Eine Twelve-factor App ist nicht von Systempaketen abhängig.
  Dieses Prinzip ist auch für Nicht-Microservice-Architekturen sinnvoll. Während sich aber bei einem Monolithen die Abhängigkeiten zu Systembibliotheken möglicherweise noch beherrschen lassen, wird dies mit einer hohen Anzahl verschiedener Services kompliziert. Ein klassischer Weg, um Abhängigkeiten für Anwendungen zu verwalten, sind Applikationsserver. Diese ergeben heutzutage aber immer weniger Sinn. Applikationsserver brauchen häufig viele Ressourcen, mehr als ein Microservice selber. Das Versprechen, eine Anwendung einmal zu bauen und sie dann in verschiedenen Applikationsservern ohne Anpassungen starten zu können, hat sich in der Praxis selten als haltbar erwiesen.
  Häufig müssen Anwendungen auf den spezifischen Applikationsserver hin angepasst werden, manchmal sogar an eine bestimmte Version. Die Idee, Anwendungen schlanker zu machen, indem bestimmte Bibliotheken bereits Teil des Applikationsserver-Klassenpfades sind, hat sich oft eher als Problem herausgestellt. Die genutzten Bibliotheken in einer Development Stage haben sich von der Produktion nicht selten unterschieden. Aufgrund von Lizenzkosten, Performanz oder Aufwänden wurden in den Stages entweder verschiedene Applikationsserver verwendet, oder der Entwickler musste in seiner IDE minutenlang warten, bis seine Codeänderungen lokal deployt waren. Das Paradigma hat sich geändert: Disk Space ist günstig, doch Entwicklungszeit ist teuer.
  Entwickler minutenlang auf ein Deployment warten zu lassen, um geänderten Code zu testen, ist heute also nicht mehr akzeptabel. Schnelle Startzeiten, schnelles Feedback und reproduzierbare Ergebnisse über alle Stages sind wichtiger, als Speicher- oder Disk-Nutzung zu reduzieren. Deshalb sollte heute eine Applikation alle seine Abhängigkeiten beinhalten. Jede Abhängigkeit sollte explizit definiert sein. ‚Runs on my machine‘ ist ein Satz, den man heute nicht mehr hören will.