Microservices & Einradfahren

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

Alexander Graf, 37, E-Commerce Unternehmer & Analyst, Gelernt bei der Otto Group, danach über 10 Unternehmen gegründet, heute u.a. Gründer Geschäftsführer des führenden Commerce Technologieanbieters Spryker Systems. Im Juni 2015 hat er das E-Commerce Buch veröffentlicht, das seitdem die E-Commerce Rankings anführt. Weitere Infos hier, oder direkt kontaktieren unter: alexander.graf@etribes.de || Tel: +49 (40) 3289 29690

Neue Beiträge abonnieren

28 Antworten

  1. Peter Marx sagt:

    Der sehr lesenswerte Beitrag wäre sehr viel einfacher zu lesen, wenn nicht in jedem zweiten Satz ein Deppenleerzeichen vorkommen würde. Da muss man jedes Mal kurz inne halte und sich aufregen.

    • Nach meinen sehr mäßigen Erfolgen im Deutschunterricht bin ich ja schon froh soweit gekommen zu sein 🙂 Deppenleerzeichen haben ich nun gegoogelt und gebe das direkt zur Textaufsicht weiter. Vielleicht wir das morgen noch mal angepasst. 🙂

  2. Tweety Muc sagt:

    Nun, kommt mir irgendwie bekannt vor. Wir verstehen unser altes System nicht, ist zu monolytisch und komplex. Also bauen wir ein noch komplexeres System, das werden wir dann bestimmt besser verstehen. Techies sind halt Spielkinder und natürlich spielt man gerne mit dem neuesten Spielzeug. Über die gesteigerte Komplexität macht sich keiner Gedanken und in ein paar Jahren kommt dann wieder einer und sagt: das alte System ist total out, wir müssen zurück zu monolytischen Systemen und …. naja, den Rest kann sich jeder denken, SAP zum Beispiel geht im ERP Bereich genau diesen Weg weg von verteilten Systemen hin zu einer HANA für alles. Aber somit haben ITler immer Arbeit 😉

  3. Sören Martius sagt:

    Hi Alex,

    Endlich mal kritischer Artikel bezgl. Microservices.

    In meinem aktuellen Projekt begleite ich eine Firma auf dem Weg vom homogenen Monolithen zur heterogenen Microservice-Architektur. Mal von den bereits vielen genannten Pro- und Kontraargumenten abgesehen, gefällt mir vor allem, dass Services nicht zur Wiederverwendbarkeit, sondern zum Austauschen designed werden.

    In einer gelungenen Microservice-Architektur gibt es außerdem keinen richtigen Single Entry Point mehr. Ein oft unterschätzter Punkt ist aber die Hiring Situation und das allgemeine Know-How des Teams. Eine klassische Magento Bude wird es immer schwer haben den Wechsel zu einer – ich nenne es mal – optimaleren Lösung Hinsichtlich Skalierung hin zu bekommen.

    Wir haben vor ein paar Monaten auch noch „nur“ mit PHP gearbeitet, durch den Wechsel zu Microservices bekommen die Entwickler eine Chance sich mit Sprachen wie z.B. GO, Scala, oder gar komplett funktionalen Programmiersprachen wie Clojure oder Haskell zu beschäftigen ( für moderne Multicore Prozessoren sind funktionale Programmiersprachen die einzige sinnvolle Lösung ).

    Immer nach dem Motto: Wir bauen einen Service in PHP und den gleichen dann noch einmal in Go. Die schlechtere Lösung schmeißen wir weg. Außerdem wächst das Know-How des Teams enorm.. Das Problem mit PHP war schon immer, dass zu viele Wege nach Rom führen und es wenig Beispiele für wirklich Programmierung oder Einsatz von Pattern gibt. Durch z.B. die Symfony Community hat sich dort in den letzten Jahren viel getan.

    Zuletzt ist noch ein wichtiger Punkt, dass Microservices dem Team ermöglichen sollen, einzelne Services so oft wie nötig zu deployen. Dazu kommt die Möglichkeit des A/B Testens verschiedener Service-Implementierungen gegeneinander.

    Am Ende des Tages hast Du natürlich Recht mit der Aussage, dass das Thema auch ein riesen Hype ist. Zumindest eine „Service Oriented Architecture“ ist nichts Neues. Und das Konzept von Microservices gibt es in Unix Distributionen schon seit Jahrzehnten ( cp, cat, rm, etc –> alles einzelne unabhängige Services ).

    Auch macht es sicherlich für die meisten Unternehmen keinen Sinn damit anzufangen.

    Wer weiß, vielleicht bewegt sich der Trend in 2 Jahren wieder zum homogenen Monolithen.

    • Sören Martius sagt:

      Achja: Nicht zu Vergessen. Auch das Frontend lässt sich in entsprechende Microservices aufteilen. ( Composite Frontend )

  4. Microservices sind mMn nur eine Verschiebung von Komplexität hin zu den Schnittstellen der Services. Dennoch denke ich dass der grundsätzliche Ansatz dahinter korrekt ist: schaffe kleine wartbare Einheiten, um die Komplexität deines Systems im Griff zu behalten. Ob man dann den Stempel Microservices noch oben drauf setzen muss sei dahingestellt.

    • Die „Kritik“ ist ja eher, dass es mittlerweile viele Setups gibt, bei denen die kleinen Einheiten wartbar geworden sind, aber das Gesamtsystem sich kaum noch weiterentwickelt, weil die Abhängigkeiten zu sehr einschränken.

      • Sebastian sagt:

        Wenn man Microservices wie reguläre Methoden in der Softwareentwicklung verwendet und Kaskaden an Aufrufen provoziert (Microservice ruft Microservice auf), dann gewinnt man in der Tat wahrscheinlich in den seltensten Fällen etwas dazu.

        Ansonsten treten Microservices ja gerade deshalb an, um Funktionalitäten unabhängig von irgendwelchen Legacysystem zu ermöglichen. Die Frage ist aber, wie groß denn nun ein Microservice im konkreten Fall sein sollte. „Viele kleine Einheiten“ hört sich nach keinem durchdachten Konzept an.

  5. Robert sagt:

    Erstens: du solltest zwischen Feature-Developern und Infrastruktur-Developern unterscheiden. Fefe hat dazu mehr: http://blog.fefe.de/?ts=a8e8447c

    Zweitens: zwischen dem Monolithen und den Microservices gibt es übrigens auch noch die SCS (Self-contained Systems). http://scs-architecture.org/vs-ms.html In dieser Kategorie sehe ich beispielsweise auch Spryker.

    All das sollten aber nur Rezeptvorschläge für das konkrete Projekt sein. Vor allem wenn ich einen Monolithen (noch) betreiben muss und händeringend nach Möglichkeiten suche, dem Lock-in zu entkommen. Da sind die MS oder die SCS ein verheißungsvolles und erstrebenswertes Ziel. Auch oder alleine schon als Diskussionsgrundlage für „Wie machen wir denn jetzt weiter?“-Runden. Ob das aber auch sinnvolle und nachhaltige Ziele sind, ist eine andere Diskussion und hängt vom Einzelfall ab. Bei Otto hat es ja geklappt. Das Oracle-Monster ist weg.

    Für die Greenfield-Verfechter sind MS oder SCS aber, meiner Meinung nach, auch durchaus sinnvoll. Denn richtig geplant, gebaut und betrieben sind sie ein Garant für lang anhaltende Wartbarkeit in Verbindung mit hoher Manövrierfähigkeit. Als Designziel also – warum nicht?

    Mal sehen wo die Reise hingeht.

  6. Martin sagt:

    Endlich verstanden! SOA reloaded!

    • Sebastian sagt:

      Das kann man so nicht sagen. Das Ziel beider Ansätze ist identisch, nämlich neue Anforderungen schneller und einfacher umzusetzen. Nur die Wege sind unterschiedlich:

      SOA beinhaltet Services die nur relativ selten geändert werden. Ein Service eines ERP-Systems wie SAP R/3 wird beispielsweise nicht alle paar Tage modifiziert.
      Die einzelnen Services werden dann in der Regel über ein Portal (UI und Orchestrierung) den Anwendern zugänglich gemacht.

      Microservices/SCS sind hingegen viel isolierter. Ein Team entwickelt aufgrund von fachlichen Anforderungen einen Service der dann unabhängig von irgendwelchen Portalservern deployt werden kann. Bei SOA muss immer eine sehr enge Absprache mit allen anderen Parteien erfolgen, damit es zu keinem Bruch kommt.
      Microservices/SCS verfolgen hingegen den Ansatz von anderen Services unabhängig zu sein; deshalb auch die getrennte Datenhaltung je Service.

  7. Unabhängig von den Vor- und Nachteilen, die Microservices / SCS so mit sich bringen, sind dies IMHO die technologischen Begleiter agiler Teamstruktur und -werte (kleine, unabhängige Teams, die schnell und flexibel arbeiten können – dies braucht auch eine entsprechend technische Abbildung).

    Wenn man Conway’s Law zugrunde legt, könnten Microservices / SCS die logische Folge der Kommunikations-Struktur sein, die sich durch kleine, unabhängige Teams zwangsweise ergeben.

    Ist das logisch so stimmig?

    • Da würde ich auf jeden Fall zustimmen. Die Frage ist ja eher wie die Teams orchestriert werden bzw. ob alle einen eigenständigen Scope haben. Was mE beim Microservices Versprechen fehlt bzw. was gerne mißachtet wird, ist die Orientierung am Business. Was bringen denn 20 Services, wenn ich trotzdem keine kundenrelevanten Features auf meine Plattform bringen kann. Die kleinen Schritte in der Entwicklung der Services sind für den Kunden meist kaum sichtbar. Verglichen mit deinem Teamansatz heißt das, dass man 20 agile Teams in einem Startup loslaufen lässt und diese Teams treffen sich jeden Tag und erzählen was sie so gemacht haben. So kommt aber kein Business zustande. Microservices erscheinen extrem demokratisch, aber ich meine, dass in den meisten IT Projekten eher eine Diktatur notwendig ist, wenn die Teams nicht zu groß sind (unter 50-100 Leuten)

      • „So kommt aber kein Business zustande.“

        Naja klar. Du willst ja den Wert des Produkts maximieren und damit auch Wert für den Endanwender schaffen. Das geht meist dann gut, wenn du die externe Referenz – den Endanwender – mit einbeziehst, und dich nicht nur auf die Feature-Phantasien des internen Produktmanagers verlässt. 🙂

        Taktiken zB validiertes Lernen aus Lean Startup usw.

        Diktatur: hmmm, interessant. Musst du mal genauer erklären?!

  8. „Vom grundsätzlich schwer zu managenden Technologiezoo mal ganz abgesehen.“

    Alexander, das („managen“) ist genau das, was du eigentlich nicht mehr willst. „Embrace failure“ wenige Zeilen später schlägt in die gleiche Kerbe.

    Gemäß „You build it, you run it“ braucht’s auch keine zentrale IT mehr, die sich um das „managen“ des Technologie-Zoos kümmert, denn das machen ja die einzelnen Teams, die in der Verantwortung für ihren Teil stehen.

    „Riding the wave of uncertainty“, so plakativ es auch sein mag, darum geht’s doch eigentlich. Der Sog des Marktes gibt den Takt vor, und nicht das „Handbuch der zertifizierten und bei uns einsetzbaren IT-Technologien“ des internen IT-Stabs.

    • mhh, also eine komplette Systemlandschaft nach klassischen ERP Regeln managen, das geht wohl in der Tat nicht mehr. Einen konkreten Scope managen (Shop, PIM, ORM), das ist aber doch super möglich und sorgt für Geschwindigkeit. Wer orchestriert denn die Teams? IT ist ja kein Selbstzweck, sondern muss idR irgendeiner Business zuliefern. Wer stellt denn fest, dass das Team „Suche“ in den letzten 12 Monaten komplett unbrauchbaren Mist gebaut hat? Wer springt dann ein? Wer entscheidet?

      • Das Team hat ja – also wenn wir jetzt im agilen sprechen – immer einen Product Owner. Der ist für die Wertmaximierung des (Teil-)Produkts zuständig. Die POs sollten sich natürlich synchen.

        Das habe ich am „Inside otto.de“-Vortrag ein wenig vermisst, dass darauf eingegangen wird, wie das dort gehandhabt wird. Natürlich braucht’s eine wie auch immer geartete Koordination/Sync, schließlich geht es ja um ein Gesamtprodukt. Also mindestens eine Mission für die Teams, IMHO auch durch die Makro-Architektur-Prinzipien ausgedrückt. Und dann ist halt die Frage, wie tight du hier gehen willst und wieviel Freiheiten du lassen willst. Nicht so viel tightness kann ja auch durchaus eine Chance auf einem hochdynamischen Markt sein.

        In meinem Vortrag auf http://de.slideshare.net/BjoernSchotte/lets-rock-it-denkwerkzeuge-fr-moderne-organisation-und-it bin ich ja auch auf das Denkwerkzeug „Social Cohesion“ eingegangen. Je stärker diese ist – so die These – desto weniger innovationsfähig bist du als Unternehmen. Die Aufgabe besteht also hier, genau den richtigen „sweet spot“ zu finden, der genügend cohesion einfordert, damit die Org nicht auseinanderbröselt, aber trotzdem so loosely coupled in der Org ist, dass die Innovationskraft zum Wettbewerbsvorteil wird.

        Die Orchestrierung der Teams würde für mich anhand des Value Streams erfolgen. Und der beginnt halt bei der externen Referenz, dem Kunden. Alle liefern diesem zu.

        • Also da würde ich mitgehen, wenn ein Service in der Lage ist einen Kunden komplett zu bedienen. PIM könnte z.B. ein Service sein und der Kunde von PIM ist das Team, das Produktdaten verwaltet. Der Shop hat aber idR nur den Endkunden aus dessen Sicht Anforderungen definiert werden und deshalb dürfen das auch nur ein, zwei ggf. drei Services sein die sich noch effizient abstimmen können, um auf Anforderungen zu reagieren.

          Was mE nicht geht sind technische Einheiten in Services zu teilen obwohl sie zusammen einen Kunden bedienen. Der Abstimmungsaufwand wird in so einem Fall schnell größer als der Vorteil etwas in kleineren Einheiten besser managen zu können.

          • Ich kann deinen Punkten folgen. Sie sind IMHO auch logisch schlüssig. Prinzipiell könnte ich dir zustimmen. Will ich aber noch nicht. 😉 Mich reizt die andere Gedankenwelt. Lass sie uns mal durchdenken:

            Die gängige Organisations-Partitionierungs-Logik im Agilen kennt für jedes Team einen Product Owner als „Single Source of Truth“ für das, was gebaut wird. Die Loge der Product Owner hat sich dann untereinander abzustimmen. Konzepte wie SAFe, Nexus, LeSS etc. kennen dafür unterschiedliche Mechanismen und werden beliebig kompliziert.

            Soweit, so gut.

            Abstimmung und „managen“ kommt zu einem Preis, und der ist möglicherweise kein kleiner. Das Leben ist ja eine Aneinanderreihung von TradeOffs (mhm, Kalenderblatt-Spruch).

            Microservices usw. sind auch kein Allheilmittel. Im Artikel schreibst du ja auch, dass man sich sehr genau überlegen sollte, wie man schneidet.

            Ein Shop kennt diverse Personas von Endkunden. Was du IMHO brauchst, ist das kollektive Wissen in den Teams, was diese Personas ausmacht. Am Ende willst du doch Lernumgebungen schaffen: nicht der Produktmanager (sorry, Leute) mit der besten Phantasie soll sich durchsetzen, sondern das, was du im Team als Kollektiv über deinen Kunden lernst, indem du permanent Experimente durchführst. Das kommt der Marktdynamik entgegen, weil da kommt der Sog von außen.

            Sicherlich brauchst du übergreifende Themen wie UX – die schaffst du aber am besten über lose gekoppelte Communities of Practices, in der die UXer die in den Teams sitzen sich regelmäßig treffen und unterhalten. Durch die gemeinsame Unterhaltung entsteht ein shared mental model und damit ein kollektives Wissen über alle unabhängigen Teams hinweg.

            Mir ist noch nicht klar, was du genau gemanaged haben willst. Die Anforderungen werden geleitet durch den Endanwender und die dazugehörige Lernumgebung mit Rückkopplungen. Im besten Fall hast du je Team einen Product Owner, der sich mit dem Team um das Definieren der User Stories kümmert. Die USs implementierst du zu den geringsten Grenzkosten, um die frühestmögliche Lernerfahrung zu schaffen (dh. um so schnell wie möglich zu liefern, damit du anhand des Nutzerinteresses testen kannst ob du in die richtige Richtung läufst).

            Wenn ein einzelnes Service-Team sich um das Thema „Suche“ kümmert, dann kann es sich ganz gezielt darum kümmern, die beste Such-Experience zu liefern. Und zwar „Suche“ als Thema aus funktionaler Sicht.

            Ok, warum Amazon das mit seinem A9 immer noch nicht so dolle kann, müssen wir die Leute da mal fragen 😉

            Am Ende unterliegen wir doch alle der Kontroll-Illusion. Und wie gesagt, managen kommt zu einem Preis, je nach Managing-Grad ist der hoch oder weniger hoch.

            Ich verstehe es so, dass der sweet spot gesucht werden muss, der das Optimum an Flexibilität und Geschwindigkeit erlaubt, weil genau das den Wettbewerbsvorteil bringt, der dich auch Morgen noch im Geschäft hält.

            Aber vielleicht sollten wir das mal in nem Hangout on Air oder so diskutieren. Möglicherweise verstehe ich dich auch falsch. 🙂

  9. @Björn:

    Für die Diskussion ist das Kommentarformat wahrscheinlich nicht geeignet. Zeit für deinen Gastbeitrag! Aber ein Gedankenspiel dazu habe ich noch:

    Nehmen wir doch mal ein E-Commerce Unternehmen, dass eine Plattform neu aufbauen will. Das Tech Team hat 20 Developer und ein paar PMs/POs. Die zwei gedanklichen Extreme sind doch:

    a) Eine Applikation (sauber programmiert und intern entkoppelt) an der alle Leute mitarbeiten. Eine Datenbank, eine Deployment Umgebung….
    b) 20 Applikationen die als eigenständige Services laufen und jeweils von einem Developer gemanaged werden. Ggf. werden 5 unterschiedliche Sprachen verwendet (siehe dein Metro Beispiel von der Code Talks)

    Was ist besser? Was performed? Was ist stabiler? Das ist pauschal schwer zu beantworten, aber in meine These ist, dass a) in den meisten Fällen besser skaliert. Ggf. machen wir dazu mal ein Interview. Deal?

    • Jepp, sehr gerne.

      Hatte ich schon gesagt, dass ich nicht unbedingt Pro Microservices bin und das von Situation zu Situation auch immer unterschiedlich zu bewerten ist? 😉

    • Valentin sagt:

      Der Ansatz „Ein Kunde – ein bis drei Services“ greift zu kurz weil IT-Services einfach zu unterschiedlich sind. Das Beispiel PIM vs. Webshop zeigt das eigentlich ganz gut.
      Ich glaube, es führt nicht weiter, eine Korrelation zwischen Unternehmens-Größe oder -Situation und idealer Architektur-Komplexität zu beschwören. Faktoren wie Strategie, Teams, Knowledge, Erfahrung u.v.m. haben einen ebenso großen Einfluss auf die Auswahl der richtigen IT-Strategie und -Architektur und verfälschen diesen vermeintlichen Zusammenhang daher zu stark.

      Wie du oben sagst: Man will flexibel und schnell sein. Das gilt aber nicht nur für die IT, sondern ebenso für die Organisation selbst. Daher: In einer perfekten Organisation und IT gebe ich dir recht: Die in meinen Augen effizienteste Organisationsform ist das Ein-Mann-Unternehmen. Da es hier keine Schnittstellen-Reibungen gibt, performed es ideal. Ähnlich in der IT: Ein perfekter Monolith ist nicht zu schlagen.
      Der Microservice-Ansatz erhält seine Berechtigung aus der Erkenntnis, dass mit zunehmender Größe (sowohl in der Organisation als auch in der Software) die Qualität und Effizienz der Prozesse abnimmt. Um diese Reibungs-Probleme zu handlen, setzen Organisationen auf Verantwortlichkeiten und klare Schnittstellen, es werden Teams und Abteilungen gegründet. Microservices bzw. klar getrennte Entwicklerteams übernehmen dieses Konzept und machen es zu einer Architektur-Philosophie, indem sie dem Kind einen Namen geben. Klare Verantwortlichkeiten, Strukturen und Schnittstellen unterstützen dabei, das ganze System zu managen. Schlussfolgerung: Da es ab einem bestimmten Level keine perfekte Organisation mehr gibt, kann das Microservice-Denken, gepaart mit einem sehr guten Management, den zweitbesten Weg in Richtung Geschwindigkeit und Flexibilität darstellen.

  10. Matt sagt:

    Schöne Verteidigung von monolithischer Software. Muss es auch geben, gerade wenn man Spyrker verkaufen will…

    Aber noch viel schöner: „Das IT Team von Otto ist in diesem Bereich schon Champions League“ (gemeint ist damit wohl der Neubau der otto.de, nicht die gescheiterte Einführung von SAP ;-). Man ist scheinbar schon in der Champions League, wenn man im Jahre 2011 etwas entdeckt, dass Amazon seit ca. 2002 bzw. 2006 einsetzt. Oder ist man vielleicht doch ehr wie Christoph Kolumbus? Man entdeckt etwas, was viele andere schon lange vorher kannten und nutzten, lässt sich aber doch feiern… 😉

  11. Gina sagt:

    And I thought I was the sensible one. Thanks for setting me sthirgat.

  12. Tobias sagt:

    Zum Beitrag kann ich leider nicht viel Beitragen, möchte euch aber die Präsentation von Kevin Goldsmith (Spotify) über Microservices empfehlen. https://www.youtube.com/watch?v=7LGPeBgNFuU

  1. 3. Mai 2016

    […] welch breiten Raum das Thema Microservices auf der Konferenz einnahm. In seinem Artikel „Microservices & Einradfahren“ stellte er zunächst etwas verblüfft fest, dass es auch in der Welt der Techies so etwas […]