Simon Brown says it nicely:
I'll keep saying this ... if people can't build monoliths properly, microservices won't help. #qconlondon #DesignThinking #Modularity—
Simon Brown (@simonbrown) March 04, 2015
Architect Clippy is a bit more snarky:
I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?—
Architect Clippy (@architectclippy) February 24, 2015
In both cases, the message is the same: microservice architectures (MSAs), in and of themselves, are not necessarily “better”. There are aspects where moving to a distributed architecture from a monolithic one can improve a system (e.g. enabling selective load balancing and incremental deployment). However, if someone isn’t capable of building a modular monolith, distributing the pieces is unlikely to help matters.
Even where the requisite architectural design capability exists, however, it isn’t a given that distributing the components of the application is the right choice. Distributed applications will incur additional complexity from both a development and an operations standpoint. The more granularly the application is distributed, the more complexity will result. It makes little sense to incur complexity costs that outweigh any benefits received. The decision, however is not a binary one; system architectures that fall between MSA and monolith are possible. One can selectively apply MSA and/or SOA principles from the application level all the way to the enterprise’s IT architecture.
Daniel Bryant’s “Drafting a Proposal for a Microservice Maturity/Classification Model” contains an interesting taxonomy of application architectural styles:
- Megalith Platform
- Humongous single codebase resulting in a single application
- Monolith Platform
- Large single codebase resulting in a single application
- Macro SOA Platform
- Classical SOA applications, and platforms consisting of loosely-coupled large services (potentially a series of interconnected monoliths)
- Meso Application Platform
- ‘Meso’ or middle-sized services interconnected to form a single application or platform. Essentially a monolith and microservice hybrid
- Microservice Platform
- ‘Cloud native’ loosely-coupled small services focused around DDD-inspired ‘bounded contexts’
- Nanoservice Platform
- Extremely small single-purpose (primarily reactive) services
As a taxonomy of application types, Bryant’s work is interesting. Some of the details he’s listed for each type are highly generalized (e.g. Megaliths and Monoliths are assumed to be highly coupled, low cohesion big balls of mud that are difficult to understand), but it could serve as a basis for categorizing applications. As a maturity model, however, it has serious issues. As a maturity model, it would assume that nanoservices(!) represent the zenith of application design. I would argue that this is inherently flawed. Not all enterprises will necessarily require applications fitting the full MSA model. The idea that all applications would benefit from this style of architectural design is extremely hard to believe. I would argue that forcing this style onto smaller applications with limited user bases would be harmful – incurring unnecessary expense for these applications would risk discrediting the technique in circumstances where it would be appropriate.
Where a technique is chosen because of evidence that it delivers specific benefits that meet specific needs and the costs involved don’t outweigh those benefits, there is a higher probability of success. Where the decision is made on the basis of using what’s “new” or “cool”, there’s no real way to give a probability of success because the selection criteria is divorced from fitness for purpose. That being said, my bias would be towards a much lower chance of success.
Innovations can be alternatives without necessarily being “better” in all cases.
17 thoughts on “Microservice Architectures aren’t for Everyone”
Hi Gene. It seems to me that the quality of a system or architecture (or design or implementation) is determined by how well the solution overcome pain and/or enables gain, for the jobs the consumer performs in their environment. Isn’t this where the maturity model belongs.
I use the analogy of a PGA golfer. You could come up with a maturity model that captures: a) the players position at address, b) the plane of the backswing, the position at the top, the balance of the downswing, the alignment of the swing at impact and the shape of the follow through. There are several golfers who perform wonderfully on this maturity model. Then there are golfers like Lee Trevino, Arnold Palmer and Jim Furyk, who wouldn’t perform as well.
Yet these are among the greatest golfers of all time. This is because the real maturity model is strokes per round (vs. competitors). The beauty of the swing is less important than the ability to stay out of trouble, recover from trouble, and get the ball into the hole.
The level of coupling, cohesion, robustness, efficiency and other implementation qualities are important, but they are only part of the equation. A loosely-coupled, low-cohesion, robust, efficient solution is efficient, but it is only effective if it truly solves the right problem.
Or stated more simply: efficiency is doing things right; effectiveness is doing the right things well.
Indeed…I was telling someone earlier today on Twitter – the key is not to confuse the capability with a technique. Techniques come together (or not) to make the capability and it’s the grade of the capability that determines how ‘mature’ you are.
BTW. Prior post is just emphasizing the point you made in the last sentence, but elaborating because it’s too damn important to be whispered 🙂
LikeLiked by 1 person
Pingback: Three Short Links: March 10, 2015 - Apprenda
Just commented on another on the same subject – but I think this is a false duality. The conversion process is a two way street. We shouldn’t be talking about turning monoliths into microservices, we should be talking about composing microservices into monoliths. It’s glue – composition – flexibility – reusability – and simplicity. It’s difficult to use a micro service architectures because, if large enough (and they will become large enough) they become almost impossible to use. On the other hand – ‘easy-to-use’ monoliths are like lumbering giants – when they fall – they fall hard. Sometimes they don’t get back – in the same way a micro-service architecture is like a liquid sand that’s useless without a container to hold it in.
In my humble opinion – we should be building containers (i’m not speaking metaphorically) to hold the services in a ‘bowl’ . Maybe form it like clay and harden it. Then melt it and form it again. Traditional monoliths have no ability to do this – and microservices need structure – with the end result looking like a monolith. Some monoliths are actually built this way, and they tend to work out well. There’s always an iteration – build something – break it apart – put it back together again – figure out what’s reusable – make the smalls table – put it together – and then you have a big thing that’s stable. Standardized conventions would let you mix and match services within a monolith with ease – and nobody has to know 😉
Didn’t read that sentence in the middle – just the beginning and the end – just pretend like this comment is referring to the first two quotes in isolation haha 🙂
I see it as less of a duality and more of a continuum. On the monolithic extreme, you have a an application with a simpler infrastructure but very little flexibility re: deployment, scaling, etc. On the MSA extreme, you have the opposite. What matters is whether the benefits match the needs. I’m of the opinion that the answers to that question are most likely concentrated closer to the center than to either end.
Pingback: Microservice Principles, Technical Debt, and Legacy Systems | Form Follows Function
Pingback: Are Microservices the Next Big Thing? | Form Follows Function
Pingback: Form Follows Function on SPaMCast 353 | Form Follows Function
Pingback: Microservices - Cloud Architecture for Digital Businesses - Cloud Best Practices
Pingback: Microservices Cookbook: Design Principles for Microservices - CBPN
Pingback: Monolithic Applications and Enterprise Gravel | Form Follows Function
Pingback: Microservices Recipes - Going Cloud Native
Pingback: Microservices Recipes - CBPN
Pingback: Microservices Recipes | @CloudExpo #Cloud #Containers #Microservices - Recipes of The Day
Pingback: Microservices, Monoliths, and Modularity | Form Follows Function