Three Lessons I Learned from the Microservices Hype

Monolith First

The first date was June 3, 2015, when Martin Fowler published the article “MonolithFirst”, advising to always start a new solution as a monolith, organize it into modules, and only split it into microservices when it becomes a problem. This reduces development cost, release time, and, in the end, results in a simpler solution since we don't need to deal with the challenges of distributed architecture.

Don´t start with a monolith

The second date came less than a week later, on June 9, 2015. Stefan Tilkov counter-argued in his article “Don’t start with a monolith” that it’s very hard to keep modules as isolated as a microservices architecture demands. When you start with microservices, you're naturally forced to develop well-decoupled services.

It all depends

The third date was around 2016–2017, when I received a project request for what was essentially a content blog—but the client wanted it developed with a microservices architecture.

Later, I consulted for an industrial company and evaluated the software architecture of a system that controlled ONE machine and had been built with 28 microservices.

I also saw solutions that could have easily been handled with a background worker and horizontal scaling, yet were turned into complex setups with 23 deployable services.

Three Lessons

Personally, I really like Amazon’s definition of microservices:

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate using well-defined APIs. These services are owned by small, self-sufficient teams.

Most of the time, when we developers discuss our field, we tend to focus only on the technical side. Honestly, it’s AMAZING to see a microservice architecture working perfectly. All those components communicating through requests, messaging, asynchronous processes... It's awesome! Let’s be real!

But did you catch a key point in Amazon’s definition? The adoption of microservices architecture doesn’t start with the technical aspect—it begins with the ORGANIZATIONAL structure of software development. A microservice is an INDEPENDENT software owned by ONE TEAM.

First: Conway’s Law

This leads to the first big lesson: Conway’s Law:

Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Interesting, right? We can even flip it:

Organizations that design systems are constrained to structure communications that mirror those system designs.

Either way, the bottom line is: your company’s organization and your software’s structure must be aligned so that communication, development, and strategy are built efficiently and appropriately.

Second: The Scale Cube

The second lesson relates to the main technical argument I hear for adopting microservices: software scalability. And I like to respond to that with the Scale Cube, which presents us with three ways to scale software:

X-Axis

Here we have horizontal replication. Is your system prepared for horizontal scaling? If I create new instances and place a load balancer in front, will it still work? What extra components need to be built for this to function? A great example of this is Stack Overflow: 1.3 billion page views per month with a horizontally scaled monolith.

Y-Axis
Here we have functional decomposition—macro/microservices. At this point, we start thinking not just about software scalability, but organizational scalability too. Implementation complexity increases, requiring both technical and organizational changes. You need a very clear understanding of teams, departments, and company processes for everything to work correctly.

Z-Axis
Here, we separate similar things, meaning the system runs with subsets of information. This solution is more common than we think. Companies that deploy their system per client, for example, scale this way.

The Scale Cube presents paths that can be used separately or combined to build a solid application scaling strategy. But whatever the strategy is—it starts with the business.

Third: Domain Driven Design

Third, but certainly not least, I’d like to talk about Domain Driven Design (DDD). The term was coined by Eric Evans in 2003.

I implemented my first system using DDD between late 2014 and early 2015. At that time, I structured the system with everything I thought was important: Entities, Repositories, Domain and Application Services…

It was a great experience, but it took me a while to understand that DDD isn’t so much about building software—it’s about understanding the business. The technical or tactical side is cool, but the strategic side is truly fascinating. How can understanding the business make such a difference in system development? And trust me—it DOES.

Today, for me, it doesn’t make sense to build systems far from the business. You can't define architectural requirements for software without understanding the business. I can't even write good code if I don’t understand the real problem it needs to solve.

DDD changed how I design systems. I started designing systems at a time when everything began with a database schema. We thought about data first, and only then tried to fit functionalities into it. Today I start with PROCESSES. Data is a consequence of processes. With well-designed processes, it's easier to define modules, microservices, architecture, and infrastructure. And DDD offers many tools to help with this, including the strategic part—domains and business processes.

Start Simple, Evolve with Complexity

Developing distributed systems or microservices increases complexity. When you have a huge organization and system, it makes sense to break down that complexity into small independent parts. This really speeds up the whole. But when you have a small or medium-sized system, it often doesn’t make sense to bring in that complexity. Always assess your organization’s size and the strategies that match your current moment.

Just thinking about distributed architecture brings to mind:

• What services will I need to build? I usually start with the identity service—but what comes next?

• What extra components, like distributed caching, will I need?

• What communication patterns will I use, and how will I handle idempotency and resilience? Not just how to horizontally scale EACH service—but how to guarantee their elasticity?

• Is the business ready for asynchronous processes? There’s no microservices without messaging.

• Is the business ready to give up constant data consistency? (CAP Theorem – Consistency, Availability, Partition Tolerance)

• How will we implement distributed transactions? (SAGA/SEC patterns)

• What tools will I need to monitor all this?

• …and so on.

I love watching debates between opposing sides. It's essential to follow people willing to discuss. I believe there are always different perspectives and to me, that’s strategic thinking. I learn a lot in these moments because I’m forced to think and form my own opinion. To view the problem from multiple angles, analyze, and give the good old response: “IT DEPENDS.”

So, what’s my opinion? Should you use microservices or not? I just answered, right? IT DEPENDS!

It’s important to analyze each case and assess if the solution fits the problem. Just because something works for Netflix, Uber, or Twitter doesn’t mean it will work for your business too. You are not them. The problems are different—and they require different solutions.