Bosch-Gruppe Österreich

Established Company

Show all Videos

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In Why you shouldn't build a microservice architecture, Michael Eisenbart argues that architecture’s job is to save time and that microservices are “heavy equipment” whose guaranteed extra complexity must be justified by concrete needs—such as selective scaling, multi-team development, or numerous external interfaces. Using a tree-felling analogy and cases where two servers plus a load balancer suffice, he cautions against defaulting to microservices, urges teams to ship early, keep architects hands-on, and be ready to change course. Viewers gain a pragmatic decision process to choose microservices deliberately or stick with a simpler design to get from A to B faster.

Stop Defaulting to Microservices: Hard‑Won Lessons from “Why you shouldn't build a microservice architecture” by Michael Eisenbart (Bosch‑Gruppe Österreich)

Context: Why this perspective matters

In “Why you shouldn't build a microservice architecture,” Michael Eisenbart of Bosch‑Gruppe Österreich delivers a message that is less anti‑microservices and more anti‑assumption. Eisenbart has spent about eight years at Bosch in software development. He currently works in the Accelerator, the digitalization organization for Bosch’s powertrain business. In that capacity, his group runs a global infrastructure with partners, connecting more than 1000 manufacturing lines worldwide and many other data sources into a big data ecosystem. They build and run seven software products with DevOps teams that own operations end to end. Forty developers across seven countries contribute to this setup, including a team in Linz. Eisenbart is responsible for the development arm of that organization.

That context isn’t just pedigree. It explains why he speaks with authority about architecture decisions—and why a self‑declared fan of microservices argues you shouldn’t build a microservice architecture by default. His point lands crisply: microservices are the heavy machinery; reach for them when the job is truly big.

The north star: Get from A to B faster

Eisenbart distills architecture down to its real job: saving time. CI/CD, testing strategies, deployment automation, version control—at the end of the day, they serve one purpose: get from A to B as fast as possible. That is the yardstick for every architectural choice.

“At the end of the day, we want to get from A to B as fast as possible.”

He’s fine with short‑term slowdowns if they buy real long‑term speed. But that payoff must materialize at some point. And complexity is the enemy of speed. This is where microservices sit: not as a bad pattern, but as a risky default pick.

The tree‑felling metaphor: Heavy tools only when the trees are big

His metaphor is memorable. A small tree in your yard? A chainsaw and a sunny afternoon get it done. But multiple large trees right next to the neighbor’s house are a different story. Suddenly you need a lift, special equipment, logistics, and coordination with neighbors. Overhead dominates the job. Microservices are that heavy equipment. They shine when the task is large and risky. They’re overkill when a simple chainsaw suffices.

“When you bring in the heavy equipment, you get overhead—logistics, timing, coordination—before you even start cutting.”

Translated to software: microservices add coordination and operational overhead before any business value ships. Those startup costs must be more than offset by concrete advantages. If not, you’ve missed the A‑to‑B goal.

Microservices, in essentials: Pros and the one con that matters

Eisenbart intentionally keeps the list focused.

Pros (when they truly apply)

Easier scaling, especially of individual components that need it most.
Better for multiple teams working on the same product: clear interfaces and boundaries can help parallel work.
Easier to reason about architecture in conversations with other teams when there are many external interfaces; helps with troubleshooting later.

The con that dominates: additional complexity

More moving parts: more deployments, more monitoring, more infrastructure.
More expensive to run: the sum total of services, pipelines, and observability increases cost and effort.
More discipline required: keeping architecture boundaries honest, managing changes, and avoiding duplicate functionality implemented differently in different services.

“Literature often lists many pros and few cons—but the one con, ‘additional complexity,’ is decisive.”

The essence: complexity is guaranteed; the benefits are not. Microservices should win only when their benefits clearly apply to your software.

The decision checklist: Do the benefits apply here?

Eisenbart doesn’t argue for or against patterns in the abstract. He offers practical questions that test whether the benefits are real in your context.

1) Do we truly need to scale—and specifically per component?

In their internal applications, concurrent usage is bounded. Bosch has many employees, but only about a third are online at any given time; not everyone will use the app. That means a few hundred to a few thousand concurrent users—not millions.

“If you need to scale, you can also deploy two servers and a load balancer—works fine with classical architectures.”

If whole‑system horizontal scaling suffices, microservices may be unnecessary. Only when you know selective scaling is critical does that microservices advantage pay off.

2) Do we actually need multiple teams on the same product?

Eisenbart aims for one team per product. Multiple teams introduce coordination overhead—and slow the A‑to‑B progress.

“Ideally, one team is most efficient; multiple teams add coordination overhead.”

If a single team can build it, the multi‑team advantage of microservices likely doesn’t apply.

3) Do we need to reason about architecture with many external systems?

If your application is insular—few or no interfaces—the need to make architecture “explainable” is smaller. That erodes another claimed advantage of microservices.

The simple outcome

If none (or few) benefits apply, don’t choose microservices.
If most apply, keep asking and dig into the full list of benefits. Complexity is certain; the benefits are hypothetical until proven in your context. The tool must fit the tree you’re cutting.

The candid twist: “Most of our products run as microservices”

This makes Eisenbart’s caution compelling. He’s not a microservices skeptic; he runs most products on microservices. Precisely for that reason, he’s careful to apply them only when the job calls for heavy equipment. Defaulting to microservices is the mistake; choosing them deliberately is the craft.

Production reality: There is no correct architecture—only degrees of wrong

A great slide in his talk shows a disastrous production deployment. That, he says, will happen—and there’s nothing you can do to fully prevent it. The conclusion is not cynicism but urgency.

“There is no such thing as a correct architecture. There are only different degrees of wrong.”

From that, he draws practical rules:

Get to production fast: Spend six months crafting architecture on paper, and you’ve already lost those six months on the A‑to‑B timeline.
Architects must implement: Only in code and operations do you learn how your architecture actually behaves.
Don’t fall in love with your architecture: Be ready to change it later; it’ll never be perfect.

This mindset counters microservices hype with grounded engineering: shipping beats theorizing.

Applying the talk: A minimal framework for decisions

Without inventing new methods, we can translate Eisenbart’s common‑sense approach into a simple, repeatable practice.

Step 1: Start from the A‑to‑B objective

What is the smallest valuable feature we can ship?
How do we get it into production quickly to start learning?

Architecture serves delivery, not the other way around.

Step 2: Ask the three questions honestly

Scaling: Are we dealing with hundreds/thousands of concurrent users rather than millions? Does whole‑system scaling suffice?
Teams: Can one team deliver? If multiple teams are needed, will decoupling benefits outweigh synchronization overhead?
Interfaces: Do we have many external integrations such that architectural explainability is a real bottleneck?

If two out of three answers are “no” or “not relevant,” a simpler architecture is usually the better start.

Step 3: Define a complexity budget

Every additional moving part (service, pipeline, monitoring target) should be explicitly justified.
Maintain a “complexity list”: What makes operations, deployments, and troubleshooting harder? Why is it still necessary?

Step 4: Build with operations in mind

Have monitoring and deployment paths before introducing additional complexity.
Architectural boundaries are allowed—expected—to shift once production teaches you new facts.

Step 5: Force feedback loops

Keep architects in the code: implementation is part of the architecture job.
Release early, release often: stability matters, but real learning only happens in production.

Lessons that stick: Quotes and paraphrases

“Microservices are the heavy tools—only bring them when the trees are big.”

“Complexity is guaranteed; the benefits are not.”

“If you spend six months just on architecture, you’ve already lost those six months.”

“There is no correct architecture—only different degrees of wrong.”

These aren’t slogans; they’re practical guardrails for teams that both build and run software.

What this means for internal products

Eisenbart explicitly references internal applications. Even in a global company, concurrent usage tends to be bounded—hundreds to a few thousand users at a time. That rarely requires fine‑grained, per‑component scaling. A couple of servers and a load balancer can be perfectly adequate. If microservices are chosen mainly for “future proofing,” you’re likely paying complexity tax without tangible return.

Duplicate functionality and discipline: The hidden costs

Additional complexity invites duplication. In a distributed system, the same function can be implemented twice—in different ways across services. That hurts maintainability and consistency and raises the need for governance and discipline. Governance and discipline consume time, which is exactly what architecture is supposed to save. This is why Eisenbart insists on validating the benefits rigorously.

Troubleshooting and communication: Where microservices help—and where they don’t

When your product integrates with many external systems, clearly scoped services make it easier to discuss and troubleshoot: what goes where, who owns what. But if the product is largely insular, that benefit is small, and the overhead of a service zoo outweighs it.

The honest stance on messy go‑lives

Eisenbart shows a picture of a botched production rollout—and normalizes it. Things will go wrong. The response that matters is learning, not prolonged planning. Spending six months designing does not eliminate risk; it merely delays feedback. Shipping early shifts energy from debating to improving.

A pragmatic return to reality

From a DevJobs.at editorial vantage point, the strength of this talk is its pragmatism. No pattern worship, no dogma—just common sense:

Measure choices by time saved: does this get us from A to B faster?
Treat complexity as a cost center.
Choose microservices for concrete, present reasons—not because they’re modern.
Ship to production, learn, and adjust.

That is not conservative—it’s professional engineering.

Concrete takeaways for engineering teams

Start with the simplest architecture that ships. Add complexity only when its benefits are visible.
Re‑run Eisenbart’s three questions every time you consider adding services: scaling, teams, interfaces.
Document complexity as a conscious trade‑off—with a clear expectation of the payback.
Measure success in lead time, not architectural purity.

Session reference

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

Conclusion: Microservices are a tool, not a goal

Michael Eisenbart isn’t against microservices—most of his products use them. His talk reminds us that they are the heavy tools. They’re fantastic when warranted, harmful when chosen by habit. If you treat complexity as the guaranteed cost of a microservices design and test the benefits against your real context, architecture becomes what it should be: a lever to get from A to B faster. Ship early, accept that go‑lives can be messy, and don’t fall in love with your diagrams. That’s how resilient systems get built—pattern second, purpose first.

More Tech Lead Stories

More Dev Stories