IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Software-Entwicklung 4.0 – Microservices

Kategorie: Trends des Monats

Sehen Sie Microservices auch als SOA in neuen Schläuchen oder als ein neues revolutionäres Konzept, um die heutigen Time-To-Market Anforderungen an die IT in einem agilen Umfeld erfüllen zu können?

Diese Frage habe ich gemeinsam mit rund 40 IT-Architekten in unserem Kundenforum Architektur erörtert. Die Teilnehmer stammten aus unterschiedlichen Bereichen wie eCommerce, Public, Logistik, Versicherung und Auto. Nach einer kurzen Definition des Begriffes Microservice haben wir diskutiert: „Wurden bei Ihnen schon Microservices entwickelt?“

Von den 23 teilnehmenden Kundenarchitekten[i] hatten bereits fünf in ihrem Unternehmen Microservices entwickelt – allerdings nur zwei von ihnen in einer strengen Auslegung der Definition. Neun Architekten denken in ihrem Umfeld zumindest über die Entwicklung von Microservices nach, doch weitere neun Architekten planen dies nicht einmal. Überrascht Sie das?

Ihre Antwort hängt sicherlich auch davon ab, wie hoch der Time-to-Market-Druck in Ihrem persönlichen Umfeld ist. Es ist in meinen Augen kein Zufall, dass die Erfolgsstories - soweit mir bekannt - immer dort entstanden sind, wo die Amazons, OTTOs und Netflixe dieser Welt sich unter dem Druck der Märkte im digitalen Zeitalter (neu) erfinden mussten.

Da stellt sich die Frage: Was hält viele davon ab, wenn es doch so außerordentliche Erfolgsbeispiele gibt? Wir haben die Architekten daher gefragt, was nach ihrer Einschätzung die größte Herausforderung bei der Einführung und Umsetzung von Microservices sei.

Dieses Mal waren zwei Antworten möglich:

 Was ist nach Ihrer Einschätzung die größte Herausforderung bei der Einführung und Umsetzung von Microservices?

Abbildung 1: Was ist nach Ihrer Einschätzung die größte Herausforderung bei der Einführung und Umsetzung von Microservices?

Mich hat wenig überrascht, dass die Teilnehmer die Größe und die Entkopplung als größte Herausforderung sehen. Die Größe beinhaltet die schwierige Zerlegung in fachlich sinnvolle und gleichzeitig kleine überschaubare Services. Durch die Entkopplung muss man erreichen, dass die vielen Microservices trotz der steigenden Anzahl von Schnittstellen untereinander wirklich unabhängig bleiben.

Der Betrieb und eine andere Herausforderung bezüglich notwendiger Organisationsänderungen im Unternehmen waren insbesondere für diejenigen mit Erfahrung in der Umsetzung von Microservices die größte Herausforderung, da der Betrieb und die Überwachung einer viel größeren als heute üblichen Anzahl von Services den klassischen Betrieb überfördern könnte. Deshalb sind Microservices ohne DevOps mit höchstmöglicher Automatisierung aller Build, Deployment- und Betriebsprozesse gar nicht denkbar. Die größte Herausforderung sehen daher viele auch in den notwendigen organisatorischen Änderungen im Unternehmen nach dem Motto „You build it – you run it“, welche die klassische Rollenverteilung zwischen Entwicklung und Betrieb neu ordnen.

Dass nur wenige die GUI-Integration angekreuzt haben, könnte auch daran liegen, dass hierzu in einem Vortrag vorab eine Lösung mit „Edge Side Includes (ESI)“ präsentiert wurde. Persönlich überrascht hat mich dann doch, dass kaum jemand die Kosten als Antwort gewählt hat. Sicherlich kann man allein über den Punkt, ob Microservices teurer als klassische Services sind, ausgiebig kontrovers diskutieren.

Einig waren sich alle, dass Unternehmen am besten auf der grünen Wiese direkt mit Microservices und nicht mit einem Monolithen starten sollten, um den Monolithen dann in Microservices zu zerlegen. In dieser Runde hätte Stefan Tilkov mit seiner These „Skip the Monolith, Start with Microservices“ viele Anhänger gehabt.

Als Fazit zeigte die abschließende anonyme Umfrage, dass Microservices in der Software-Entwicklung 4.0 eine bedeutende Rolle spielen werden. Fast jeder hat geantwortet, dass er unter bestimmten Voraussetzungen und insbesondere bei hohen Time-To-Market Anforderungen den Einsatz von Microservices für sinnvoll hält.

Heute und in der Zukunft umso mehr ist jedes Unternehmen ein Software-Unternehmen. Persönlich bin ich daher davon überzeugt, dass die Dynamikanforderungen, denen früher oder später alle unterliegen werden, andere Architekturen erfordern und Microservices als Paradigma in der Software-Entwicklung 4.0 eine Lösung bieten – allerdings nur in Kombination mit den anderen drei Paradigmen der Software-Entwicklung 4.0: Agile, Cloud und DevOps. Aus diesem Grunde empfehle ich auch die anderen Blogs zu dieser Serie:

und die 14 Praxistipps zur Umsetzung von Microservices meines Kollegen Ramon Anger.



[i] Nur die am Forum teilnehmende Architekten unserer Kunden konnten sich an der anonymen Umfrage beteiligen 

 

Über den Autor

Karl Prott
> Sehen Sie Microservices auch als SOA in neuen Schläuchen? Ja und nein. Nein, weil sich die Technik und die Architektur völlig geändert haben. So war zur Zeit von SOA noch SOAP der neuste Hype und von manchen fälschlich sogar als SOA-Protokoll übersetzt. Der ganze Wahnsinn mit ESBs die versprachen sämtliche Probleme der Welt zu lösen und doch nur wieder viele neue Probleme gelöst haben kam dann noch dazu. Heute gibt es ein völliges umdenken hin zu leichtgewichtigen und schlanken Lösungen. Insbesondere REST und JSON, was auch für die wichtige Welt der Browser alle Schnittstellen eröffnet. Aber gleichzeitig auch Ja, denn das Ur-Problem der SOA ist doch, dass man komplexe Datenmodelle nicht einfach beliebig auseinander reißen kann. Kommt dann die Anforderung einer übergreifenden Suche, die in verschiedenen Datenbeständen jeweils nur eingeschränkt selektiv ist verlagert man JOINs von der DB auf Anwendungsebene, was in einer Katastrophe endet. Die Daten dann am Service vorbei per DB-Link anzusprechen ist auch nicht gerade das ursprüngliche Ziel des ganzen. Auf diese Probleme bieten auch Microservices keine echte Antwort. Der Begriff Microservices impliziert durch das Micro zudem alles so klein wie nur irgend möglich zu zerhacken. Das führt aber auf den Holzweg. Fazit: Der Monolith ist tot. Zu komplexe Protokolle und Middelware wird aussterben und durch leichtgewichtige Lösungen ersetzt. Wir brauchen Anwendungslandschaften mit mehreren und kleineren Anwendungen. Aber Daten die zusammengehören darf man nicht auseinander reißen. Der erfahrene Architekt, der die Fachlichkeit durchdringt und in sinnvolle entkoppelte Einheiten zerlegt ist gefragter denn je. Leute, die nur einem Hype hinterher rennen und aus technischer Sicht Datenmodelle zerhacken, werden nur Chaos anrichten. p.s.: Das Problem der GUI-Integration haben wir inzwischen ganz elegant mit aktueller Browser-Technologie gelöst bekommen.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.