Microservices architecture has become a buzzword in the tech industry, promising unparalleled agility, scalability, and resilience. Yet, according to Gartner, more than 90% of organizations attempting to adopt microservices will fail. How can you ensure you’re part of the successful 10%?

This article is based on a webinar I gave last month. You can watch the webinar below or read on.

Six Secrets to Success with Microservices

If you’ve spent any time in software architecture, you’ve probably heard about microservices. They’re everywhere. But after years of consulting, I’ve realized something surprising:

Nobody really wants microservices.

Sounds counterintuitive, right? But let’s unpack this idea. Organizations don’t actually want microservices. They want organizational agility, a reasonable release frequency, confidence in deployments, enforced modularity, efficient compute utilization, and an architecture they won’t be ashamed of.

So why do microservices dominate the conversation?

The Illusion of Five-Star Architecture

One of my favorite books on software architecture is Fundamentals of Software Architecture by Mark Richards and Neal Ford. In it, they give star ratings to different architectural styles. Microservices score five stars almost across the board—agility, scalability, fault tolerance, evolvability, elasticity. It’s easy to see why organizations gravitate toward them.

But what does “five stars” really mean?

Think about restaurant ratings. A high-end steakhouse in Colorado might have 4.5 stars. A McDonald’s in the same area might have 4.2. Does that mean a Big Mac is comparable to fine dining? Of course not. The ratings don’t exist on a universal scale.

Similarly, when we say microservices have five-star scalability, we’re talking about Amazon-scale scalability—where Amazon averages 136,000 deployments per day and handles 50 million HTTP requests per second during peak times.

Meanwhile, Shopify—a monolith—only scores two-star agility and deployability in this model. But they still manage 40 deployments per day and handle 1.3 million requests per second on a massive Rails monolith.

So the takeaway here is:

Star ratings don’t tell the whole story. The real question is: What do you actually need?

Secret #1: Nobody Really Wants Microservices

Microservices are a means to an end, not the goal itself. Companies want business agility, scalability, and reliability. The real architectural challenge isn’t about following trends—it’s about delivering what the business actually needs in a way that fits the organization’s size, maturity, and constraints.

Secret #2: There Is No Single Definition of Microservices

And that’s how disaster starts.

Ask ten teams to define microservices, and you’ll get ten different answers. This is because we don’t have a single definition—just a loosely defined category of architectures.

Martin Fowler once wrote:

“While there is no precise definition of this architectural style, there are certain common characteristics around organization, business capability, automated deployment, intelligent endpoints, and decentralized data management.”

This ambiguity leads to misaligned expectations and chaos when teams, believing they’re all on the same page, charge forward in different directions.

Instead of looking at “monolith vs. microservices” as binary, we should recognize that:

Architecture is about decisions, not patterns.

Each pattern is just a side effect of a handful of key architectural decisions. What matters isn’t topology; it’s how we structure constraints to induce the qualities we want.

Secret #3: Microservices Trade Simplicity for Extreme Complexity

Microservices aren’t magic. They trade extreme cost and complexity for extreme agility and scalability. That’s why Gartner predicted in 2017 that:

“By 2019, 90% of organizations attempting microservices will fail.”

Why? Because they ignored the X-factors—the hidden variables that make microservices possible.

Successful microservices require:

• Domain-driven design (DDD)
• Organizational alignment with Conway’s Law
• Continuous integration and delivery (CI/CD)
• Mature development practices
• DevOps-first mindset
• Operational automation
• Truly independent teams

If you don’t have these, you’re not getting microservices—you’re getting a distributed monolith, with all the complexity and none of the benefits.

Secret #4: Decomposing a Monolith Isn’t Always Hard

If you’ve been in tech long enough, you’ve seen this:

“We’re five years into our microservices migration.”

But here’s the reality: Decomposing a monolith isn’t necessarily difficult.

What’s difficult is changing module boundaries. If your monolith has well-defined boundaries, decomposition can be straightforward. A modular monolith—like Shopify’s—adopts key microservice constraints without the complexity of full distribution.

Going from a monolith to a distributed system is easy. Changing domain boundaries is hard.

That’s why the smartest way forward is often a monolith-first approach, making gradual, controlled moves toward distribution rather than jumping in blindly.

Secret #5: Granularity Doesn’t Have to Be Absolute

Engineers love purity. But the goal isn’t purity—it’s fit.

Microservices are often defined as:

“A single-purpose, independently deployable unit of code that does one thing well.”

But that doesn’t mean every project should chase fine-grained services at all costs. Sometimes coarser-grained components make more sense.

If breaking a service apart introduces unnecessary complexity, don’t do it. Balance cost, complexity, and scale—don’t just optimize for dogma.

Secret #6: A Monolith-First Approach Is Often Practical

Many teams avoid monoliths because they fear architectural decay—the slow drift into a tangled mess. But decay isn’t inevitable if you have governance and enforcement in place.

Tools like:

• Sonargraph
• ArchUnit (.NET/Java)
• Modular monolith validation frameworks

can ensure you maintain strict module boundaries. If you enforce modularity within a monolith, the eventual transition to microservices will be painless.

Build what you need now. Make sure it can evolve later.

Final Thoughts: The Right Approach for Your Organization

So what’s the takeaway from all of this?

1. Nobody wants microservices—they want what microservices promise.
2. There’s no single definition of microservices, so don’t get caught up in labels.
3. Microservices trade simplicity for extreme complexity—make sure the tradeoff is worth it.
4. Decomposing a monolith isn’t always hard—breaking module boundaries is.
5. Granularity isn’t absolute—use what makes sense.
6. Monolith-first is often the most practical approach.

Over-engineering isn’t a substitute for good architecture. Instead of chasing trends, focus on delivering what the business truly needs with an architecture that fits.

And as always, feel free to connect with me on LinkedIn to keep the conversation going. Thanks for reading, and happy architecting!