Empfehlungen nicht nur für Microservices
7 Leitlinien für die serviceorientierte Softwareentwicklung in Zeiten digitaler Transformation
Die Unterscheidung von Services für Infrastruktur (IaaS), Plattformen (PaaS) und Software (SaaS) ist allgegenwärtig. Bei "SaaS – Software as a Service" stellt sich dabei die Frage, ob es für Business oder Application Services steht.
- Ein Business Service kann ein vollständiger Prozess wie zum Beispiel ein Bestellprozess sein. Die Software, die diesen Prozess implementiert, bedient sich dann häufig der Services verschiedener IT-Systeme, den sogenannten Application Services.
- Ein Application Service ist ein Service, den ein IT-System – auch Applikation genannt – anbietet. Der Application Service kann ein Produkt in der Cloud oder auch der Service eines IT-Systems sein, das in der Infrastruktur des Unternehmens läuft. Es kann ein öffentlicher oder auch ein nur im Unternehmen verfügbarer Service sein.
In der serviceorientierten Architektur (SOA) geht es insbesondere um die richtige fachliche Strukturierung der Geschäftsfunktionen als Services. Und auch darum, wie solche Business Services am besten durch Application Services implementiert werden. Die Frage nach dem richtigen Service-Schnitt war dabei immer schon der Knackpunkt.
Einen schlechten Ruf hat SOA teilweise dadurch bekommen, dass serviceorientierte Architekturen häufig mit Web Services gleichgesetzt wurden. Dabei sind Web Services nur eine von vielen technischen Varianten zur Umsetzung von Application Services. Bei dieser Missinterpretation von SOA, konzentrierte man sich insbesondere auf die technische Realisierung, bei der dann häufig ein Enterprise Service Bus (ESB) als Allheilmittel zur Umsetzung einer SOA empfohlen wurde. Technologie und Tools können aber keinen fachlichen Schnitt gewährleisten, der für die Service-Nutzer passend und attraktiv ist.
Microservices haben die Diskussion des richtigen Serviceschnitts insbesondere aus Sicht der Service-Granularität neu angefacht. Während in einer SOA in der Vergangenheit eine Applikation häufig viele Services angeboten hat, ist jeder Microservice eigenständig installier- und betreibbar. Auch ein Microservice ist nichts anderes als eine Variante von Application Services.
In diesem Sinne sind Microservices nichts weiter als eine Architekturvariante zur Umsetzung einer SOA. Eine andere Architekturvariante für SOA bleibt ein gut strukturiertes und leistungsfähiges IT-System, das mehrere Services aus einer einzigen Applikation heraus anbietet und das die Fachwelt als Deployment-Monolithen bezeichnet. In Zeiten der bimodalen IT werden beide Architekturvarianten in Zukunft ihre Berechtigung haben.
Wer agil sein möchte, muss den Vierklang aus Agile, DevOps, Microservices und Cloud beherrschen.
Darüber hinaus können IT-Architekten vieles aus der erfolgreichen Umsetzung von Microservices auch für die Umsetzung von gut strukturierten Deployment-Monolithen übernehmen. Die folgenden sieben Empfehlungen spiegeln somit Erfahrungen aus der Umsetzung von Microservices wider, die man generell für die Implementierung von Software für heute und morgen befolgen sollte.
Empfehlung 1: Software Development 4.0
Agil allein reicht heute nicht mehr. Wer agil sein möchte, muss den Vierklang aus Agile, DevOps, Microservices und Cloud beherrschen. Um die Ziele
- Time-To-Market von der Idee bis zur Produktion in Tagen,
- in hoher Qualität und Zuverlässigkeit,
- zu akzeptablen Kosten,
zu erreichen, werden diese vier Trends zu Software Development 4.0 kombiniert: Flexible und überschaubare Microservices werden in einem agilen, interdisziplinären und auf den Geschäftsnutzen ausgerichteten Ansatz auf einer voll automatisierten Produktions-Pipeline (DevOps) in der Cloud entwickelt, getestet und betrieben.
Empfehlung 2: Agile Architekturen
IT-Architekten sollten auch über andere Architekturen als Microservices nachdenken, wenn sie eine moderne, zukunftsfähige und agile Lösung bauen möchten. Neue – oder zumindest immer mehr an Bedeutung gewinnende Architekturparadigmen – sind neben Microservices:
- Leichtgewichtige BPM-Lösungen, die sich als Bibliothek leicht in Anwendungen integrieren lassen, statt mit einem schwergewichtigen BPM-Produkt die Anwendungslandschaft komplexer zu machen.
- Event(Message)-getriebene Architekturen sind nicht neu, aber immer öfter die Alternative, wenn nächtliche oder langlaufende Batches die heutigen Anforderungen an kurze Reaktionszeiten nicht mehr erfüllen können.
- Keine Trennung von OLAP und OLTP mehr: Das bisher allgemein anerkannte Architekturparadigma, analytische Funktionen in eigenständigen Systemen (OLAP*) getrennt von den Systemen mit den operativen Funktionen (OLTP*) zu implementieren, gilt in vielen Fällen nicht mehr. Moderne In-Memory-Datenbanken, wie SAP Hana, können analytische Anfragen bedienen, ohne dass es einer besonderen Aufbereitung der Daten in einer OLAP-Datenbank bedarf. So können heutige Anforderungen in Echtzeit erfüllt und gleichzeitig die Anwendungslandschaft drastisch vereinfacht werden, weil die komplexen ETL-Prozesse zwischen OLTP- und OLAP-Datenbank ersatzlos wegfallen.
Empfehlung 3: Denken in Bausteinen
Die Zeit ist reif, um Services aus der Cloud oder dem eigenen Unternehmen in die Lösungen zu integrieren und als Software-Bausteine für andere anzubieten.
Eine PAC-Analyse vom Mai 2016 [1] besagt: Die Digitalisierung braucht Individualisierung und damit Softwareentwicklung. In vielen Unternehmen sind Standardlösungen in Digitalisierungsprojekten die erste Wahl. Das können Plattform-Erweiterungen sein, Cloud-Services oder Lizenz- und Open Source-Software. Um sich aber von seinen Wettbewerbern zu differenzieren, sind individuelle Anpassungen oder Erweiterungen notwendig. Jeder träumt davon Services anzubieten, die in Lego-Bauweise aus Standard-Services und individuellen Services komponiert werden.
Als Nutzer von Services müssen die Unternehmen lernen, wie man Services aus der Cloud, von Partnern oder auch aus dem eigenen Unternehmen in eine Gesamtlösung integriert. Als Anbieter von Services können sie sich von erfolgreichen Beispielen, wie den "Google Maps APIs Web Services" [2], inspirieren lassen, wie man eigene Dienste erfolgreich am Markt anbieten kann.
Empfehlung 4: Der goldene Schnitt
Genauso wenig wie Web Services als Technologie oder ein Enterprise Service Bus (ESB) als Produkt in der Vergangenheit geholfen haben, den richtigen fachlichen Schnitt für Services zu finden, werden heute Microservices diese Arbeit erleichtern. Wie man einen Service als Programmierschnittstelle (API) oder auch mit graphischer Benutzeroberfläche für einen Endkunden passend und attraktiv macht, kann den Verantwortlichen keine Architektur oder Technologie abnehmen.
Hier ist es besonders wichtig, dass Business-Architekten "outside in" vom Nutzer her denken. Was braucht der Nutzer? Wie ist ein Service für ihn einfach und bequem nutzbar? So kommen Business- und Systemarchitekten gemeinsam zu einem goldenen Serviceschnitt.
Empfehlung 5: Eventual Consistency
Mit dem Hype von Microservices, ist "Eventual Consistency" als eine neue Variante von Transaktionalität populär geworden. "Eventual Consistency" beschreibt die Situation, dass in einem verteilten System, das aus mehreren Microservices besteht, nicht jeder Microservice bei gemeinsam genutzten Daten ohne Zeitverlust jede Datenänderung mitbekommen kann. Diese Datensynchronisation kann also etwas dauern. Je geringer der Zeitverlust sein soll, umso schwieriger und aufwändiger ist häufig die Umsetzung.
Viel wichtiger als eine technische Diskussion zur Umsetzung von "Eventual Consistency" ist allerdings, dass der Fachbereich versteht, welche Auswirkungen, aber auch welche Möglichkeiten sich aus fachlicher Sicht hieraus ergeben. Die für ein IT-System fachlich Verantwortlichen müssen lernen, fachliche Lösungen zu entwerfen, für die der Zeitverzug, mit dem sich Änderungen durch das System propagieren, kein Problem darstellt. Es ist beispielsweise heute für jeden, der online ein Produkt bestellt, absolut normal, dass er seine endgültige Auftragsbestätigung per E-Mail bekommt. Der zeitliche Verzug ermöglicht es dem Anbieter, den Lagerbestand nicht in jede Transaktion einer Online-Bestellung zu zwingen. Sollten tatsächlich zwei Personen gleichzeitig das letzte Exemplar bestellt haben, wird dies im Hintergrund trotzdem vor dem Versenden der E-Mail festgestellt. Es braucht daher fachliche Experten zur Entwicklung von Lösungen mit "Eventual Consistency", die auch für den Endkunden attraktiv sind. Die Empfehlung lautet also: "Eventual Consistency" gehört auch in den Bausteinkasten des IT-Architekten, aber es ist vielmehr eine fachliche als eine technische Herausforderung.
Empfehlung 6: Erreichbar oder nicht erreichbar
Die Frage ist nicht – wie bei Hamlet – Sein oder Nichtsein, sondern erreichbar oder nicht erreichbar. Bei Mobilgeräten ist damit zu rechnen, dass ein Service wegen fehlenden Netzes nicht erreichbar ist. Microservices sind voneinander unabhängig installierbar, wenn ein Microservice auch dann antworten kann, wenn abhängige Microservices nicht verfügbar sind. Meine Empfehlung ist daher, aktiv mit der Nichterreichbarkeit von Services umzugehen. Als mögliche Lösungen bieten sich an: Caching, Rückgriff auf ein Alternativsystem, das Circuit Breaker Pattern oder auch eine Anpassung der fachlichen Lösung.
Das Spektrum serviceorientierter Architekturen wird größer.
Empfehlung 7: Überall Events
In meiner zweiten Empfehlung wurden Event- beziehungsweise Message-getriebene Architekturen bereits als agile Architektur angesprochen. Das Thema "Eventverarbeitung" bekommt aber in der aktuellen Softwareentwicklung eine noch viel größere Bedeutung. Es geht um mehr als nur darum, Batches durch zeitgemäße Eventverarbeitung zu ersetzen.
Dass wir heute mit unserem Smartphone ein Paket vom Versender bis an die Haustür des Empfängers quasi in Echtzeit verfolgen können, ist selbstverständlich. Mit dem Zeitalter des Internets der Dinge beginnt aber gerade erst die Verbreitung von Sensoren in allen Dingen, die damit über entsprechende Software vernetzt werden. Wenn jedes Haushaltsgerät, jedes Kleidungsstück und jede Pflanze in unserem Garten Daten verschicken kann, dann lässt sich erst in Ansätzen erahnen, wie sehr wir überall von Events umgeben sein werden, die sinnvoll verarbeitet werden möchten.
Wir benötigen dann nicht nur dedizierte Systeme, die Events in großen Massen entgegennehmen, verarbeiten und auch wieder weiterverteilen, sondern jedes unserer IT-Systeme muss in der Lage sein, wertvolle Informationen in Form von Events verarbeiten zu können. Überall Events zu erzeugen, bedeutet also auch, überall Events verarbeiten zu können.
Fazit
Das Spektrum serviceorientierter Architekturen wird größer. Auf der einen Seite stehen sich Deployment-Monolithen und Microservices [3] gegenüber. Auf der anderen Seite existiert ein breites Spektrum von Technologien wie beispielsweise REST, klassische Web Services und ESB-Produkte, um sie zu implementieren und zu publizieren. Die sieben Empfehlungen zeigen aber, dass es unabhängig von diesen verschiedenen Dimensionen Leitlinien gibt, die heute Voraussetzung sind, um eine zukunftsfähige und agile Lösung zu bauen.
- J. Hackmann, 2016: Kundenspezifische Softwareentwicklung in Zeiten der digitalen Transformation von Geschäftsmodellen, Eine Analyse von PAC.
- Google Maps APIs Web Services
- Informatik Aktuell – Guido Steinacker: Von Monolithen und Microservices
weitere Informationen:
Dr. Karl Prott: IT-Trends Blog "Software Development 4.0"
