Kolumne: EnterpriseTales

Reduce to the Max: Microservices

Lars Röwekamp, Arne Limburg
Enterprise Tales

© Software & Support Media

Es gibt wohl kaum ein Thema in der Softwareentwicklung, das derzeit so heiß diskutiert wird wie die Wunderwelt der Microservices. Von „einfach genial“ bis hin zu „alter Wein in neuen Schläuchen“ trifft man auf die unterschiedlichsten Meinungen. Nicht selten begründen sich dabei die verschiedenen Einstellungen der Diskutanten schon in der Auffassung, was sich denn genau hinter dem Begriff „Microservices“ verbirgt. Grund genug für EnterpriseTales, einen Blick hinter die Kulissen zu wagen.

Um es gleich vorwegzunehmen: Wer in diesem Artikel eine eindeutige Definition des Begriffs Microservices sowie klare Architekturvorgaben in Form von Patterns und Tipps für ein entsprechend definiertes, universell einsetzbares Toolset/Framework erwartet, der sollte gar nicht erst weiterlesen. Zu unterschiedlich sind derzeit die Auffassungen und Erfahrungen der Experten aus ihren eigenen, stark individuellen Projekten, die sie bereitwillig in Blogs, Artikeln oder auf Konferenzen teilen. Angefangen bei kleinsten Einheiten, die je Request einen eigenen Prozess starten (und diesen dann auch sofort wieder beenden) bis hin zu SOA-ähnlichen Dimensionen eines Service sind für die Definition des Begriffs Microservices nahezu alle Facetten vertreten.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

Weniger ist mehr

Einig sind sich allerdings nahezu alle Verfechter Microservices-basierter Architekturen darin, dass ein derartiger Ansatz nur dann sinnvoll ist, wenn die einzelnen Services so autark wie möglich sind und so eine lose Kopplung des Gesamtsystems erreicht werden kann. Dies gilt nicht nur für die Entwicklung der Services selbst, sondern vor allem auch für Datenhaltung, Deployment und Monitoring – DevOps lässt grüßen. Denn was nutzt es, losgelöste Services zu implementieren, die am Ende doch alle auf dieselbe Datenbank zugreifen und somit bei kleinsten Änderungen an der Struktur dank der damit verbundenen Abhängigkeiten alle gleichzeitig neu deployt werden müssen? Und wie flexibel ist ein System mit autarken Entwicklungsteams, deren Softwarefragmente am Ende doch wieder in einem einheitlichen Deployment-Rhythmus künstlich synchronisiert werden?

Im Rahmen der vor Kurzem in Berlin stattgefundenen Konferenz microxchg 2015 (http://microxchg.io) haben sich einige Vordenker des Microservices-Ansatzes an einer Definition versucht: Adrian Cockcroft, ehemaliger Cloud Architect bei Netflix und somit einer der Microservices-Pioniere, definierte den Microservices-Ansatz als „Loosely coupled service oriented architecture with bounded contexts“. Oliver Wegner, Leiter Architektur und Qualitätssicherung E-Commerce bei OTTO, bezeichnet dagegen einen Microservice als „Einheit, die von einem kleinen Team komplett – sowohl fachlich als auch technologisch – beherrscht werden kann“. Stefan Tilkov, Gründer von innoQ, wiederum wählte einen Ansatz zur  „Definition“ von Microservices, den auch viele andere Speaker auf der Konferenz verfolgten, und beschrieb Microservices über eine Reihe von Charakteristika. Angefangen bei einer in sich abgeschlossenen, fachlichen Logik und einer damit einhergehenden, bei Bedarf redundanten Persistenz, über eine losgelöste Entwicklung und Evolution des Service sowie stark limitierter Interaktionen mit anderen Services, bis hin zu einem autonomen Deployment und Monitoring reichte sein Lackmustest.

Der goldene Schnitt

Eine wesentliche Herausforderung – und auch hier scheinen sich nahezu alle Microservices-Verfechter einig zu sein – stellt das richtige Zuschneiden der Services dar. Als Basis für sinnvolle Servicegrenzen wird in diesem Kontext gerne das mittlerweile mehr als zehn Jahre alte Buch „Domain-Driven Design“ von Eric Evans und die dort vorgestellten Bounded Contexts heranzogen.

Weniger Konsens herrscht bei den Experten dagegen darüber, ob auch das User Interface Bestandteil der einzelnen Services sein oder es besser ein einheitliches User Interface geben sollte, das über ein Client-API-Gateway gekapselt auf die Services zugreift. Neben den beiden Extremen findet man in einschlägigen Blogs und vor allem in realen Projekten auch häufig Lösungen, bei denen zwar jeder Service sein eigenes UI mit sich bringt, dieses aber auf gemeinsamen Styles und Richtlinien aufsetzt und so nach außen ein einheitliches Ganzes darstellt.

Conway’s Law

Dass Projekte und Architekturen nicht selten an den zugrunde liegenden Organisationsstrukturen scheitern, wissen wir spätestens seit Conway’s Law:

„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“ (Conway’s Law)

Hier bilden leider auch Microservices keine Ausnahme. Entsprechend muss die Einführung eines Microservices-basierten Ansatzes passende Team- und Kommunikationsstrukturen mit sich bringen, um Aussichten auf Erfolg zu haben. Dies stellt Organisationen vor die Aufgabe, gegebene Teamstrukturen zu hinterfragen und bestehende Teams gegebenenfalls neu zu strukturieren. Nur so lässt sich den zusätzlichen Aufgaben und Verantwortungen eines autark arbeitenden Entwicklerteams gerecht werden. Im Gegenzug dazu erhält das Team deutlich mehr Freiheiten, z. B. bei der Wahl der Programmiersprache, den einzusetzenden Frameworks, Tools und Libraries oder der zu verwendenden Datenbank bzw. Persistenz.

Wichtig ist, dass ein Team auch organisatorisch in die Lage versetzt werden muss, seine Services eigenständig zu implementieren, zu deployen und zu monitoren, um sie so permanent verbessern zu können. Nur so kann das Risiko der vielen vielen losgelösten Releases einzelner Services minimiert werden. Das ist laut Sam Newman von ThoughtWorks, Autor des Buchs „Building Microservices“ (O’Reilly, 2015) wiederum nur dann möglich, wenn sich teamübergreifend eine „Kultur der Automatisierung“ etabliert, die maßgeblich auf automatisierten Tests und Continous Delivery aufsetzt.

Fazit

Auch wenn Microservices für den einen oder anderen noch sehr abstrakt zu sein scheinen, feiern die ersten großen Referenzprojekte Erfolge und bringen klare Vorteile zum Vorschein. Die Entwicklungsteams genießen ihre neu gewonnenen Freiheiten und stellen sich im Gegenzug der Verantwortung für „ihre“ Services – von der Entwicklung bis zum Deployment und darüber hinaus.

Kleine, flexible Teams sind in der Lage, schnell auf Anforderungsänderungen oder Laufzeitprobleme zu reagieren, ohne dabei ein zehnfach abgesichertes Qualitätsgateway durchlaufen zu müssen. Fehlerhafte Services, die nicht in den Griff zu bekommen sind, werden im Zweifelsfall einfach neu implementiert, bei Bedarf auch in einer anderen Technologie. Der Aufwand hierfür ist in der Regel sehr überschaubar und somit schnell gerechtfertigt.

Natürlich bringt der „neue“ Ansatz auch neue Herausforderungen mit sich. Dies gilt insbesondere für den organisatorischen Teil eines Projekts. Diese Herausforderungen scheinen aber mittlerweile einigermaßen gut verstanden zu sein – erste „Lessons learned“ wurden durchlebt.

Fairerweise soll an dieser Stelle erwähnt werden, dass es sich bei den bisherigen Pionieren fast ausschließlich um große bis sehr große Unternehmen mit entsprechendem „Kampfkapital“ zur Entwicklung eigener Infrastruktur, z. B. für Continous Integration und Monitoring, handelt. Erste Lösungen wurden aber bereits z. B. von Netflix als Open-Source-Projekte der Allgemeinheit zur Verfügung gestellt.

Etwas überraschend scheint vielleicht, dass kaum ein Microservices-Verfechter das Thema „Kostenreduzierung in der Softwareentwicklung“ als Argument pro Microservices in den Raum wirft. Laut eigener Aussage geht es den meisten vielmehr darum, die Reaktionszeiten – Stichwort „Time to Market“ – sowie die Qualität der Softwaresysteme deutlich zu verbessern. Der Aspekt Kosten spielt dabei eine eher untergeordnete Rolle.

Oder anders formuliert: Microservices stellen eine immense Chance dar, dem Chaos der monolithischen Systeme wieder Herr zu werden und so endlich die Kontrolle über die eigene Software zurückzugewinnen. Ob dies gelingt, bleibt spannend. In diesem Sinne: Stay tuned.

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.