Microservices: Kaum ein Architekturstil befindet sich zur Zeit derart im Schlaglicht der Aufmerksamkeit. Für all jene, die sich bislang trotzdem noch nicht genauer mit ihnen beschäftigt hat, hat IT-Guru Martin Fowler einen ausgezeichneten Leitfaden zusammengestellt.

„Pacta sunt servanda“, oder zu deutsch „Verträge sind einzuhalten“: Was schon im Mittelalter galt, soll in der modernen Welt der Software auch verbindlich sein. Mithilfe von (API-)Verträgen, die nicht nur durch einen, sondern mehrere Vertragspartner gestaltet werden, lassen sich Microservices-Architekturen einfach und effizient testen und weiterentwickeln.

Über das Für und Wider von Microservices wird nach wie vor lebhaft diskutiert. Während manche dem neuen Architekturstil eher zurückhaltend und abwartend gegenüberstehen, werfen sich ihm andere mit offenen Armen entgegen. Vor allem für letztere hat Christian Posta, Middleware-Spezialist und Architekt bei Red Hat, aktuell einen Tipp parat: Demnach geht es bei der erfolgreichen Arbeit mit Microservices in erster Linie nicht um bestimmte Technologien wie Docker, Kubernetes oder SpringBoot.

Erst kürzlich hatte sich der Veteran der Softwarearchitektur Martin Fowler in die Diskussion um Microservices eingemischt und davor gewarnt, sie als Basis eines Systems zu verwenden. Da seine Meinung zum Thema jedoch nicht abgeschlossen ist, legte er nun mit einer Gegenüberstellung der Vor- und Nachteile von Microservices nach. Denn, wie Fowler ausführt, sind Microservices kein Allheilmittel, sondern verursachen wie jeder Architekturstil auch gewisse Kosten, die im Blick behalten werden müssen.

Microservices sind aktuell einer der Trends in der Softwarearchitektur. Natürlich sollte man mit solchen Buzzwords und Hype-Themen vorsichtig sein. Allerdings gibt es bereits einige Branchen-Größen (z. B. Netflix), die diesen Architekturstil produktiv einsetzen. Zudem ist mittlerweile auch eine Vielzahl von Bibliotheken im Microservices-Umfeld entstanden.

Che ist ein Java-Framework, das der Erstellung verteilter und lose gekoppelter Anwendungen dient, die über einen browserbasierten Client sowie serverseitige RESTful Services verfügen. Die Anwendungen werden durch Zusammensetzen von Extensions gebaut und folgen zahlreichen Grundsätzen der Eclipse RCP.

Worum geht es bei Microservices? Welche Änderungen können Entwickler erwarten, wenn sie von einem Monolithen auf Microservices umsteigen? Und wie fügt sich DevOps in das Ganze ein? Dr. Mark Little, Vice President of Middleware Engineering bei Red Hat, erläutert die Grundlagen des Monolithe zerstörenden IT-Trends.

Vor kurzem hat sich Martin Fowler in der aktuellen Diskussion um Microservices zu Wort gemeldet, indem er das negative Bild von monolithischen Software-Architekturen zurechtrückt und die großen Systeme als ersten Ausgangspunkt von Microservices empfiehlt. Nun widerspricht Stefan Tilkov: Monolithen seien gerade kein geeigneter Ansatz für den Bau von Microservices. Werden sie zerlegt, sieht das Ergebnis meist anders aus, als von den Entwicklern erhofft.

Microservices sind zur Zeit in aller Munde: Vielstimmig werden sie als optimale Lösung gefeiert, um monolithische Architekturen zu überwinden. Doch mitunter sind auch gegenteilige Meinungen zu vernehmen. Martin Fowler, Urgestein der Softwareentwicklung, hat nun – basierend auf den Überlegungen zahlreicher Kollegen – zumindest eine kleine Lanze für die Monolithen gebrochen.

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.