Welchen Herausforderungen müssen sich Entwickler im Zusammenhang mit Microservices stellen? Dieser Fragestellung widmeten sich Oliver Gierke und Eberhard Wolff in ihrer gemeinsamen Session auf der W-JAX 2015.

Neuerungen in Scala und reaktive Anwendungen mit Akka und CoreOS. Mit diesen beiden spannenden Themen tritt Heiko Seeberger (codecentric) auf der W-JAX-Bühne auf. Einen kleinen Vorgeschmack gibt er in diesem Interview – in dem auch die Frage nach dem Releasetermin von Scala 2.12 gestellt wird…

Dank des Hypes um Microservices mag es den Anschein haben, dass jedes Entwickler-Team und jedes Unternehmen sein monolithisches Empire zerstückeln muss, um dem allgemeinen Microservices-Trend zu folgen. Das aber ist nicht unbedingt jedermanns Sache, meint Holly Cummins (IBM), Sprecherin auf der diesjährigen JAX London…

Auf der W-JAX 2015 werden sich Tobias Bayer und Hendrik Still (beide inovex GmbH) mit der dunklen Seite der Microservices beschäftigen. Angefangen beim Monitoring über verteilte Transaktionen und die Testbarkeit bis hin zur Service Discovery gibt es einige Herausforderungen zu bewältigen, die neben den Vorzügen von Microservices im Talk eine Rolle spielen werden. Im Vorfeld standen uns die beiden für einige Fragen zur Verfügung…

Der Informatiker Simon Wardley hat im Juni 2015 unter dem provokativen Titel „Why Agile, Lean and Six Sigma must die“ eine Empfehlung abgegeben, wie große Systeme mit vielen Komponenten strategisch zu entwickeln sind. Mit seiner Map-Methode machte er deutlich, dass sich nicht für alle Komponenten zu jeder Zeit die gleiche Methode gewinnbringend einsetzen lässt. Was aber bedeutet das für Microservices und anti-fragile Architekturen?

Jeff Sussna plädiert dafür, die Entwicklung von Microservices auf DevOps-Niveau zu heben. Um dies zu erreichen, müssen Organisationen ihre Definition der System-Level-Qualität ändern: Von der Stabilität zur Resilienz. Beginnen wir damit, Microservices als die komplexen Systeme zu behandeln, die sie sind!

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.