Mit der Transformation in das digitale Zeitalter stehen CIOs vor der großen Herausforderung ihre IT-Architekturen zu modernisieren, um ihren internen Kunden damit eine atmende Plattform zu bieten, die für mehr Agilität steht und die Innovationskraft des Unternehmens fördert. Diese Veränderung erfordert das vollständige Überdenken über Jahre hinweg implementierter Architekturkonzepte. Denn auch wenn das derzeitige Bestreben darin besteht, existierende Enterprise Applikationen in die Cloud zu heben, müssen CIOs ihre IT-Mannschaften dazu befähigen, sich mit neuartigen Entwicklungsarchitekturen zu beschäftigen. Denn moderne Applikationen und IoT-Services folgen einem anderen Ansatz und sind innovativ und Cloud-basiert.

Microservice: Hintergrund und Bedeutung

Eine typische Applikationsarchitektur erinnert bildlich an einen “Monolith”, einen großen massiven Stein (Objekt), der aus einem einzelnen Stück besteht. In diesem Zusammenhang kann man daher auch von einem “Applikationsklotz” sprechen, da sich darin die Eigenschaften schwer, unbeweglich und gar nicht bis kaum veränderbar widerspiegeln.

Über die letzten Jahrzehnte hinweg wurden viele, meistens große monolithische Applikationen entwickelt. Das bedeutet, dass eine Applikation sämtliche Module, Bibliotheken, Abhängigkeiten usw. beinhaltet, die notwendig sind, um die reibungslose Funktionsfähigkeit sicherzustellen. Dieses Architekturkonzept bringt einen großen Nachteil mit sich: Ändert sich auch nur ein kleiner Teil an der Applikation, dann muss die gesamte Applikation neu getestet, kompiliert und bereitgestellt werden – ebenfalls die Teile der Applikation an denen keine Änderungen vorgenommen wurden. Ein riesiger Aufwand, der Personal, Zeit und IT-Ressourcen benötigt und in vielen Fällen zu Verzögerungen führt, insbesondere dann, wenn innerhalb eines der Teilabschnitte ein Fehler passiert. Weiterhin erschwert ein Monolith die Sicherstellung und Umsetzung von:

• Skalierbarkeit
• Verfügbarkeit
• Agilität
• Continuous Delivery

Um den oben beschriebenen Herausforderungen zu begegnen muss dafür gesorgt werden, dass die Applikationsarchitektur, anstatt aus einem einzigen großen Objekt, aus vielen einzelnen voneinander unabhängigen Objekten besteht. Alle Teilobjekte miteinander integriert führen dann zur Gesamtfunktionalität der Applikation. Die Änderung eines Teilobjektes beeinflusst dabei nicht die Eigenschaften und Funktionsweisen eines anderen Teilobjektes. Unterm Strich bedeutet dies, dass jedes Teilobjekt als eigener unabhängiger Prozess bzw. Service funktioniert. Dieses Konzept wird auch als “Microservice-Architektur” bezeichnet.

Was ist ein Microservice?

Ein Microservice kapselt eine abgeschlossene Funktionalität und wird unabhängig entwickelt und betrieben. Es handelt sich dabei also um eine kleine eigenständige Softwarekomponente (Service), die eine Teil-Funktion innerhalb einer großen, verteilten Softwareapplikation bereitstellt. Ein Microservice lässt sich somit unabhängig entwickeln und bereitstellen und skaliert autonom und selbständig. Auf Microservices basierende Applikationsarchitekturen sind daher modularisiert und lassen sich einfacher und schneller um neue Funktionen erweitern und im Laufe des Lebenszyklus warten.

Im Gegensatz zu klassischen Applikationsarchitekturen verfolgen moderne Cloud-basierte Architekturen den Microservice-Ansatz. Dies ist den Eigenschaften der Cloud geschuldet, an denen die Cloud-nativen Applikationsarchitekturen entsprechend angepasst werden müssen. Das bedeutet, sie müssen Themen wie die Skalierbarkeit und Hochverfügbarkeit von Beginn an mit berücksichtigen. Die Vorteile einer Microservice-Architektur zeichnen sich insbesondere durch die folgenden Eigenschaften aus:

• Bessere Skalierbarkeit: Wird ein Teil-Service einer Applikation zu einem Zeitpunkt mehr in Anspruch genommen als die anderen, ist er in der Lage eigenständig zu skalieren, ohne die restlichen Teile der Applikation negativ zu beeinflussen.
• Höhere Verfügbarkeit der gesamten Applikation: Fällt ein Teil-Service aus, beeinflusst er damit nicht die gesamte Applikation sondern nur die Funktionalität die er abbildet. Das kann bedeuten, dass ein Teil-Ausfall keine direkte Außenwirkung hat, wenn es sich dabei um einen Backend-Service handelt.
• Bessere Agilität: Änderungen, Verbesserungen und Erweiterungen lassen sich unabhängig von der Funktionalität der gesamten Applikation vornehmen und ohne andere Teil-Services zu beeinträchtigen.
• Continuous Delivery: Die Änderungen, Verbesserungen und Erweiterungen lassen sich regelmäßig vornehmen, ohne dass für die gesamte Applikation ein Update vorgenommen werden muss beziehungsweise ohne die gesamte Applikation in den Wartungsmodus zu schicken.

Ein weiterer Vorteil einer Microservice-Architektur: Ein Microservice lässt sich in mehr als einer Applikation einsetzen. Einmal entwickelt kann er später für eine Funktion in vielen weiteren Applikationsarchitekturen sorgen.

Monolith- vs. Microservice-Architektur

Welcher Anbieter arbeitet mit Microservices?

Derzeit existiert eine Reihe von Anbietern, welche die Bedeutung von Microservice-Architekturen verstanden haben. Besonders renommierte Infrastrukturanbieter-Größen tun sich allerdings weiterhin schwer mit ihrer Transformation. Wie es funktioniert zeigen einmal mehr die jungen wilden respektive die Cloud-natives:

• Amazon Web Services

Amazon AWS hat die Cloud-Infrastruktur von Beginn an auf das Bereitstellen von Microservices (Building Blocks) ausgerichtet. Beispiele: Amazon S3, Amazon SNS, Amazon ELB, Amazon Kinesis, Amazon DynamoDB, Amazon Redshift

• Microsoft Azure

Die Cloud-Plattform besteht von Anfang an aus Microservices. Seit kurzem existiert mit der Azure Service Fabric ein Service, mit dem sich auf Azure eigene Microservices entwickeln lassen. Beispiele: Stream Analytics, Batch, Logic App, Event Hubs, Machine Learning, DocumentDB

• OpenStack im Allgemeinen

Mit jedem Release erweitert die Community das OpenStack-Portfolio mit neuen Microservices vorwiegend für den Infrastrukturbetrieb. Beispiele: Object Storage, Identity Service, Image Service, Telemetry, Elastic Map Reduce, Cloud Messaging

• IBM Bluemix

IBMs PaaS Bluemix liefert eine Vielzahl an Microservices. Diese werden sowohl von IBM selbst oder über externe Partner auf der Plattform angeboten. Beispiele: Business Rules, MQ Light, Session Cache, Push, Cloudant NoSQL, Cognitive Insights

• Heroku/Salesforce

Der Heroku PaaS  bietet mit „Elements“ einen Marktplatz für fertige externe Services, die sich als Microservices in die eigene Applikation integrieren lassen. Beispiele: Redis, RabbitMQ, Sendgrid, Raygun.io, cine.io, StatusHub

• Giant Swarm

Giant Swarm bietet Entwicklern eine Infrastruktur für die Entwicklung, das Deployment und den Betrieb einer Microservice-basierten Applikationsarchitektur. Hierfür setzt Giant Swarm unter anderem auf Technologien wie Docker und CoreOS.

• cloudControl

Die PaaS-Plattform von cloudControl verfügt mit “Add-ons” über einen Marktplatz, um selbstentwickelte Anwendungen mit Services von externen Partnern zu erweitern. Beispiele: ElephantSQL, CloudAMQP, Loader.io, Searchify, Mailgun, Cloudinary

Die Anbieter liefern auf Basis ihres Microservice-Portfolios einen Programmierbaukasten der fertige Services liefert, mit denen sich Applikationen schneller entwickeln lassen. Es handelt sich dabei um fertige Bausteine (vgl. Hybrid- und Multi-Cloud-Architekturen), die selbst nicht mehr entwickelt werden müssen und sich stattdessen direkt als Bausteine im eigenen Quellcode verwenden lassen.

Beispiele für eine Microservice-Architektur?

Der Video-on-Demand Anbieter Netflix gehört nicht nur beim Thema Cloud Computing zu den Pionieren und absoluten Vorbildern für IT-Architekten. Unter der Leitung von Adrian Cockroft (jetzt Battery Ventures) hat Netflix eine eigene mächtige Microservice-Architektur aufgebaut, um seine Video-Plattform hochskalierbar und hochverfügbar zu betreiben. Zu den Services zählen u.a:

• Hystrix = Latenz und Fehlertoleranz
• Simian Army = Hochverfübarkeit
• Asgard = Applikation Deployment
• Exhibitor = Monitoring, Backup und Recovery
• Ribbon = Inter Process Communication (RPC)
• Eureka = Load Balancing und Failover
• Zuul = Dynamisches Routing und Monitoring
• Archaius = Configuration Management
• Security_Monkey = Security und Tracking Services
• Zeno = In-Memory Framework

Sämtliche Microservices kapselt Netflix in seinem “Netflix OSS”, das als Open Source auf Github (http://netflix.github.io/) heruntergeladen werden kann.

Ein Beispiel aus Deutschland ist Autoscout24. Das Automobil-Portal steht vor der Herausforderung seine 2000 Server verteilt über 2 Rechenzentren und die derzeit eingesetzten Technologien auf Basis von Microsoft, VMware und Oracle abzulösen. Das Ziel: Eine Microservice-Architektur in einem DevOps-Modell, um damit über einen Continuous Delivery-Ansatz nicht mehr nur ein Release pro Monat auszurollen, sondern ständig Verbesserungen und Erweiterung bereitzustellen. Als Cloud-Infrastruktur hat sich Autoscout24 für die Amazon Web Services entschieden und befindet sich bereits in der Migration.

Microservice: Die Herausforderungen

Trotz ihrer Vorteile bringt eine Microservice-Architektur einige Herausforderungen mit sich. Neben dem Wissen rund um das Thema Cloud Computing (Konzepte, Technologien etc.) zählen hierzu insbesondere:

• Eine höhere Komplexität im Betrieb, da die Services sehr agil und beweglich sind.
• Eine zusätzliche Komplexität auf Grund des Aufbaus eines massiv verteilten Systems. Hierzu gehören u.a. Latenz, Verfügbarkeit und Fehlertoleranz.
• Entwickler benötigen Betriebswissen = DevOps
• Das API-Management und die nahtlose Integration haben hohe Priorität.
• Ein vollständiger Ende-zu-Ende Test ist notwendig.
• Sicherstellung einer ganzheitlichen Verfügbarkeit und Konsistenz der verteilten Daten.
• Vermeidung einer zu hohen Latenz der einzelnen Services.

The Bottom Line: Das sollten CIOs berücksichtigen

Stand heute machen Standard Web-Applikationen (42 Prozent) auf Public Cloud-Umgebungen noch den Löwenanteil aus. Mit Abstand folgen mobile Applikationen (22 Prozent), Media Streaming (17 Prozent) und Analytics Services (12 Prozent). Enterprise Applikationen (4 Prozent) und Services im Anwendungskontext “Internet of Things” (3 Prozent) machen bislang nur einen kleinen Teil der Workloads aus. Der Grund für die derzeitige Verteilung: Webseiten, Backend-Services sowie Content-Streaming (Musik, Videos, etc.) eignen sich ideal für die Public Cloud. Hingegen stecken Unternehmen immer noch inmitten ihrer digitalen Transformation und evaluieren Anbieter als auch Technologien für den erfolgreichen Wandel. IoT-Projekte befinden sich derzeit noch vorwiegend in der Ideenfindung und machen in 2015 daher nur einen kleinen Anteil der Verteilung auf Public Cloud-Umgebungen aus.

Bis zum Jahr 2020 wird sich das Verhältnis maßgeblich verändern. Mit dem steigenden Cloud-Wissen innerhalb der Unternehmens-IT und der stetig wachsenden Marktreife von Public Cloud-Umgebungen für Enterprise Applikationen, wird der Anteil dieser Kategorie weltweit von 4 Prozent auf 12 Prozent anwachsen. Der Anteil für Web und mobile Applikationen sowie Content-Streaming wird sich anteilig verringern. Dafür werden IoT-Applikationen mit 23 Prozent bereits fast ein Viertel aller Workloads auf Public IaaS-Plattformen ausmachen.

Mit diesen Einflüssen im Rücken stehen CIOs vor der Herausforderung ihre technische Agenda zu überdenken und sich eine Strategie zu überlegen, um das Unternehmen zu befähigen, mit den aktuellen Marktveränderungen zumindest mithalten zu können. Sie müssen daher rechtzeitig auf das Ende des Application-Lifecycle reagieren, indem sie alte Anwendungen durch moderne Applikationsarchitekturen ersetzen. Allerdings entsteht ein Wettbewerbsvorteil nur dann, wenn man die Dinge anders macht als die Konkurrenz und nicht dieselben Dinge einfach nur besser. Das bedeutet, dass CIOs heute einen entscheidenden Beitrag leisten müssen, neue Geschäftsmodelle zu entwickeln und als IT-Fabrik neue Produkte mit zu entwickeln. Die Welle von Services und Applikationen im Rahmen des Internet of Things (IoT) ist dabei nur eine Chance die es zu nutzen gilt.

Der Einfluss der Microservice-Architektur

Eine Microservice-Architektur kann eine IT-Abteilung dabei unterstützen, besser auf die Anforderungen aus den Fachabteilungen zu reagieren und damit für ein schnelleres Time-to-Market zu sorgen. Hierbei sollte allerdings nicht mehr in unabhängigen Silos gedacht, sondern ein digitaler Schirm über die gesamte Organisation gespannt werden. Hierzu gehört ebenfalls das Einführen eines DevOps-Modells, um die Microservices in kleinen Teams verteilt zu entwickeln. Denn moderne Entwicklungs- und Collaboration-Werkzeuge ermöglichen die Entwicklung in weltweit verteilten Teams. Damit lässt sich gleichzeitig der Fachkräftemangel in einem bestimmten Ländermarkt umgehen, indem man Spezialisten aus der ganzen Welt rekrutiert. So ließe sich zum Beispiel ein Microservice-Team mit den Rollen Produkt-Manager, UX-Designer, Entwickler, QA-Engineer und DB-Admin aufstellen welches dann über definierte APIs auf die Cloud-Plattform zugreift, die wiederum von System-, Netzwerk- und Storage-Admins betrieben wird.

Zu den Entscheidungsgrundlagen für eine Microservice-Architektur zählen:

• Bessere Skalierbarkeit autonom agierender Services.
• Schnellere Reaktionszeit auf neue Technologien.
• Jeder Microservice ist ein eigenes Projekt.
• Die Funktion eines Microservice lässt sich in mehreren Applikationen verwenden.
• Einsatz mehrerer verteilter Teams.
• Einführung des Continuous Delivery-Modells.
• Schnelleres Onboarding neuer Entwickler und Mitarbeiter.
• Microservices lassen sich einfacher und schneller für einen spezifischen Geschäftszweck entwickeln.
• Integrationskomplexität lässt sich verringern, da einzelne Services weniger Funktionalität und damit eine geringere Komplexität enthalten.
• Fehler lassen sich besser isolieren.
• Kleine Dinge lassen sich einfacher testen.

Unterm Strich sollte jedoch beachtet werden, dass die Einführung einer Microservice-Architektur nicht nur einen Wandel auf der technologischen Agenda bedeutet. Ein Umdenken in der Unternehmenskultur und der interdisziplinären Kommunikation ist unausweichlich. Das bedeutet, dass sich auch die bestehende IT- und Entwicklungsmannschaft verändern muss. Sei es durch interne Fortbildung oder externe Rekrutierung.