Microservices vs Monoliths Part 1: Understanding the Hype and Hidden Motivations

The debate between microservices and monoliths has raged for years in software development circles. Yet many teams still make this key architectural choice based on industry trends rather than a thoughtful assessment of their specific needs.

A big danger is treating architecture selection as a purely technical decision.

It’s not. It’s fundamentally a business decision with technical implications.

Further, discussions about the microservices are often laden with appeals to authority - “Amazon and Netflix do it, and they are successful,” goes the reasoning, and by extension, “and if we do to, so we will we.” Perhaps even more appealing is the logic of the downside: “if we do not do it,” many reasons, “we will be at a technological disadvantage.”

This is the first post in a five-part series examining how to make intelligent decisions about microservices versus monolith architecture. Throughout this series, we’ll explore business drivers, technical considerations, organizational readiness, and practical implementation strategies.

How to Think About and Discuss Microservices

Companies have vastly different circumstances, and this effects software architecture in very fundamental ways - more fundamental, in fact, than many people realize.

First, think of the fundamental nature of that company. Many companies who are known for microservices are tech companies at their core - while Uber and Netflix may not sell software directly, they are considered tech companies, and are considered a prestige employer for technological specialists.

This isn’t a bad thing, of course, and it’s not unreasonable to think that such companies do, indeed, have enough skill to make excellent choices. However, do not forget the flipside of this: their very skill and prestige makes imitating them a potentially useful move. If you can’t have Netflix on your resume, you can, at the very least, get your new project at your current project to use Netflix-style tooling.

This logic is understandable - but remember, just because an architectural decision makes your CTO or other technological decision makers happy does not mean it is correct for your company. It may, indeed, be the best move for that individual’s career - but is it the best move for your company?

Similarly, individuals familiar with microservices may be inclined to choose a microservice oriented architecture simply because they are familar with the tools involved. Others may be more comfortable with monolith architecture and may prefer to stay with architectures they are comfortable. This is not a trivial concern, per se - by definition, teams are skilled at what they are skilled at and are therefore most productive when using familiar tools and architecture, and it can be expensive to change.

These factors should all be considered when discussing microservices architecture. Are your decisionmakers suggesting microservices becaues its the best for your company or because its best for their ego and/or future career prospects? Conversely, are they promoting traditional development practices because thats what they know and are comfortable with?

The Real Questions to Ask

When evaluating architectural proposals, executives and technical leaders should ask:

• What specific business problems does this architecture solve for us?
• Are we choosing this because it’s best for the company or best for individual career advancement?
• Do we have the organizational maturity and skills to execute this successfully?
• What are we optimizing for - resume building or business outcomes?

Understanding these motivations doesn’t mean dismissing technical expertise. Rather, it means ensuring that expertise serves business goals rather than personal ambitions.

Size, Conway’s Law, and Organizational Structure

Size itself is also a significant factor.

Consider Conway’s law, a rather fascinating observation from a 1967 paper:

The choice between microservices and monoliths comes down to trading one set of problems for another. Monoliths offer simplicity in development and deployment but can become unwieldy as they grow. Microservices provide better isolation and scaling options but introduce significant complexity in operations and service coordination.

The shape of your software often mirrors the shape of your organization. Small teams with broad responsibilities often work more effectively with monoliths, while larger organizations with specialized teams may benefit from the bounded contexts that microservices enforce.

A Reality Check: The E-Commerce Case Study

Consider, for a moment, a medium-sized e-commerce company. While they have consistently updated their frontend technology, the core of their business processing has remained largely unchanged for over a decade. Their engineering team, eager to adopt microservices, cited scalability concerns. However, a closer examination revealed that their actual business challenges were not about Facebook-scale transaction volume, but rather about feature delivery speed and a codebase that had grown messy and difficult to change. In such a scenario, switching to microservices would introduce significant operational complexity without addressing the root cause.

It may be that such a business would be better to refactor instead; gradually rebuild their existing monolith into cleaner modules with better boundaries. Some of these modules could be written using a microservices architecture if thats appropriate. This approach addressed their real business need—faster feature delivery—without introducing the operational complexity of distributed systems.

Coming Up in This Series

In the next posts, we’ll dive deeper into:

• Part 2: Business drivers that should guide architectural decisions
• Part 3: Technical considerations that actually matter
• Part 4: A practical decision framework for choosing your architecture
• Part 5: Common pitfalls and how to avoid them

The key is to approach these decisions with clear eyes about motivations, constraints, and actual business needs rather than getting caught up in architectural trends.