Suche
Bericht von der Microxchg

Microservices: (noch) keine einheitliche Definition

Lars Röwekamp

microxchg Logo (Quelle: microxchg.io)

Mitte Februar. Ganz Berlin im Berlinale-Fieber. Ganz Berlin? Nein! Eine „kleine“ Gruppe von Interessierten und Experten tauschte sich parallel zur Galaveranstaltung zwei Tage lang auf der microxchg 2015 Konferenz – der ersten Veranstaltung ihrer Art in Deutschland – über die Wunderwelt der Microservices aus. Und das alles ganz ohne roten Teppich und Smoking, dafür aber mit vielen Erkenntnissen.

Um es gleich vorweg zu nehmen: Wer auf der Konferenz eine einheitliche Definition des Begriffs „Microservice“ sowie klare Architekturvorgaben in Form von Patterns und ein entsprechend definiertes, universell einsetzbares Toolset/Framework erwartet hatte, der war fehl am Platz. Zu unterschiedlich waren die Auffassungen und Erfahrungen der Sprecher aus ihren eigenen, stark individuellen Projekten, die sie mit den Teilnehmern der Konferenz teilten. 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 Services waren nahezu alle Facetten vertreten.

Weniger ist mehr

Einig waren sich alle darin, dass eine Microservices-basierte Architektur 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. 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 DB-Struktur alle neu deployt werden müssen? Und wie flexibel ist ein System mit autarken Entwicklungsteams, deren Software-Fragmente am Ende doch wieder in einem einheitlichen Deployment-Rhythmus künstlich synchronisiert werden?

Adrian Cockcroft, ehemaliger Cloud Architect bei Netflix und somit einer der Microservice-Pioniere, definierte den Microservice-Ansatz als „Loosely coupled service oriented architecture with bounded contexts“. Oliver Wegner, Leiter Architektur und Qualitätssicherung E-Commerce bei OTTO, dagegen bezeichnet einen Microservice als „Einheit, die von einem kleinen Team komplett – sowohl fachlich als auch technologisch – beherrscht werden kann“.

Stefan Tilkov, Mitveranstalter der Konferenz, wählte in seinem Vortrag 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 Services sowie stark limitierter Interaktionen mit anderen Services, bis hin zu einem autonomen Deployment und Monitoring reichte sein Lackmustest.

Über die Frage, ob auch das User Interface Bestandteil der einzelnen Services sein sollte oder es besser ein einheitliches UI gäbe, das über ein Client-API-Gateway gekapselt auf die Services zugreift, herrschte dagegen kein wirklicher Konsens. Neben den beiden Extremen wurden auch Lösungen vorgestellt, bei denen zwar jeder Service sein eigenes UI mit sich bringt, dieses aber auf gemeinsamen Styles und Richtlinien aufsetzen.

Der goldene Schnitt

Eine wesentliche Herausforderung stellt das richtige Zuschneiden der Services dar. So war es nicht verwunderlich, dass nahezu jeder Vortrag das Buch „Domain Driven Design“ von Eric Evans und die dort vorgestellten Bounded Contexts als Basis für sinnvolle Servicegrenzen heranzog. Natürlich wurde innerhalb der Vorträge auch mehr als einmal Conway’s Law zitiert und darauf hingewiesen, dass die Einführung von Microservices-basierten Architekturen auch entsprechende Team- und Kommunikationsstrukturen nach sich ziehen muss, um Aussichten auf Erfolg zu haben. Dies bringt unweigerlich die Aufgabe mit sich, dass bestehende Teamstrukturen hinterfragt und Teams gegebenenfalls neu strukturiert werden müssen, um den zusätzlichen Aufgaben und Verantwortungen gerecht zu werden. Im Gegenzug dazu erhält das Team deutlich mehr Freiheiten, z. B. bei der Wahl der Programmiersprache, der einzusetzenden Frameworks, Tools und Libraries oder der zu verwendenden Datenbank bzw. Persistenz.

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

Fazit

Die Herausforderungen an Microservices-basierte Architekturen scheinen verstanden, erste „Lessons learned“ wurden durchlebt. Nun gilt es diese Erfahrungen zu konsolidieren und in die Breite zu tragen. Bei den bisherigen Pionieren handelt es sich indes fast ausschließlich um große bis sehr große Unternehmen mit entsprechendem „Kampfkapital“ zur Entwicklung eigener Infrastruktur für z. B. Continuous Integration und Monitoring. Erste Lösungen wurden aber bereits als Open-Source-Projekte, z. B. von Netflix, der Allgemeinheit zur Verfügung gestellt.

Eine vielleicht für einige überraschende Erkenntnis war, – hier schienen sich ebenfalls die Experten einig zu sein – dass Microservices kein Ansatz sind, um die Kosten der Software-Entwicklung zu minimieren. Es gehe vielmehr darum, die Reaktionszeiten – Stichwort „Time-to-Market“ – sowie die Qualität der Systeme deutlich zu verbessern. Oder anders formuliert: Microservices stellen eine Riesenchance dar, dem Chaos der monolithischen Systeme wieder Herr zu werden und so endlich die Kontrolle über die eigene Software zurück zu gewinnen.

Verwandte Themen:

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.
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Microservices: (noch) keine einheitliche Definition"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Martin Gutenbrunner
Gast

Hallo Lars,

auch, wenn ich bei der Microxchg leider nicht dabei sein konnte, freut es mich doch, dass sich die hier geschilderten Erfahrungen zum Großen Teil mit meinen decken.
Am besten finde ich die Erkenntnis, dass nicht nur technische, sondern auch menschliche und organisatorische Belange gelöst werden müssen.

Ich hab hierzu vor einiger Zeit auch selber meine Gedanken zusammengefasst:
http://blog.ruxit.com/soa-or-microservices-does-not-matter-dingos-kidneys/

schöne Grüße
Martin

Lars Röwekamp
Gast

Hallo Martin,
guter Blogeintrag. Nach meiner Erfahrung scheitern heute kaum noch Projekte an der Technologie. Das eigentliche Problem ist in der Regel die Komplexität der Fachlichkeit. Schafft man es, diese in überschaubare und klar voneinander abgegrenzte Blöcke – z.B. in Form von Microservices (als technische Repräsentation von DDD „Bounded Context“) – zu unterteilen, um so die Abhängigkeiten zu lösen, hat man schon fast gewonnen.
Gruß Lars