We've been hearing a lot about microservices in the past year or so. Whether you believe they are a new architectural approach or just some repackaging of SOA, it is hard to argue that the concept has not taken the developer community by storm. An often cited source for some of the original microservices materials, distilling the experiences and writings of groups such as Netflix, was Martin Fowler's article. Recently Martin has written more on the topic and particularly about when people should consider using microservices.
One of the consequences of [overhyped microservices] is that we've seen teams be too eager to embrace microservices, not realizing that microservices introduce complexity on their own account. This adds a premium to a project's cost and risk - one that often gets projects into serious trouble.
Martin admits that whilst there may be a lot of hype around the term, it's a useful term to use for an architectural style that has been around for a while. What's interesting though is that Martin does not refer to this style as a variant of SOA, despite that being the view of some of the early practitioners of microservices. Regardless of the name, Martin goes on to ask the question many developers are wondering: is a microservices architecture a good choice for your system?
The fulcrum of whether or not to use microservices is the complexity of the system you're contemplating. The microservices approach is all about handling a complex system, but in order to do so the approach introduces its own set of complexities. When you use microservices you have to work on automated deployment, monitoring, dealing with failure, eventual consistency, and other factors that a distributed system introduces.
In his article Martin includes a graph which attempts to show how complexity of microservices changes compared to that of typical monolithic approaches. From this his recommendation is:
don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.
The types of complexity that may push developers towards using microservices include multi-tenancy, supporting different business functions evolving independently and scaling. However, in Martin's view the single biggest factor that may decide whether or not to use microservices is finding that the monolith has become too big to modify and deploy. However, as we reported last year, Simon Brown makes an interesting observation:
If you're building a monolithic system and it's turning into a big ball of mud, perhaps you should consider whether you're taking enough care of your software architecture. Do you really understand what the core structural abstractions are in your software? Are their interfaces and responsibilities clear too? If not, why do you think moving to a microservices architecture will help? Sure, the physical separation of services will force you to not take some shortcuts, but you can achieve the same separation between components in a monolith.
Martin also looks more objectively at microservices and their monolithic cousins:
Many of the problems ascribed to monoliths aren't essential to that style. I've heard people say that you need to use microservices because it's impossible to do ContinuousDelivery with monoliths - yet there are plenty of organizations that succeed with a cookie-cutter deployment approach: Facebook and Etsy are two well-known examples.
And he also agrees that there is no real reason why as a system's size increases you should be forced to look at microservices in order to have more easily replaceable parts (components). There are no good reasons why a single monolith cannot have well defined module boundaries. However, in practice Martin believes that it is often too easy for these boundaries to be breached as monoliths to become the eponumous Big Ball of Mud. In conclusion though Martin wants people to think long and hard about all of the factors involved in their architecture and system implementations before making the leap to microservices:
As size and other complexity boosters kick into a project I've seen many teams find that microservices are a better place to be. But unless you're faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably. So if you can keep your system simple enough to avoid the need for microservices: do.