Microservice vs Monolith...that is the Question

There seems to be a growing movement online fighting against microservices. The movement itself shouldn’t alarm anyone, such backlash is common with the adoption of any approach or technology. Consider the following:

• Public cloud adoption – companies of all sizes wanted to be “all in”. But many larger companies are finding that it’s cost prohibitive to run absolutely everything in the cloud and as a result, are pulling some workloads back “on-premises”. Rest assured the “cloud” is here to stay and will continue to grow – but in its current incarnation it’s not for every workload where cost is a consideration.
• Agile methodologies – many companies “claim” to make the change, and then fall back on more traditional approaches or adopt hybrid methodologies like SAFE. This is an odd one, as most companies continue to lie to themselves regarding adoption.
• Personal Digital Assistants (PDAs) – including the Newton and the Palm Pilot. These were arguably “before their time” and didn’t offer the long-term value they promised until the phone was integrated with them. But for quite some time new user adoption was higher than disenfranchised user departure creating an analog to common viruses.
• Fad Diets – enough said. It seems like diets have a shelf life, and the diet and fitness industry is largely predicated on reinventing new diets from past diets (e.g. Paleo just being rebranded Atkins).
• 3D Televisions – a few years ago it was hard to find a TV that didn’t offer 3D. Try to find one now. Arguably a poor example, as this particular capability seems to be largely dead.
• Google Glasses – remember the folks we used to call Glassholes? Again, another poor example – following the trend of PDAs as the utility simply wasn’t there.
• Second Life – everyone was trying to get onto it (when it worked). Or course, it didn’t “work” very well. Do you know anyone who uses it now?

Some of the above have clear reasons for failure, including “just didn’t work”. In most cases, the utility provided by the solution simply didn’t merit continued usage, or alternatively warranted lower usage. This last point is the primary reason some companies are moving away from microservices; it just didn’t have a return for them.

The backlash and partial withdrawal from microservices is understandable, especially when considering the following implementation related points:

Inappropriate Usage

Too often, companies will “chain” microservices in-depth, failing to understand the mathematical implication: lower availability.

Teams should understand and avoid common anti-patterns of usage including mesh, fan out, fuse and the associated multiplicative effect of failure. When using appropriate patterns (CQRS, Strangler, Sidecar), they should understand how and why to appropriately use them and from what they should stay away.

Remember – whenever you need to split a solution for depth that would otherwise result in multiple service calls, consider using libraries instead for higher availability.

Flawed or Missing Predicates

Monolithic (functional, short duration) teams and microservices don’t go well together. To truly benefit from a change to services, teams must divide themselves into groups that can properly own the services they create. The team should be “durable”, to ensure that they perform well together (see Tuckman’s Phases of Development). Short duration teams, and teams built around projects (instead of outcomes) fail when implementing microservices as the increased number of services increases team confusion and overhead rather than the intended outcome of decreasing both.

Additionally, many times the business reasons for moving to isn’t appropriately analyzed; teams do it sometimes for the wrong reasons and for others without a reason. Microservices work well when dedicated teams are aligned to services and associated data that they own in isolation (i.e. no other team owns them). When that happens, team velocity often increases and time to market decreases. When effort isn’t applied to ensuring consistency between the organization model and the architecture model (see Conway’s Law), velocity can suffer.

Low ROI

Teams that do not clearly and correctly identify the value upon which an architectural pivot is predicated typically fail at microservices. Lower cost of operations, better availability, faster time to market, lower latency, better scalability and lower cost of scale are all possibilities when implementing microservices. But separating a monolith can be costly business, and specific metrics around value creation need to be developed and analyzed to validate a return on said investment.

The Rebirth and Rise of the Monolith

Monoliths are sometimes preferable to microservices. We often tell our clients that when they are implementing the MVP of a new solution with a small team, it’s appropriate to do so in a monolith. Further, most startups begin with a monolith, and why wouldn’t they? Remember, one of the most valuable capabilities that microservices unlock is the ability to scale a large organization (when properly aligned to teams). A corollary to that is that, for small teams, there is little velocity related value in microservices. The following are a list of scenarios in which a monolith may be best:

• Single, small team and no significant team growth: If the team working on a solution has 15 or fewer people, there is very little benefit to microservices.
• Low rate of solution change (“commits”): Rate of change is often an antecedent to team growth. When a solution has low rate of change, the team managing it is very likely small. As such, services offer little in the way of developer velocity.
• Low demand/utilization, or low to no growth of a solution: One reason to consider microservices is the growth (demand) for a given monolith. If request rates are low, there is little benefit in separating the solution for the purposes of solution scalability.
• Low growth of underlying data: We sometimes consider Y axis, or services (microservices) splits to help solve contention as data increases. When data growth is not a problem, micro services offer little for data scalability.

Summary

The monolith never died, and microservices were never a solution for every problem. Both have their place – sometimes within the same development organization. Your approach to architecture should be predicated on good business analysis – specifically validation that your efforts will have a measurable and meaningful financial return.

When managing a large team, developing a hyper growth product, consider microservices and durable product teams to own those services. When implementing microservices, be mindful of the anti-patterns above and heed our advice on the appropriate usage of patterns (also above). Choose a size for your service that meets the needs/business outcomes upon which it is predicated. If you are unwilling to modify your organization to create alignment to the services they create, do not consider microservices.