Microservices shift complexity to where it belongs
Microservices are no free lunch, but they are smart nutrition.
London Eye (source: Pixabay)
Virtually every talk, discussion or a blog post about microservices architecture makes a point of warning its audience that this novel architectural style, while bringing many benefits, increases operational complexity significantly. One of the first and, probably, most cited articles on this subject is: “Microservices – Not A Free Lunch!” by Benjamin Wootton. It was followed by Martin Fowler’s blog post where he coined the “You must be this tall to use microservices” meme, providing a list of minimum requirements for safely practicing microservices architecture, not unlike the list of safe height requirements published at many amusement/theme parks.
While these warnings certainly have some ground, at least for now, I believe they only tell a small part of the story. I recently discussed the “partial truth” issue at the API Strategy and Practice Conference in Austin, Texas (see: video recording) and it was very kindly received, so I would like to elaborate on this topic here.
Learn faster. Dig deeper. See farther.
What do we gain with microservices?
It’s still early days for microservices, and it’s fair to ask what benefits they provide if they increase organizational complexity. After all, we should only adopt a new technique if it significantly simplifies what we do, correct? Maybe yes, maybe not. Fred Brooks provides a rather sobering perspective on the subject, in his 1986 book:
“… there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.”—Fred Brooks, No Silver Bullet
According to Brooks, software systems have essential complexity that cannot be removed without also taking away essential functionality of the system. There does exist part of the system complexity that can be optimized with better processes or better architecture (he calls those “Accidental Complexity”), but there is definitely a limit to what we can optimize. The larger the system, the larger its core functionality—therefore smaller is the part that we can “optimize-away.” Naturally, this effect is especially true for so-called enterprise systems, due to the complex business environment they are deployed into. As my friend, and co-author, Ronnie Mitra aptly explains: generally speaking, we are not removing complexity, we are shifting it from one area to another.
Creating a balanced diet of complexity
The “shifting of complexity” point is exactly where microservices architecture excels and why we can use it in an extremely powerful way to improve inherently complex systems, such as enterprise software. A general claim that microservices architecture is overall “simpler” vis-à-vis its arch-nemesis monolith is inaccurate. Many small moving parts are not inherently more manageable than one huge organism. Indeed, while the individual complexity of a microservice may be reduced, the sophistication of orchestrating a large, distributed system is significant. What microservices architecture actually does is it shifts complexity from the space of code design and implementation into system operations.
Although moving complexity from one place to another may seem to be just stashing away the problem, we actually gain a lot. Microservices architecture allows us moving complexity into the area where we know how to automate things. We have learned a lot in the past decades about automation of systems operations. In contrast, we unfortunately really haven’t had any significant progress in automating software architecture design or development. Remember all those RAD tools? Yep, they didn’t really work.
In summary, with microservices architecture we are taking complexity out of the area we aren’t good automating (software design and development) and moving it into the area we have become extremely good at automating: operations. And that really is the big, essential win with microservices architecture. That is also why “increased complexity” of operations in microservices is not scary (hint: it’s by design) and why microservices isn’t just “rebranded SOA.” Microservices is the child of its time—the time when we learned effective ways of automating operations.
This post is a collaboration between O’Reilly and CA Technologies. See our statement of editorial independence.