Microservices guru warns devs that trendy architecture shouldn't be the default for every app, but 'a last resort'

Old-style monolithic but modular software is 'highly underrated'

QCon London Sam Newman, author of Building Microservices and Monolith to Microservices, told attendees at the QCon developer conference in London that "microservices should not be the default choice."

Microservices have become today's equivalent of "nobody ever got fired for buying IBM", a common catchphrase back in the '80s, said Newman. "With half of all the clients I have worked with, I have told them microservices are not for you."

In case you should doubt him, another session at QCon described how Segment, a data analytics company based in San Francisco, went "to microservices and back again."

"After years of continuing to add to our microservice architecture we found ourselves in a spot where our developer velocity was quickly declining and we were constantly tripping over our microservice architecture and its complexity," said the abstract. "Moving to a monolith was the solution that worked for us."

The implication is not that microservices are no good, but that developers have adopted them too readily, persuaded by the benefits. The idea of microservices is that decomposing an application into small independent services makes it possible to update it more quickly and safely, and to scale more efficiently, whereas applications that are compiled into a single large executable – monoliths – require all-or-nothing deployments that are harder to coordinate.

Explaining the benefits of microservices, Newman said: "There are lots of reasons why we might pick a microservices architecture, but the one I keep coming back to is this property of independent deployability."

If you want to make a change to some part of an application, such as the part that covers shipping, "I should be able to deploy that shipping service into a production environment without having to change the rest of the system. This helps to ship software more quickly and it helps our teams work in a more autonomous fashion."

What, then, is the problem? The core issue seems to be that it is hard to do microservices well. Newman described what he called "the worst of the monoliths, the distributed monolith". This describes a system that has been decomposed into multiple processes, "but for whatever reason, we have to deploy the entire system together as part of a lockstep release. Often this can occur because we've got our service barriers wrong. We're smearing business logic all over these different layers. We're having to coordinate between multiple teams to get anything done."

A sign of trouble, said Newman, is that "if you have a full-time release coordination manager, chances are you have a distributed monolith." Newman sees great value in continuous delivery, where software is automatically built and tested and therefore already ready for release.

The distributed monolith has the deployment complexity of a microservices architecture, but without its benefits. The services lack the "independent deployability" critical to success.

This was a popular session at QCon. Why? A clue came when Newman asked attendees if they have some application or system that is "too big, that you're trying to make smaller." Hands went up all over the room.


Newman made the point that even applications deployed as a single process, or monoliths, can be modular in their design, with different teams working on each module. It is nothing new – it's an idea "from the early 1970s around structured programming", he said. This gives "a degree of independent working" and is "a highly underrated option". A potential problem with modular applications is that "people tend to be not good at defining module boundaries or having discipline about how module boundaries are formed" – the result being "they descend into a ball of mud". Overcome this, though, and many organisations "would be better off" with a modular monolith than with a microservices architecture.

It is worth noting too that if you have a well-designed modular application, decomposing it into microservices is relatively easy. You will be able to reuse a lot of the code because the concept of isolated sections of code dealing with different features is already in place. The "units of decomposition," said Newman, are the "domain concepts, such as invoicing, notifications and order management."

"Monolith has become a replacement for the term we used to use, which was legacy. It's a problem because some people are starting to see any monolith as something to be removed. That's deeply inappropriate. The monolith is not the enemy. This is not the problem that you've got."

Given that microservices are not the right solution in every case, what are the clues that an existing monolithic application might actually be a good candidate for decomposing into microservices? "You've tried all the easy stuff," Newman told The Register. "Have you done some value chain analysis? Have you looked at where the bottlenecks are? Have you tried modularisation? Microservices should be a last resort."

Even scalability may not be a good enough reason to adopt microservices. "My clients say, my application doesn't scale. I ask, have you tried running 10 copies of your monolith? And they haven't. Do all the easy stuff first." ®

Send us news
Get our DevOps newsletter

Keep Reading

Red Hat snaps up Kubernetes security specialist StackRox

Onward to OpenShift

Microsoft's most useful open-source project for Kubernetes, Dapr hits the 1.0 primetime

API now stable, more on the way

Microsoft takes Kubernetes right to the edge with release of Akri for IoT devices

Beware Greeks bearing gifts

Microsoft is not the enemy, why Google still runs 'Borg', and other insights from Kubernetes founders

Kubecon Europe Brendan Burns looks forward to 'Visual Basic for the cloud'. Really?

Long after Linux, Windows Server Containers finally arrive on Microsoft's Azure Kubernetes Service

Generally available, but will never reach parity with Linux on Kubernetes

Netherlands minnow Red Kubes releases open-source Community Edition of its Otomi Kubernetes wrangler

Easy to use with no big vendor lock-in? Nice idea but it's still early days

Microsoft introduces Open Service Mesh for Kubernetes, plans quick donation to CNCF

Interview 'Customers are trying to use Istio and having a hard time, we see this from the support ticket volume'

Everything's coming up Kubernetes: Google Cloud adds support for Windows Server Containers

All your clouds look like K8

DataStax releases K8ssandra, the Kubernetes peace offering to the open-source community

'Like any good family, you're going to have fights,' says dev relations bloke

Kubernetes moves to end ‘permanent beta’ for some APIs

Developers told to hurry up and get features stable as support for other features extends to help slow upgraders

Tech Resources

5 Things To Consider When Choosing An APM Tool

The goal: to reach a state of observability where the whole picture is detailed and constantly up-to-date — with monitoring and alerts that take it all into consideration.

Four Key Tips From Incident Response Experts

While nothing can fully alleviate the stress of dealing with an attack, knowing what to do in advance will help you defend your organization.

The Role of Machine Learning and Automation in Storage

There has been lots of hype around the increasing role that machine learning, and artificial intelligence more broadly, will play in how we automate the management of IT systems.

Catching Modern Threats: InsightIDR Detection Methodologies

Learn how our multi-layered approach enables teams to detect malicious activity across the attack chain for both known and unknown threats.