Alexander Schwartz msg systems ag

Anwendungen benötigen Konfigurationsdaten mit unterschiedlichen Informationen, z. B. zu den Adressen der Nachbarsysteme und zu fachlichen Parametern. In einer Microservices-Umgebung ist Automatisierung der Schlüssel zu einem zuverlässigen und effizienten Betrieb. Eine übergreifende zentrale Konfiguration ist der erste Schritt. Im zweiten Schritt müssen Konsumenten automatisch die von ihnen benötigten Services finden, wenn diese skaliert oder auf anderen Knoten neu gestartet wurden.

Viele kleine Services zu haben ist modern. Es lockt das Versprechen, neue Funktionalitäten zielgerichteter und schneller in Produktion zu bringen. Die Herausforderung ist dabei, den Überblick zu behalten: wo früher noch die Verwaltung und Problemanalyse von Hand möglich war, hilft jetzt nur noch vollständige Automatisierung. Wie gut, dass es dafür fertige Komponenten für Konfiguration, Service Discovery und Resilience gibt! Damit lassen sich nicht nur neue Services entwickeln, auch bestehende Anwendungen können davon profitieren.

Das große Versprechen einer Microservice-Architektur ist es, dass Ideen zielgerichteter und schneller umgesetzt und in Produktion genommen werden können. Wo es früher nur wenige Releases pro Jahr gab, sollen es jetzt mehrere Releases pro Tag sein, die jeweils automatisch in einer Continuous Delivery Pipeline getestet werden. Dies gelingt nur, wenn statt eines großen Monolithen kleine Services zielgerichtet in Produktion gebracht werden.

In einer solchen Umgebung ist die manuelle Konfiguration von Services genauso wenig möglich wie die manuelle Installation. Es sind Lösungen gefragt, die die dynamische Rekonfiguration der Services zulassen und dafür an zentraler Stelle hochverfügbar und passend zur Umgebung die notwendigen Konfigurationen bereitstellen.

Die Umgebungen sollen sowohl dynamisch horizontal skalieren als auch jederzeit neue Services integrieren können. Einen Loadbalancer von Hand zu konfigurieren scheidet hier aus. Auch wenn ein Loadbalancer für den Zugriff von außen einen zentralen Einstiegspunkt bieten kann, so sollen sich Services innerhalb der eigenen Infrastruktur direkt austauschen. So wird der Loadbalancer nicht zum unnötigen Engpass. Hierfür ist Service Discovery gefragt.

Services sind von ihrer eigenen Datenbank und den Services in ihrer Umgebung abhängig. Ist eine dieser Abhängigkeiten nicht verfügbar oder zu langsam, so ist Service nicht verfügbar und Fehler pflanzen sich fort. Dies gilt in klassischen Architekturen wie auch in Microservice-Architekturen. Damit nicht ein defekter Service die anderen blockiert, sind robuste Schnittstellen notwendig. Da Microservice-Architekturen durch kleiner geschnittenere Systeme viel mehr Schnittstellen haben, gibt es hierfür fertige Bibliotheken, um dies zu lösen. Davon profitieren auch klassische Architekturen.

Dynamische Konfiguration zur Laufzeit

Das erste, was eine Anwendung bei ihrem Start benötigt, ist ihre Konfiguration. Konfiguration ist das, was sich in verschiedenen Staging-Umgebungen wie Entwicklung, Test und Produktion unterscheidet und was ohne Ausrollen einer neuen Softwareversion geändert werden soll. Der Rest ist Programmcode. Die gute Nachricht: da durch die Continuous Delivery Pipeline mehrmals pro Tag Softwareänderungen in Produktion gegeben werden können, kann an den Stellen auf Konfiguration verzichtet werden, bei denen sie früher „auf Vorrat“ beziehungsweise „auf Verdacht“ eingebaut wurde. Zusätzlich kommen neue Konfigurationen, etwa für Feature Toggles, hinzu, mit denen neue Funktionen erst in der Testumgebung, später in Produktion nach und nach für Nutzer freigegeben werden.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 5.16 - "Microservices: Ein Hype im Realitätscheck"

Alle Infos zum Heft
236749Flexible und robuste Microservices
X
- Gib Deinen Standort ein -
- or -