Ein ESB erfordert eine sehr mächtige Infrastruktur mit ausgeprägten Fähigkeiten im Management der einzelnen Services einschließlich einer zentralen Orchestrierung der Services z.B. mittels BPEL.
Microservices gehen einen alternativen Weg und übertragen wieder mehr Aufgaben an den einzelnen Service. Die Kommunikation basiert auf leichtgewichtigen und etablierten Verfahren wie HTTP oder (für asynchrone Kommunikation) auf Message Queues. Mehr erwarten Microservices nicht von ihrer Infrastruktur. Für alles weitere sind sie selbst zuständig. Dieser Ansatz wird unter dem Schlagwort “smart endpoints, dump pipes” subsumiert.
Die Kommunikation zwischen Microservices geschieht immer vor dem Hintergrund der remote communication und den damit verbundenen Herausforderungen ( [Foxwell] ). Situationen von Downtime von Microservices und Timeouts müssen behandelt werden. Microservices müssen diese Herausforderungen aktiv annehmen (Design for Failures). Strategien dazu werden in [Nygard] vorgestellt (resilience). Gemäß der Prämisse “smart endpoints, dump pipes” wird die Behandlung in jedem Microservices separat vorgenommen und nicht von einer zentralen Infrastruktur übernommen.
In großen Systemen wachsen schnell die Anforderungen an ein Management von Microservices. Wird eine Container-Technologie wie Docker eingesetzt, so muss eine Infrastruktur existieren, um ein sogenanntes Container Cluster zu betreiben. Diese Infrastruktur umfasst Verwaltung und Clustering von Containern (Orchestration, Scheduling), Auffinden der Services (Service Discovery), Load Balancing, Skalierung, Monitoring/dezentrales Logging. Diese allgemeinen Infrastruktur-Services müssen bereitgestellt werden. Für jede dieser Infrastruktur-Services gibt es unterschiedliche Implementierungen. Es existieren aber glücklicherweise unterschiedliche Softwarestacks, die die jeweiligen Infrastruktur-Services untereinander abgestimmt zusammenstellen (sogenannte Solution Stacks) ([Peinel]).
Solche Solution Stacks werden als PaaS (Platform as a Service) bezeichnet. PaaS stellen die Infrastruktur bereit, innerhalb derer die Mircoservices entwickelt, getestet und betrieben werden können.
Es existieren PasS wie CloudFoundry oder OpenShift, welche Sie auf Ihrer eigenen Hardware/Virtualisierungsumgebung betreiben können (private cloud). Sie behalten damit vollständige Kontrolle über Laufzeitumgebung und Daten.
Als Alternative zur private cloud können Sie sich einen Anbieter wählen, der PaaS für Sie auf dessen Hardware/Virtualisierungsumgebung betreibt (Hosting einer public cloud).
Beispiele für public-cloud-Anbieter sind Pivotal (basiert auf PaaS CloudFoundry), RedHat (basiert auf PaaS OpenShift), AWS (Amazon WebService und Beanstalk), Google (basiert Google AppEngine) oder Heroku (basisert auf PaaS Nomad).
Ihre Aufgabe bleibt es, sich für die Cloud-Strategie (private oder public cloud) zu entscheiden und die passende PaaSund ggfs. den passenden Anbieter zu wählen.
Auswirkungen auf die Toolkette zur Auslieferung
Die Auslieferungszyklen sind kürzer und Microservices können unabhängig voneinander ausgeliefert werden. Die Microservice-Architektur gibt – im Gegensatz zu monolithischen Systemen – die Freiheit, Microservices schnell, häufig und unabhängig voneinander zu releasen. Dazu ist allerdings ein automatisierter Build-, Deployment- und Release-Prozess notwendig. Es sollte der Schritt zu Continuous Delivery und Deployment Pipeline vollzogen und eine entsprechende Infrastruktur aufgesetzt werden [Thoughtworks-2]. Eine geeignete Continuous-Delivery-Infrastruktur vorausgesetzt, erhöht sich drastisch die Reaktionsfähigkeit auf sich unter Umständen schnell ändernde Marktanforderungen.
Betrieb von Microservices in der private cloud
Beim Betrieb einer private cloud müssen Lösungen gefunden werden, um Microservices und die zugehörigen Infrastruktur-Services zu verwalten. Wurde früher eine Anwendungen, z.B. durch einen Applikation Server, verwaltet, bestand die Infrastruktur im Wesentlichen aus der Verwaltung des Application Servers (inkl. Clustering, Loadbalancing, …).
In einer Microservices-Architektur ist die Infrastruktur ebenso Änderungen unterworfen, wie die Microservices selbst (dynamische Infrastrukturen, „Infrastructure as Code“ [Morris]).
Die Anzahl und die Konfiguration der bereitzustellenden Server und Infrastruktur-Services nimmt mit der Anzahl der Microservices und der wachsenden Komplexität ihrer Infrastruktur zu. Es müssen unterschiedliche Umgebungen bereitgestellt werden, welche (im besten Fall) sogar aus dem Continuous-Delivery-Prozess heraus ausgebaut werden können.
Infrastrukturen sollten ohne großen Aufwand zuverlässig und wiederholbar aufgebaut werden können. Automations-Tools wie Puppet, Chef oder Ansible bilden den Einstieg in eine dynamische Infrastruktur. Aber die Bestrebung von Infrastructure as code gehen darüber hinaus. Die Automation von Infrastruktur wird durch Automation-Toolsbereitgestellt, der Konfiguration und Ausführungsskripte Codecharakter haben. Dieser Code wird vergleichbar zu normalem Softwarecode behandelt und unterliegt Testverfahren und selbst einem Continuous-Delivery-Prozess.
