
In Defence of the Monolith, Part 2 - pieterr
https://www.infoq.com/articles/monolith-defense-part-2
======
abraae
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.

~~~
empthought
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.

~~~
stuartaxelowen
"Microservices are just tiny monoliths" \- _gasp_

~~~
empthought
They're not, though. sed is a microservice. Emacs is a monolith. Sed is not a
tiny emacs.

~~~
parenthephobia
Nobody said it was: sed is a tiny perl.

~~~
arglwarg
sed is maximum viable perl. Well maybe awk, but that is pushing it.

------
mattchamb
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.

------
_RPM
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?

~~~
jacquesm
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.

------
ionised
Get out of here STALKER...

------
thomasfoster96
Partially off-topic: Does anyone else find the fact that this is “Part 2” of a
“Defence of the Monolith” ironic?

