All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements.
Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as long as billing works and users get content when they want?
There's another strong driver for microservices however, which is customer choice, particularly in SaaS settings.
In our industry (HR software), there is no one right answer, or one business problem - customers demand choice, every customer has slightly different needs, and microservices are indicated because they allow customers to pick and choose. The same is true for most SaaS areas I would say.
As an example, one tiny sub-area of HR software, employee engagement improves when we offer employees meaningful benefits. It turns out that many employees love their pets, and offering pet insurance could be a great perk (the HR space is so big that just this niche within a niche could be a multi-million dollar opportunity for someone with a good offering).
Yet would anyone seriously consider altering a monolithic HR application to add pet insurance management? Never. The only viable solution is a microservice, that does just this, and does it well, and plugs into the rest of the stack via APIs.
tl;dr: in the SaaS world, microservices are sometimes indicated not for architectural reasons, but to support customer choice, which is far more important.
I think what you have there is a monolithic HR application and a smaller monolithic pet insurance application that exchange information via enterprise integration, not a microservice architecture.
I don't usually find arguing over names to be productive. Your "smaller monolithic" application is my microservice. What's in a name?
But as a customer, if I have a HR app from vendor A, and then I want to add a pet insurance app from vendor B, the last thing I want to do is to roll out some creaky enterprise integration process/framework/product. If those products work together via APIs why should I take any of the burden of integration?
What's in a name? Microservices are fine-grained and operate on a single bounded context, where applications typically have coarser-grained interfaces and involve multiple contexts. I suppose if your pet insurance system were only to provide a constrained list of values of pet insurance products, and provide an interface to associate them with a user ID from the HR monolith, then it's a microservice. (Of course, you've pushed off the integration with the _actual_ pet insurance app somewhere else, but that might be OK.)
"APIs" are an enterprise integration technique [1]. There's nothing inherently creaky or frameworkey about them.
> Yet would anyone seriously consider altering a monolithic HR application to add pet insurance management? Never.
Sure they might? I can't see a category of business features that would naturally lend themselves to being microservices rather than extended features of a monolith unless there was some real technical challenge that was otherwise more easily solved by being in a microservice.
calling something over http vs calling functions or class methods does not make much difference. So in your example how does it make it easier to add vs monolith? Monolith can have well defined modules and interfaces and microservices could be an entangled mess.
No one owns the whole stack. You pick your "main" software, and customize it with third-party services. None of it runs on your premises. No party is willing to expose much more than an API.
It seems like you're talking about a plugin architecture, not necessarily microservices. Microservices could be a way to implement it. Not all systems built with microservices could support a plugin like that, not all plugins need to use microservices, and even if you do you might have to write some form of adapter to integrate someone else's service with your system.
E.g. most video games support stuff like this, but they definitely don't use microservices.
Monolith has become a buzzword. Is any business software actually not a monolith? I mean does it make business sense to re write everything as a microservice?
As always: it depends. Some organizations would benefit from it because they plan on a trajectory that will cause their software to change repeatedly over a longer period of time. Microservices would make it a lot easier to tackle a portion of the whole and to swap it out with something different, or to remove or add pieces in their entirety.
Monolithic software can be quite good when developed with a good understanding of what you want the future to look like. If the future holds more uncertainty such projects tend to become stale and acquire traits usually associated with legacy projects: hard to impossible to maintain or adapt to new roles, no clear interfaces between sub-sections (if those are identifiable at all) and hard to test.
So no, it's not for everybody and it's not for everywhere, but when applied properly it can make all the difference between maintaining forward momentum and losing it entirely after only a few years in business.
The great power of microservices is they allow a reduction in scope, and that alone is worth quite a bit in the maintenance and understanding departments, in a monolith the whole thing is the scope, and that can kill your ability to reason about a project.
This article makes the suggestion to break up your .net project into nuget packages. This is horrible and DOES NOT WORK - DO NOT DO THIS.
As someone who, as of this very minute, is working on a project that someone has broken up into different nuget packages - this is a fine idea but it can go very bad and kill productivity completely.
Unless each individual part has independent test harnesses, as soon as you need to make a change, you need to go through the build server to test any change. Combine this with sub-par tooling and you can use your imagination as to how badly that messes up your development flow.
As well as this, it also messes up your potential branching strategies - you cant make a branch to do speculative changes unless you setup a build definition to create the nuget packages. And even if you do this, you need to maintain two streams of versions for the same package. This has a whole range of problems when it comes to updating packages - a package update ends up having to actually be a downgrade in terms of version numbers. This is not supported by your tooling in visual studio.
Before taking this approach, please give it some serious second thoughts.
20 comments
[ 3.4 ms ] story [ 59.7 ms ] threadPerhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as long as billing works and users get content when they want?
There's another strong driver for microservices however, which is customer choice, particularly in SaaS settings.
In our industry (HR software), there is no one right answer, or one business problem - customers demand choice, every customer has slightly different needs, and microservices are indicated because they allow customers to pick and choose. The same is true for most SaaS areas I would say.
As an example, one tiny sub-area of HR software, employee engagement improves when we offer employees meaningful benefits. It turns out that many employees love their pets, and offering pet insurance could be a great perk (the HR space is so big that just this niche within a niche could be a multi-million dollar opportunity for someone with a good offering).
Yet would anyone seriously consider altering a monolithic HR application to add pet insurance management? Never. The only viable solution is a microservice, that does just this, and does it well, and plugs into the rest of the stack via APIs.
tl;dr: in the SaaS world, microservices are sometimes indicated not for architectural reasons, but to support customer choice, which is far more important.
But as a customer, if I have a HR app from vendor A, and then I want to add a pet insurance app from vendor B, the last thing I want to do is to roll out some creaky enterprise integration process/framework/product. If those products work together via APIs why should I take any of the burden of integration?
"APIs" are an enterprise integration technique [1]. There's nothing inherently creaky or frameworkey about them.
[1] http://www.enterpriseintegrationpatterns.com/patterns/messag...
Sure they might? I can't see a category of business features that would naturally lend themselves to being microservices rather than extended features of a monolith unless there was some real technical challenge that was otherwise more easily solved by being in a microservice.
"You pick your "main" software, and customize it with third-party services" - not much difference monolith vs microservices
"None of it runs on your premises" - totaly unrelated to monolith vs microservices
"No party is willing to expose much more than an API" - again consuming an API can actually be easier in monolith vs microservices
E.g. most video games support stuff like this, but they definitely don't use microservices.
Pretty sure you could do it with a new view and an if statement in any MVC every built...
Monolithic software can be quite good when developed with a good understanding of what you want the future to look like. If the future holds more uncertainty such projects tend to become stale and acquire traits usually associated with legacy projects: hard to impossible to maintain or adapt to new roles, no clear interfaces between sub-sections (if those are identifiable at all) and hard to test.
So no, it's not for everybody and it's not for everywhere, but when applied properly it can make all the difference between maintaining forward momentum and losing it entirely after only a few years in business.
The great power of microservices is they allow a reduction in scope, and that alone is worth quite a bit in the maintenance and understanding departments, in a monolith the whole thing is the scope, and that can kill your ability to reason about a project.
As someone who, as of this very minute, is working on a project that someone has broken up into different nuget packages - this is a fine idea but it can go very bad and kill productivity completely.
Unless each individual part has independent test harnesses, as soon as you need to make a change, you need to go through the build server to test any change. Combine this with sub-par tooling and you can use your imagination as to how badly that messes up your development flow.
As well as this, it also messes up your potential branching strategies - you cant make a branch to do speculative changes unless you setup a build definition to create the nuget packages. And even if you do this, you need to maintain two streams of versions for the same package. This has a whole range of problems when it comes to updating packages - a package update ends up having to actually be a downgrade in terms of version numbers. This is not supported by your tooling in visual studio.
Before taking this approach, please give it some serious second thoughts.