DevOps

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'

Got Tips? 43
SHARE

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.

Modularity

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." ®

Sign up to our NewsletterGet IT in your inbox daily

43 Comments

Keep Reading

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

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

All your clouds look like K8

Couchbase goes cuckoo for Kubernetes with v2.0 release of Autonomous Operator

NoSQL or open source, databases cannot help but be drawn to Googly cloud container orchestration system

VMware's Tanzu Application Service for Kubernetes hits beta, will take some time to get production-ready

'Only for evaluation environments' say release notes, and they mean it

Google Cloud embraces GitOps with new Application Manager for Kubernetes

Cloud giant aims to attract developers with code-oriented deployment automation

Tekton Pipelines hits beta: 'Ragdoll Norby' to sort continuous integration for Kubernetes

And 'difficult to understand, hard to debug' PipelineResources have been deprecated

What is Google up to with Anthos? More toys dropped for Kubernetes-style hybrid cloud

Service Mesh and Cloud Run put existing features in a pretty wrapper

Didn't see that coming: DataStax emits open source Kubernetes operator for Cassandra

Although you need to hop in the Management API sidecar for the really good stuff

Are you a Dapr Dan? Microsoft teases runtime for Kubernetes to make microservices sparkle

Building blocks for devs. Because you can't be all Waity K8-y when Google's all-in

Try to contain yourselves: Google Cloud lights Spark for Kubernetes

Dataproc service will run Apache Spark on K8s, now in alpha

Tech Resources

Ransomware has gone nuclear

A new generation of attackers are crafting plans to cause the most panic, pain, and operational disruption. They will take the time to maximize your organization’s potential damage and also their payoff -- not just encrypting your data, but stealing it and posting it publicly if you don’t play ball. Join Roger Grimes from KnowBe4 and Tim Phillips from The Reg for a RegCast in which they will be sounding the ransomware emergency klaxon.

Keeping a Security Mindset

Leaders and experts discuss ways you can bolster secure remote working through education and effective security measures

Network Detection & Response for MITRE ATT&CK Framework

Read the white paper for a high-level view of how enterprise NTA with ExtraHop Reveal(x) detects and enables investigation of a broad range of the TTPs catalogued by MITRE ATT&CK!

Simplify Endpoint Backup with Druva

To ensure data protection and business continuity, it’s critical to deploy an endpoint backup solution.