Bosch-Gruppe Österreich

Etablierte Firma

Alle Videos anzeigen

Why you shouldn't build a microservice architecture

Michael Eisenbart von Bosch stellt in seinem devjobs.at TechTalk die Vor- und Nachteile einer Microservice Architektur gegenüber – mit dem Hintergedanken, stets die Dinge etwas kritisch zu beleuchten.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Why you shouldn't build a microservice architecture zeigt Michael Eisenbart, dass Architektur vor allem Zeit sparen soll und Microservices als „schweres Gerät“ nur dann gerechtfertigt sind, wenn konkrete Vorteile die garantierte Zusatzkomplexität überwiegen—z. B. selektives Skalieren, mehrere Teams oder viele externe Schnittstellen. Mit einer Baumfäll-Analogie und Beispielen (oft reichen zwei Server plus Load Balancer) plädiert er dafür, nicht standardmäßig Microservices zu wählen, sondern schnell in Produktion zu gehen, Architekt:innen hands-on entwickeln zu lassen und Änderungen nicht zu scheuen. Ergebnis ist ein pragmatischer Entscheidungsprozess, um Microservices gezielt einzusetzen oder bewusst bei einer einfacheren Architektur zu bleiben.

Microservices sind kein Default: Wie „Why you shouldn't build a microservice architecture“ von Michael Eisenbart (Bosch-Gruppe Österreich) den Blick aufs Wesentliche schärft

Kontext: Was wir aus Linz mitgenommen haben

In seinem Talk „Why you shouldn't build a microservice architecture“ brachte Michael Eisenbart von der Bosch-Gruppe Österreich eine klare Botschaft auf die Bühne – und die ist weniger gegen Microservices gerichtet als gegen falsche Vorannahmen. Eisenbart arbeitet seit rund acht Jahren bei Bosch in der Softwareentwicklung, heute im „Accelerator“, der Digitalisierungsorganisation für das Powertrain-Geschäft. In dieser Rolle betreibt sein Bereich gemeinsam mit Partnern eine globale Infrastruktur, die mehr als 1000 Fertigungslinien weltweit und weitere Datenquellen in ein Big-Data-Ökosystem verbindet. Dafür werden sieben Softwareprodukte gebaut und betrieben – echte DevOps-Teams, die auch für den Betrieb verantwortlich sind. Rund 40 Entwicklerinnen und Entwickler in sieben Ländern liefern in diesem Setup, ein Team sitzt in Linz. Eisenbart verantwortet den Entwicklungsarm dieser Organisation.

Diese Rahmendaten sind nicht bloß Schmuck am Rande: Sie erklären, warum er mit Gewicht über Architekturentscheidungen sprechen kann – und warum ausgerechnet ein Microservices-Fan dazu rät, sie nicht leichtfertig einzusetzen. Seine starke These zieht: Microservices sind die „schwere Ausrüstung“. Wer nur einen kleinen Baum fällen will, braucht keinen Kranwagen.

Der Nordstern jeder Architektur: schneller von A nach B

Eisenbart reduziert Architektur auf ihren eigentlichen Zweck: Zeit sparen. CI/CD, Testing-Strategien, Deployment-Automatisierung, Versionskontrolle – am Ende dreht sich alles darum, schneller von A nach B zu kommen. Und zwar entweder unmittelbar oder mit einer klaren Beschleunigung in der Zukunft. Das ist der Prüfstein für jede architekturelle Entscheidung.

„Am Ende des Tages wollen wir von A nach B so schnell wie möglich kommen.“

Deshalb akzeptiert er durchaus, kurzfristig langsamer zu werden, wenn der langfristige Gewinn real ist. Aber: Dieser Gewinn muss irgendwann eintreten. Und Komplexität ist auf diesem Weg der natürliche Feind. Genau hier positioniert er Microservices: nicht als falsches Muster, sondern als riskante Standardantwort.

Das Baum-Metapher-Argument: Schwere Werkzeuge nur für schwere Aufgaben

Eisenbarts Bild ist eingängig: Ein kleiner Baum im Garten lässt sich mit der Kettensäge unkompliziert fällen. Doch mehrere große Bäume, dicht neben dem Nachbarhaus? Dann sind Hubarbeitsbühne, große Geräte, Logistik und Abstimmungen nötig – plötzlich frisst der Overhead den eigentlichen Job. Microservices sind diese schwere Ausrüstung. Sie sind grandios, wenn die Aufgabe groß, komplex und riskant ist. Sie sind übertrieben, wenn eine einfache Kettensäge reicht.

„Wenn du die großen Werkzeuge holst, hast du automatisch Overhead – Logistik, Timing, Koordination.“

Auf Software übertragen heißt das: Microservices erhöhen den Koordinations- und Betriebsaufwand, bevor eine Zeile Business-Value entsteht. Diese Anlaufkosten müssen durch echte Vorteile überkompensiert werden. Wenn nicht, verfehlt man das A-nach-B-Ziel.

Pro und Contra Microservices – auf das Wesentliche reduziert

Eisenbart verzichtet bewusst auf Vollständigkeit und konzentriert sich auf Kerneffekte.

Vorteile (wenn sie wirklich gebraucht werden)

Einfache Skalierung einzelner Komponenten: Wenn nur ein Teil stark wächst, lässt er sich isoliert skalieren.
Besseres Arbeiten mit mehreren Teams am gleichen Produkt: Klare Schnittstellen und Servicegrenzen können die Parallelisierung erleichtern.
Leichtere Argumentation und Austausch mit anderen Architekten bei vielen externen Schnittstellen: Die Servicestruktur macht Integration und Fehleranalyse nachvollziehbarer.

Nachteile (der eine große Nachteil: zusätzliche Komplexität)

Mehr bewegliche Teile: Mehr Deployments, mehr Monitoring, mehr Infrastruktur.
Teurer im Betrieb: Die Summe aus Services, Pipelines und Observability treibt Kosten und Aufwand.
Höhere Disziplinanforderungen: Architekturkonformität, Änderungsmanagement, Vermeidung doppelter Funktionalität.

„In der Literatur gibt es oft lange Pro-Listen und wenige Contras – aber eigentlich ist das eine Contra ‚zusätzliche Komplexität‘ allesentscheidend.“

Die Essenz: Komplexität ist garantiert. Deshalb dürfen Microservices nur dann die Antwort sein, wenn ihre Vorteile im konkreten Produkt tatsächlich schlagend werden.

Die Entscheidungsfragen: Wann greifen die Vorteile wirklich?

Eisenbart schlägt keine Patentlösung vor, sondern einen Fragenkatalog, der die großen Vorteile gegen die garantierte Komplexität abwägt.

1) Müssen wir überhaupt skalieren – und wenn ja, wirklich nur komponentenweise?

Für interne Anwendungen in ihrem Umfeld ist die Zahl gleichzeitig aktiver Nutzer begrenzt. Bosch hat viele Mitarbeitende weltweit, aber nie sind alle gleichzeitig online; typischerweise sind es einige Hundert bis wenige Tausend, nicht Millionen. Also: Warum dafür vorsorglich auf maximale Skalierbarkeit setzen?

„Wenn du skalieren musst, kannst du auch zwei Server und einen Load Balancer hinstellen – das funktioniert auch mit klassischen Architekturen.“

Wenn horizontale Gesamt-Skalierung genügt, braucht es oft keine Microservices. Nur wenn klar ist, dass einzelne Teile isoliert stark skalieren müssen, bringt der Vorteil wirklich etwas.

2) Brauchen wir wirklich mehrere Teams auf demselben Produkt?

Eisenbart priorisiert ein Team pro Produkt. Mehrere Teams erzeugen Koordinationsaufwand – das bremst. Die gewünschte Geschwindigkeit von A nach B leidet, wenn Meetings, Synchronisation und Schnittstellenabstimmung überhandnehmen.

„Ein Team ist im Idealfall am effizientesten. Mehrere Teams bedeuten Koordinations-Overhead.“

Wenn also ein Team genügt, relativiert sich der Microservices-Vorteil „Multi-Team-Fähigkeit“.

3) Müssen wir mit vielen externen Systemen sprechen – und dafür Architektur „erklärbar“ machen?

Wenn die Anwendung isoliert ist, wenig oder keine Integrationspunkte hat, sinkt der Bedarf, Architektur granular zu „begründen“. Dann fällt ein weiterer Microservices-Vorteil weg: die einfachere Kommunikation mit anderen Architekturen.

Ergebnis des Fragekatalogs

Treffen wenige oder keine Vorteile zu, ist Microservices als Default die falsche Wahl.
Treffen viele zu, lohnt das Weiterprüfen – denn die Komplexität kommt in jedem Fall, die Vorteile nur vielleicht. Die Frage ist nicht: „Sind Microservices gut?“ – sondern: „Zahlt ihr Vorteil in unserem konkreten Szenario die Komplexität zurück?“

Die ehrliche Fußnote: „Die meisten unserer Produkte laufen als Microservices“

Das macht Eisenbarts Position glaubwürdig. Er ist kein Microservices-Gegner, im Gegenteil. Die meisten seiner Produkte laufen in dieser Architekturform. Gerade deshalb rät er zur Vorsicht: Wer schwere Ausrüstung wählt, soll sie wegen der Aufgabe wählen, nicht aus Gewohnheit. Oder in seinen Worten: Hol die großen Werkzeuge nur, wenn du wirklich den großen Baum fällen musst.

Betrieb schlägt Plan: Es gibt keine richtige Architektur – nur „verschiedene Grade von falsch“

Der vielleicht wichtigste Teil des Talks kommt zum Schluss. Du kannst lesen, reden, modellieren – und dann wird der erste Produktions-Rollout trotzdem chaotisch. Das passiert. Entscheidender ist die Haltung danach.

„Es gibt keine korrekte Architektur. Es gibt nur verschiedene Grade von falsch.“

Daraus leitet er klare Handlungsprinzipien ab:

Geh schnell in Produktion: Sechs Monate nur Architektur zu malen, ist verlorene Zeit auf dem Weg von A nach B.
Architekten müssen implementieren: Nur im Code und im Betrieb lernst du, wie deine Architektur sich verhält.
Verliebe dich nicht in deine Architektur: Sei bereit, sie zu ändern. Perfekt wird sie nie.

Diese Grundsätze bilden den Gegenpol zum Microservices-Hype. Nicht das „richtige“ Pattern entscheidet, sondern die Fähigkeit, schnell zu lernen, zu liefern und anzupassen.

Anwendung in der Praxis: Ein Minimal-Framework für Architekturentscheidungen

Was lässt sich aus dem Talk unmittelbar umsetzen? Ohne neue Methoden zu erfinden, bleiben wir bewusst bei Eisenbarts Common-Sense-Linie.

Schritt 1: Formuliere das A-nach-B-Ziel

Was ist das kleinste Feature, das echten Nutzwert stiftet?
Wie bringen wir es schnell in Produktion, um Feedback zu bekommen?

Die Architektur hat dieser Lieferfähigkeit zu dienen, nicht umgekehrt.

Schritt 2: Prüfe die drei Fragen ehrlich

Skalierung: Handelt es sich um hunderte/tausende gleichzeitige Nutzer statt Millionen? Reicht horizontale Gesamtskalierung?
Teams: Können wir mit einem Team liefern? Wenn nein, ist der Mehrwert der Entkopplung größer als der Synchronisationsaufwand?
Schnittstellen: Wie viele Integrationen bestimmen die Architekturkommunikation? Ist Erklärbarkeit hier wirklich ein Engpass?

Wenn zwei von drei Antworten „nein“ oder „nicht relevant“ sind, ist ein einfacheres Architekturmodell meist der bessere Start.

Schritt 3: Komplexitätsbudget definieren

Jedes zusätzliche bewegliche Teil (Service, Pipeline, Monitoring-Target) muss begründet werden.
Führe bewusst eine „Komplexitätsliste“: Was macht Betrieb, Deployment, Troubleshooting schwerer? Warum ist es dennoch nötig?

Schritt 4: Umsetzung mit Betrieb im Blick

Monitoring- und Deployment-Pfade müssen existieren, bevor die erste Komplexität ausgeliefert wird.
Änderungen am Architekturzuschnitt sind erlaubt – sogar erwartet –, sobald Produktionserfahrungen neue Fakten schaffen.

Schritt 5: Feedback-Schleifen erzwingen

Architekten implementieren mit: Nur so entstehen kurze Lernzyklen.
Release früh, release oft: Stabilität ist wichtig, aber Lernen ist ohne reale Nutzung nicht möglich.

Lessons Learned: Zitate und Kernaussagen, die haften bleiben

„Microservice-Architektur holt die schweren Werkzeuge – das macht nur Sinn, wenn die Aufgaben groß genug sind.“

„Komplexität ist garantiert; die Vorteile nicht.“

„Wenn du sechs Monate nur an Architektur arbeitest, hast du diese sechs Monate verloren.“

„Es gibt keine korrekte Architektur – nur verschiedene Grade von falsch.“

Diese Sätze sind keine Theorien, sondern praktische Leitplanken für Teams, die reale Systeme bauen und betreiben.

Was das für interne Produkte bedeutet

Eisenbart sprach explizit über viele interne Anwendungen. Sein Punkt: Selbst in einem globalen Konzern mit vielen Mitarbeitenden ist die gleichzeitige Nutzung typischerweise begrenzt – einige Hundert bis wenige Tausend gleichzeitig. Für diese Größenordnung braucht es oft keine feingranulare, komponentenweise Skalierung. Ein klassischer Ansatz mit zwei Servern und Load Balancer kann völlig genügen. Wenn Microservices nur deshalb im Spiel sind, weil sie „Future-Proofing“ versprechen, fährt man die Komplexitätskosten ohne messbaren Gegenwert ein.

Doppelte Funktionalität und Disziplin: Warum Microservices teuer werden können

Ein praktischer Nebeneffekt der zusätzlichen Komplexität sind Dopplungen. In verteilten Services kann dieselbe Funktion leicht zweimal entstehen – in leicht unterschiedlicher Ausprägung. Das verschlechtert Wartbarkeit und Konsistenz und erhöht den Bedarf an Governance und Disziplin. Diese Disziplin ist kein Selbstzweck; sie kostet Zeit – also genau das, was die Architektur eigentlich sparen sollte. Auch deshalb plädiert Eisenbart dafür, die Vorteile knallhart zu validieren.

Troubleshooting und Kommunikation: Wo Microservices helfen – und wo nicht

Bei vielen Schnittstellen zu anderen Produkten schaffen klar geschnittene Services Transparenz. Es wird einfacher, mit anderen Architektinnen und Architekten zu sprechen: Was geht wohin? Welche Verantwortung liegt wo? Für das Troubleshooting ist die klare Service-Zuordnung ein Gewinn. Doch wenn das Produkt weitgehend insulär ist, ist dieser Gewinn gering. Dann schlägt die Komplexität des Service-Zoos den Nutzen.

Der ehrliche Umgang mit Fehlschlägen beim Go-Live

Eisenbart zeigt ein Bild vom misslungenen Produktionsdeploy – und macht damit Mut. Auch mit guter Vorbereitung wird etwas schiefgehen. Entscheidend ist, das als Lehrmoment zu akzeptieren. Wer sechs Monate Architektur perfektioniert, hat weder Risiken eliminiert noch schneller geliefert. Wer früh liefert, lernt früher – und verschiebt die Energie vom Diskutieren zum Verbessern.

Ein pragmatisches Bekenntnis zur Realität

Aus DevJobs.at-Sicht liegt die Stärke dieses Talks im Pragmatismus. Keine Pattern-Verliebtheit, kein Dogma – stattdessen Common Sense:

Definiere den Nutzen in Zeit: Bringt uns das schneller von A nach B?
Behandle Komplexität als Kostenstelle.
Wähle Microservices nicht, weil sie modern sind, sondern wenn sie konkret nützen.
Liefere in Produktion, lerne, korrigiere den Kurs.

Das ist kein Rückschritt, sondern gelebte Professionalität.

Konkrete Takeaways für Engineering-Teams

Beginnt mit der einfachsten Architektur, die liefert. Erweitert nur, wenn die Vorteile spürbar werden.
Prüft Eisenbarts drei Fragen bei jeder Erweiterung erneut: Skalierung, Teams, Schnittstellen.
Dokumentiert Komplexität als bewusste Entscheidung – mit klarer Erwartung an den Gegenwert.
Misst Erfolg in Durchlaufzeit, nicht in Architektursauberkeit.
Haltet Architektinnen und Architekten im Code: Umsetzung ist Teil der Architekturarbeit.

Session-Referenz

Title: Why you shouldn't build a microservice architecture
Speaker: Michael Eisenbart
Company: Bosch-Gruppe Österreich

Fazit: Microservices sind ein Werkzeug, kein Ziel

Michael Eisenbart ist kein Microservices-Gegner – er baut die meisten seiner Produkte genau so. Doch sein Talk erinnert daran, dass Microservices die schweren Werkzeuge sind. Sie sind großartig, wenn sie gebraucht werden. Sie sind hinderlich, wenn sie nur aus Gewohnheit geholt werden. Wer Komplexität als garantiertes Gegenstück jedes Microservices-Entwurfs begreift und die Vorteile im eigenen Kontext hart prüft, macht aus Architektur wieder das, was sie sein soll: ein Hebel, um schneller von A nach B zu kommen. Und wer früh liefert, zulässt, dass Go-Lives auch mal schiefgehen, und die Architektur nicht idolisiert, wird langfristig die robusteren Systeme bauen – unabhängig vom Pattern.

Weitere Tech Lead Stories

Weitere Dev Stories