Pretty much every talk, conversation or blog post about Microservices architecture makes a point of warning its audience that this novel Architectural style, while bringing many benefits, does significantly increase operational complexity. One of the first and, probably, most cited writings 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 ‘tall-enough to do Microservices’ meme.

While these warnings certainly have some ground, at least for now, I think they only tell a part of the story. I recently discussed the “partial truth” issue at the API Strategy and Practice Conference in Austin, TX (see: Slide Deck and Audio) and it was very kindly received, so I wanted to also explain my thoughts on this blog.

What Do We Gain with Microservices?

The critical question to ask, when considering Microservices architecture is: why would we want it, if it significantly complicates operational complexity?

“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 Fred Brooks, software systems have essential complexity that cannot be removed without also taking away essential functionality of the system. There’s part of the system complexity that can be optimized with better processes or better architecture (“Accidental Complexity”), but there’s limit to what we can optimize.

Larger the system, larger its functionality - therefore less is the part that we can “optimize”. This is especially true for so-called: enterprise systems, obviously. As my friend Ronnie Mitra aptly explains: generally speaking, we are not removing complexity, we are shifting it from one area to another. There’s also an excellent, deeper discussion of this point that you can find in Matt McLarty’s recent blog post: Calling All Architects: It’s Time to Develop a Complex!

I believe this “shifting complexity” point is extremely true for Microservices architecture. The claim that MSA “simplifies” system implementation, as opposed to its ‘arch-nemesis’ Monolith is generally untrue. What Microservices architecture actually does is: it shifts complexity from the space of code design and implementation, into: operations.

Why is this good, you may ask? If we are just shifting complexity from one place to another, what do we really gain?

What we gain is: moving complexity into the area where we know how to automate. We have learned a lot in the past decades about automation of operations, but we really haven’t had any significant success in automation of software architecture design or development. Remember all those RAD tools? Yeap, they didn’t really work. So:

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 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 (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 OPs.