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