Microservices auf der W-JAX 2015

Monolithe zerstören und Hypes die Luft rauslassen

Coman Hamilton

© Shutterstock/Joy Tasa

Sind die Vesprechen der Microservices wahr geworden? Sind sie immer besser als Monolithen? Und spart ein verteiltes System Geld? Hier kommen die Ratschläge verschiedener Microservice-Experten von der W-JAX 2015.

Schnell entwickeln, schnell veröffentlichen, flexibler, AB Test… Der Hype um Microservices reißt nicht ab. Das hat gute Gründe, erklärten viele Sprecher auf der diesjährigen W-JAX in München. Microservices helfen dabei autonome, unternehmens-übergreifende Teams zu bauen; Teams können unabhängig voneinander deployen. Sie können selektiv Technologien bauen, die spezifische Probleme lösen. Entwickler können für Austauschbarkeit designen.

Aber ist denn auch in Wirklichkeit alles rosarot?

Es sieht so aus als hätten alle Microservice-Experten eins gemeinsam. Sie machen gerne mutige Ansagen über die Macht von Microservices, um dann eine Warnung über zu viel Hype hinterherzuschieben: „If you mention one more buzzword, we’re going to have words“, sagte Markus Eisele zu seinem Co-Speaker Jan Wildeboer während ihrer Keynote über BizDevOps.

„Who uses Docker?“ fragte Eisele. Die Mehrheit der Hände der rund 1.000 anwesenden Entwickler schossen in die Höhe. „And who has managed to actually build something useful with it?“ Nur vier oder fünf Hände blieben oben. Die Lehre ist: Wir müssen den Versprechen der gehypten Technologien einen Realitätscheck unterziehen, vor allem den Microservices.

Wechsel nicht zu Microservices, wenn du Geld sparen willst

„The start is where it hurts“, sagte der Speaker Tobias Flohre. Man solle keine massiven Geschwindigskeitsteigerung über Nacht erwarten, warnte er. Und wenn das Budget für dein Team ein Problem ist, sind Microservices keine Lösung für dich. Tatsache ist, dass man sich dann von Microservices vollkommen fernhalten sollte.

Denn ein zerlegter Monolith spart keine Kosten. Vor allem am Anfang, bei der Implementierung eines radikal neuen Ansatzes, können alle Hindernisse, denen man begegnet, teuer werden. Wechsle niemals zu Microservices, um Geld zu sparen, zog Flohre als Fazit.

Währenddessen sollten man immer vorplanen und darüber nachdenken wie man Legacy-Systeme integrieren kann, erklärte Speaker Dennis Schulte. Unternehmen sind oft damit konfrontiert, dass sie eine neue Macro-Architektur mit HTTP REST dazu bekommen müssen auch mit dem alten, aber immer noch wichtigen Legacy-System zu kommunizieren.

Björn Stahl sagte, dass sein Team das Glück hatte auf der grünen Wiese anfangen zu können, sie konnten eine pures Microservice-basiertes System aufbauen. Normalerweise geniesen nur Start-ups diese Freiheit. Aufgrund der Altlasten eines Legacy-Systems lohnt es sich aber für Unternehmen darüber nachzudenken, ob es eine Möglichkeit gibt ohne sie zu leben.

Du brauchst keine Service Discovery in Monolithen

Man kann über die Agilität von Microservices sagen was man will, aber Monolithen haben auch einige Vorteile. Vor allem weiß man immer wo die einzelnen Komponenten sind. Wenn man aber den Monolith in ein verteiltes System zerlegt, verlieren die individuellen Komponenten automatisch die Fähigkeit die Ports und IP-Adressen der anderen Komponten zu verfolgen.

Eine Lösung dafür ist es, die Informationen hardzucoden, sagten Hendrik Still and Tobias Bayer. „Service A möchte mit Service B sprechen, also können wir die IP von B in A hardcoden.“ Das ist aber nicht die dynamischste Art und Weise Services kommunizieren zu lassen.

Der andere, populärerer Weg ist es eine Service Registry zu benutzen. Wenn ein Service den anderen finden will, fragt er einfach die Registry, eine Art Adressbuch. Das bekannteste Tool dafür ist Netflix‘ Eureka, eine Single Purpose Registry, die speziell für dieses Problem entwickelt wurde. Die Service Registry mit einem einfachen REST Interface und einem Java-Client ist nach den Worten des Netflix Teams „primarliy used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers“.

Autonomie ist großartig

Wie viele mittlerweile wissen, hat ein Team die Herrschaft über einen Microservice. Das ist eine großartige Sache, waren sich die meisten Speaker einig. Es bedeutet, das ein Team genauso die volle Kontrolle über Technologie- und Architektur-Entscheidungen wie über die Datenverwaltung. Es gibt also keine Mauer zwischen der Entwicklung und der Verwaltung eines Services.

Nichtsdestotrotz endet die Autonomie eines Microservice Teams immer, wenn es um das Thema Macro-Architektur geht. Sobald ein Microservice beginnt mit anderen Services zu kommunzieren, müssen Teams natürlich mit anderen Teams zusammenarbeiten. Und verlieren dadurch an Autonomie. Diese Macro-Architektur-Kommunikation muss ein anderes Team definieren, in den meisten Fällen das Software-Architektur-Team. Das hat eventuell auch weniger zu tun, weil viele seiner Aufgaben jetzt bei den autonomen Teams liegen.

Vielen sind bereits die Grundsätze von service-orientierten Architekturen begegnet: Grenzen sind explizit, Services sind autonom (nicht nur die Teams, sondern auch die Runtime), Services teilen Schema und Veträge, aber keine Klassen. Und die Service-Kompatibilität basiert auf einer Richtlinie. Klingt nach Microservices, oder? Eine abschließende, positive Lehre kommt daher von Dennis Schulte, der uns erklärt, dass „Microservices eigentlich SOA in richtig sind“.

Aufmacherbild: It is broken brick wall pattern von Shutterstock / Urheberrecht: Joy Tasa

Verwandte Themen:

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: