Figur auf Einrad balancierend auf DrahtseilDie erste code.talks Konferenz diese Woche in Berlin hatte diverse Panel zum Thema Microservices im Programm. Nachdem der unsägliche NoSQL-Hype vor ca. zwei Jahren seinen Höhepunkt erreicht hatte “Warum machst du das denn noch mit relationalen Datenbanken?”, hat sich das Thema Microservices bei den Diskussionen um Backend-technologien ganz nach vorne geschoben. Die Frontendler haben dazu noch zusätzlich mit React, Node & Co. ein ganz eigenes Spielchen entwickelt, das scheinbar niemand mehr durchschaut. Seit nun fast zwei Jahren Spryker habe ich das Vergnügen diese technischen Diskussionen live verfolgen zu können. In meiner Zeit bei Otto gab es noch ein ganz klar definiertes technisches Feindbild, das sogenannte Host System, bzw. die AS400 Maschinen, die bei allen großen Händlern im Einsatz waren. Nicht wartbar, uralt, mega Codespaghetti, alles hing davon ab usw… Wenn die erst mal weg wären, dann wird alles gut – wurde mir gesagt. Auf der anderen Seite waren die Business Kasper, zu denen ich auch gehöre, für die Technologie nur Mittel zum Zweck war. Aus meiner damaligen Sicht waren die Leute in der IT die harten Arbeiter, ganz pragmatische Denker, nur dem System verpflichtet und immer mit dem Ziel eine hohe Wartungsfähigkeit zu erreichen. Bei den Businessleuten gab und gibt es die, die sich mit aus meiner Sicht unsinnigen Strategien beschäftigt haben und irgendeinen Quarck von Omnichannel, Multikanal, Zielgruppenshops & Co. gefaselt haben. Diese Strategien waren in den letzten acht Jahren Kassenzone immer mein erklärter Endgegener, sie zu widerlegen und neue Ansätze aufzuzeigen, das war mein Ziel.

Zu meiner großen Enttäuschung muss ich nun feststellen, dass die Leute in der IT, bzw. Developer wie sie heute genannt werden, mit den gleichen Denkmustern arbeiten wie die Business Kasper. Es gibt eine extrem hohe Neigung Trends hinterherzulaufen und grundlegende technische Probleme nicht ausreichend bzw. nicht ehrlich genug zu analysieren. Microservices ist hierfür gerade ein schönes Beispiel. Das ist weder eine IT Strategie noch ein Architektur Pattern, es beschreibt höchstens eine Art der IT & System Organisation. Genauso wie Omnichannel übrigens. Omnichannel bedeutet gar nichts, es ist eine Worthülse die in der Regel mit viel „Blub“ gefüllt wird, und das gleiche Muster liegt beim Thema Microservices vor. Omnichannel kann von außen betrachtet das Ergebnis starken Wachstums sein, wenn ein Unternehmen es also schafft mit seinem Angebot in vielen Kanälen führend zu sein. Genauso verhält es sich mit Microservices, die das Ergebnis eines starken IT Wachstums sein dürften, weil man große Applikationen in Services teilen muss, damit nicht zu viele Entwickler gleichzeitig daran arbeiten. Es ist aber damit noch lange keine IT Strategie. In vielen Gesprächen bei der Code.Talks Konferenz hat sich dieser Eindruck (leider) bestätigt. Yoav Kutner (Gründer Magento1) hat seine Erfahrungen beim Roll Out der ersten großen Magento1 Projekte gemacht und berichtet auch nur kopfschüttelnd, dass Developer gerne dem nächsten Hype folgen ohne sich darüber Gedanken gemacht zu haben wo das konkrete Problem eigentlich liegt. Ja, ich weiß, das klingt nun alles sehr pauschal, aber lasst uns das mal am Thema Microservices genauer anschauen.

Martin Fowler, ein IT Guru und Microservices Verfechter hat dutzende Beiträge zu dem Thema geschrieben und beschreibt Microservices wie folgt:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Das klingt schon mal sehr vielversprechend und bei entsprechenden Problemen kann das auch weiterhelfen. Das IT Team von Otto ist in diesem Bereich schon Champions League und hat mit dem “On Monoliths and Microservices” einen Pflichtartikel in diesem Bereich produziert. Über dieses Thema hat Guido von Otto auch bei der code.talks referiert.

When we began the development of our new Online Shop otto.de, we chose a distributed, vertical-style architecture at an early stage of the process. Our experience with our previous system showed us that a monolithic architecture does not satisfy the constantly emerging requirements. Growing volumes of data, increasing loads and the need to scale the organization, all of these forced us to rethink our approach.

Es gibt auch noch andere Beispiele die hervorragend von diesem Ansatz profitieren. Zalando z.B. die auch recht offen mit ihrer “From Jimmy to Microservice” Erfahrung umgehen. Und auch für sehr schnell wachsende Tech Teams wie bei Siroop kann der Ansatz aufgehen. Was bei den vielen Lobeshymnen aber oft vergessen wird, sind die Kosten die mit so einem Ansatz einhergehen. Martin Fowler nennt diese Kosten das sogenannte Microservice Premium und warnt ausdrücklich davor leichtfertig in diese Richtung zu gehen.

The microservices approach is all about handling a complex system, but in order to do so the approach introduces its own set of complexities. When you use microservices you have to work on automated deployment, monitoring, dealing with failure, eventual consistency, and other factors that a distributed system introduces. There are well-known ways to cope with all this, but it’s extra effort, and nobody I know in software development seems to have acres of free time. So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.

microservice-premium

Rein technisch hat diese Restriktion sehr viele Ursprünge. Ob das nun die Latenzen sind, die aufgrund dutzender aktiver Services für einen Vorgang aufgerufen werden müssen, das deutlich schwierigere Debugging, das anspruchsvolle Hardwaresetup oder die sehr komplexe Datenhaltung (jeder Service mit eigener Datenbank). Vom grundsätzlich schwer zu managenden Technologiezoo mal ganz abgesehen. An dieser Stelle lassen sich wieder hervorragende Parallelen zu E-Commerce Organisationen ziehen. Wer ist schneller und effektiver beim Aufbau und der Skalierung neuer Modelle:

  1. Ein Konzern mit dutzenden Abteilungen und Direktionen die sich permanent abstimmen müssen, die in ihren Disziplinen aber jeweils extrem gut sind.
  2. Ein Unternehmen bei dem bis zu 100 Mitarbeiter in einem Raum sitzen und alle wissen was gerade passiert und alle miteinander reden.

Schneller ist 2), da müssen wir nicht groß diskutieren. Bei großen Modellen bei der es um die Skalierung eines eher gleichbleibenden Ansatzes geht, ist 1) allerdings besser. Das ist bei Microservices nicht viel anders. Um diesen Zusammenhang besser zu verstehen ist der Text von Werner Vogels (Amazon CTO) zu seinen Learnings mit AWS sehr lesenswert.

We needed to build systems that embrace failure as a natural occurrence even if we did not know what the failure might be. Systems need to keep running even if the “house is on fire.” It is important to be able to manage pieces that are impacted without the need to take the overall system down. We’ve developed the fundamental skill of managing the “blast radius” of a failure occurrence such that the overall health of the system can be maintained.

Obwohl es also bei ausreichender Beschäftigung mit dem Thema recht gute Leitplanken gibt, um herauszufinden, ob Microservices für eine IT Organsiation Sinn machen (für die meisten nein!), finden sich auf Konferenzpaneln oder im Web regelmäßig solche Beiträge wie der von Sam Gibson:

In principle, it is possible to create independent modules within a single monolithic application. In practice, this is seldom implemented. Code within the monolith most often, and quickly, becomes tightly coupled. Microservices, in contrast, encourage architects and developers the opportunity to develop less coupled systems that can be changed faster and scaled more effectively.

In die Sprache der Kassenzone Leser übersetzt steht da so viel wie: Pure Play Geschäftsmodelle sind gut, wenn sie ordentlich umgesetzt werden, aber richtig gut wird es erst, wenn man mehrere Kanäle exzellent betreibt. Omnichannel ist die Winning Strategy. Nun könnte man solche Aussagen einfach abtun, aber es ist erstaunlich wie stark und schnell sich solche einfachen Denkmuster verbreiten und ganz selbständig zu Wahrheiten werden. Die Stimmen die sich diesem Muster entgegenstellen sind vergleichsweise leise, aber die Argumente sind sehr schlüssig.

Finally, a word about nomenclature. Some advocates of micro-services like to classify the alternative as monolithic. This is a pejorative term chosen to imply: „Bad“. The word monolith means „one rock“. The implication is that if you aren’t using micro-services, then you must have a big coupled monstrosity. That’s Marketing Baloney. A well designed system following the Clean Architecture is about as far from a monolith as you can get.

Technisch und methodisch spricht sehr viel für die Nutzung “guter” monolitischer Strukturen für sehr viele E-Commerce Unternehmen. Dafür muss man sich aber auch sehr anstrengen, um guten Code zu produzieren, etwas was man kurzzeitig in der Microservices Welt nicht muss. Wenn dann aber ein Fehler in der Skalierung auftritt, würden sich die betroffenen CTOs wahrscheinlich das AS400 System zurückwünschen.

Der Basecamp Gründer hat das auf die Spitze getrieben und beschreibt sein System als “The Majestic Monolith”. Und inhaltlich bin ich voll bei ihm:

Where things go astray is when people look at, say, Amazon or Google or whoever else might be commanding a fleet of services, and think, hey it works for The Most Successful, I’m sure it’ll work for me too. Bzzzzzzzzt!! Wrong! The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting. If I dance like these behemoths, surely I too will grow into one. I’m sorry, but that’s just not how the tango goes.

Es ist ein wenig so als wollen die Unternehmen, die bisher ein sehr altes Fahrrad haben, welches sie selber gar nicht so richtig fahren können, einfach zu viel. Sie sehen im Zirkus die Einradfahrer die herrliche Tricks mit ihrem Einrad vollbringen können und sagen sich: Mein Fahrrad ist zu alt, deshalb kann ich es nicht fahren. Ich fange direkt mit dem Einradfahren an; das ist wenigstens zukunftsfähig.

Soviel zu den Beobachtungen eines Nicht ITlers in die Welt der Developer. Wenigstens konnte die Multichannel Lüge bereits widerlegt werden. Wer hätte übrigens gedacht, dass Otto die Welt der Einradfahrer gerade so dominiert? Danke auch an dieser Stelle an die vielen objektiven Diskussionsbeiträge bei der code.talks Konferenz. Dirk Hoerig (commercetools), Yoav Kutner (Oro) und Ulrike Müller (Demandware/Newstore) konnten in den Panel sehr gute Punkte rausarbeiten, um den Unternehmen bei der Einordnung zu helfen.

English version of this post @ medium.com

Neue Beiträge per E-Mail abonnieren.

Deine Anmeldung konnte nicht gespeichert werden. Bitte versuche es erneut.
Danke! Bestätige deine Anmeldung bitte in der Mail, die wir dir soeben geschickt haben.