Source:theregister.co.uk
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.”
