The Microservices vs Monolith Debate Is Really About Control, Not Technology

[vp_eng_keisha]

After a decade of watching this debate play out across multiple organizations, I’ve come to a conclusion that I rarely see articulated: the microservices vs monolith debate is fundamentally about control, not technology.

The pattern I keep seeing:

When I dig into why a team chose microservices, the stated reasons are usually technical: independent scaling, fault isolation, polyglot flexibility. But when I dig deeper, the actual driver is almost always organizational:

• “We couldn’t get the platform team to prioritize our changes”
• “The other team kept breaking our code”
• “We wanted to deploy without waiting for the release train”

These are control problems, not technology problems. Microservices are a mechanism for redistributing control away from central architecture groups toward product-aligned teams.

Conway’s Law as political archaeology:

Melvin Conway’s observation from 1967 is more relevant than ever: organizations produce systems that mirror their communication structures. But there’s a dimension that often gets missed.

Someone once told me: “You can read the history of an enterprise’s political struggles in its system architecture.” I’ve found this to be painfully accurate.

That one service that has 47 microservices while every other domain has 3? There was a power struggle there. The module that’s inexplicably isolated with its own database? Someone was protecting territory. The API gateway that routes everything through one team? Someone consolidated control.

The Inverse Conway Maneuver:

ThoughtWorks popularized the idea of intentionally designing your organization to achieve your desired architecture. Split teams into small, autonomous units with clear ownership first, and the architecture will follow.

This is powerful, but it has a shadow side: you’re not just reorganizing code. You’re reorganizing power. Who gets to make decisions? Who owns what? Who has to ask permission from whom?

When you move from a monolith to microservices, you’re telling central architecture: “You no longer control how we deploy, what languages we use, or how we structure our data.” That’s a political act.

Why the debate never dies:

The microservices vs monolith debate survives because it’s a proxy war for a deeper question: How much autonomy should teams have?

• Microservices advocates are often saying: “Trust the teams. Let them own their destiny.”
• Monolith advocates are often saying: “We need coherence. Someone has to see the whole picture.”

Both positions are valid. Neither is purely technical.

What I’ve learned:

1. Be honest about the real driver. If you’re choosing microservices because you want team autonomy, say that. Don’t hide behind “independent scaling” if that’s not the actual bottleneck.

2. Architecture won’t solve org problems. If teams can’t collaborate on a monolith, they won’t magically collaborate across service boundaries either. You’ve just made the coordination more explicit.

3. The modular monolith is a political compromise, not just a technical one. It says: “We’ll share a deployment, but respect each other’s boundaries.” That requires trust and norms, which are organizational investments.

What’s been your experience? Have you seen architecture decisions that were really about control?

[product_david]

Keisha, this framing resonates deeply from the product side.

The product-engineering boundary is where control fights play out:

I’ve been in countless architecture discussions where the stated goal was technical purity, but the actual goal was control over roadmap priorities.

When a team extracts their feature into a microservice, they’re often saying: “We want to own our backlog. We don’t want to wait for the platform team to prioritize our work. We want to decide when we ship.”

That’s a product management statement dressed up as an architecture decision.

The flip side is equally political:

When central architecture resists extraction, they’re often saying: “We need to see dependencies. We need to manage shared resources. We need consistency across the platform.”

That’s also a control statement. It’s about visibility and coordination authority.

Where I’ve seen this go wrong:

The worst outcomes happen when the control dynamics aren’t acknowledged. Two patterns I’ve observed:

1. Phantom autonomy - Teams extract services thinking they’ll move faster, but then discover they’re still dependent on platform team APIs, shared databases, and release coordination. They got the complexity of microservices without the autonomy they wanted.

2. Shadow monolith - Teams technically have microservices, but one team’s service is so central that everyone depends on it. Control didn’t get distributed - it just moved to whoever owns the core service.

The honest conversation:

Before any architecture migration, I now push for a conversation that goes: “What decisions do you want to be able to make without asking anyone else?”

If the answer is “deploy timing,” maybe you just need better CI/CD, not microservices. If the answer is “technology choices,” that might justify extraction. If the answer is “roadmap priorities,” that’s an org design conversation, not an architecture conversation.

The technology should follow the governance model you want, not the other way around.

[cto_michelle]

I want to push back slightly on this framing - not because it’s wrong, but because it can be used to dismiss legitimate technical concerns.

Yes, control matters. But so does technical reality:

I’ve been in the room when architecture decisions were 100% political. I’ve also been in the room when they were genuinely driven by scaling requirements, regulatory mandates, or technical constraints.

The danger of the “it’s all about control” frame is that it can become a thought-terminating cliché. Someone proposes microservices for a genuinely good technical reason, and the response is: “You just want control.” That’s not fair either.

The questions I ask to separate politics from engineering:

1. Is there a measurable technical problem? “We can’t scale the payment service independently” is measurable. “We want more autonomy” is a preference.

2. Would fixing the process solve the problem? Sometimes “we can’t deploy fast enough” is a CI/CD problem, not an architecture problem. Sometimes it’s genuinely that deployments are coupled in ways that require service extraction.

3. What’s the counterfactual cost? If we don’t do microservices, what breaks? If the answer is “nothing technical, just people are frustrated,” that’s still a valid reason - but name it honestly.

Where I fully agree:

The modular monolith as political compromise point is exactly right. When I’ve seen it work, it’s because leadership explicitly said: “We’re going to share infrastructure, but we’re also going to respect boundaries. Here are the norms. Here are the consequences for violating them.”

That’s a governance statement, not a technology statement.

The meta-point:

Architecture is always downstream of something - sometimes technology constraints, sometimes organizational structure, sometimes market dynamics, sometimes executive ego.

The skill is reading what’s actually driving the decision, acknowledging it, and then making the choice that serves the real need - even if the real need is political.

[eng_director_luis]

This thread is naming something I’ve struggled to articulate for years. Let me add the middle management perspective.

The director-level squeeze:

As a Director of Engineering, I sit between the teams who want autonomy and the executives who want coherence. Both sides use architecture language to advocate for their position, and I’m supposed to somehow adjudicate.

Team lead: “We need to extract our service so we can deploy independently.”
VP: “We need architectural consistency so we can maintain security standards.”

Both are saying things that sound technical. Both are really saying “I want control over X.”

The Inverse Conway trap:

Keisha mentioned the Inverse Conway Maneuver - designing your org to get your desired architecture. Here’s the trap I’ve seen:

We reorganize teams to be “product-aligned.” We tell them they own their domain end-to-end. They naturally start wanting their own services, databases, technology choices.

Then leadership says: “Wait, we didn’t mean that much autonomy. We still need standardization.”

You’ve set up an organizational structure that creates pressure for microservices, but you don’t actually want microservices. The result is constant friction.

What works:

The healthiest architectures I’ve seen come from leadership that’s clear and consistent about the control model:

1. “Here’s what you own completely. Here’s what’s centrally controlled. Here’s how we handle the gray areas.”

2. The control boundaries match the architecture boundaries. If a team owns a service, they actually own it. If something is centrally controlled, it’s actually a shared module, not a nominally-independent service that has to go through central review anyway.

3. When control needs change, the architecture changes with it. When we acquired a company and needed to isolate their data for regulatory reasons, we extracted services. That was a control change that required an architecture change.

The honest framing:

I’ve started asking in architecture reviews: “Who gains decision-making authority if we do this? Who loses it?”

It cuts through a lot of the technical rationalization. And it’s not a gotcha - sometimes the answer is “Team X gains authority, and that’s appropriate because they have the context.” But naming it makes the conversation honest.