
Questions to ask before adopting microservices - ebineva
https://medium.com/@ebin/stop-you-dont-need-microservices-dc732d70b3e0
======
emerongi
I recently did some reading on microservices, since I had to create a multi-
service deployment.

I really don't understand how people are able to manage the complexity when
they split every single small domain of an application into its own service.
You have to re-invent layers that are normally provided to you by the
database, you have to deal with a lot of extreme edge and failure cases and
you also lose any ability to statically figure out how data flows through your
application (codebase becomes harder to understand, fixing bugs will probably
take longer).

In our case, we have each _application_ as a separate service. On top of that,
we have some smaller supporting services to make certain things easier, but
they're limited and their use makes sense outside of creating complexity for
sport.

~~~
echelon
Microservices are for companies with 500+ engineers.

They help teams manage complex interdependencies by creating strong ownership
boundaries, strong product definition, loose coupling, and allow teams to work
at their own velocities and deployment cadences.

If you're doing microservices with 20 people, you're doing it wrong.

It's when you have 500 people that the average engineer doesn't need to know
about the eventually consistent data model of your active-active session
system. They just need your service API.

~~~
james_s_tayler
What do you do if you have ~20 people and a decade old million line monolith
that you're now bumping up against the limits of?

~~~
user5994461
20 people wouldn't make a million line in a decade. That's more like the
output of a few hundreds people.

~~~
_se
Haha, I love comments like this.

We've written over 10 million lines as 20-40 people in the past 15 years. I'll
be sure to tell everyone we're not supposed to be moving so fast.

~~~
user5994461
Funny enough, you wouldn't be able to work fast at all in a 10 MLOC codebase.
Working with and navigating that amount of code is a bummer.

Imagine for a minute, if there were 50 developers (ignoring managers and
administrative overhead) trying to understand 500 lines a day (a medium sized
module in most languages), they still wouldn't be able to go through half the
codebase in a whole year. So basically most of codebase can't be read or
maintained.

------
jcadam
I've had good luck with more of a hybrid architecture: one central monolithic-
ish service and numerous supporting microservices to perform specific (usually
asynchronous) tasks. The microservices tend to be things that are easily
separable from the core of the system and can be turned on or off without
affecting core functionality (they also tend to be long-running and/or
resource-intensive tasks). This is especially helpful in instances where we
might not want to even deploy some capabilities depending on the environment.

I think you get some of the benefits of both approaches here: A single
monolithic service that encapsulates the functionality needed for a minimal
working system, and the ability to carve off and maintain clearly non-core
functionality into separate programs to avoid bloating up the main service.

~~~
flamtap
I agree with this. Microservices have their place. So do monolithic,
centralized services. Using both in the same system is certainly not a sin,
can can certainly be correct.

I'm currently reading through Juval Lowy's latest book, Righting Software.
Juval is widely credited as one of the pioneers of microservices [1], and he
states in the book that even he doesn't appreciate the term. He illustrates
his point by comparing the small, eight-inch water pump in his car versus the
huge, eight-foot city water pump that moves water to his home. Both perform an
unarguably essential service. But just because the pump in his car is orders
of magnitude smaller, does not make it a "micropump". A service is a service
no matter how big or small it is.

Should you use microservices? As is the answer to any sufficiently interesting
question: it depends.

[1]
[https://en.wikipedia.org/wiki/Microservices#History](https://en.wikipedia.org/wiki/Microservices#History)

------
NohatCoder
I think that if the question you ask is: Should I use microservices or not?
Then you have already failed. The question you should be asking is: Where
should the application be split?

Nowhere, or into two unequally sized chunks, are both valid answers. If you
can't split a component without resorting to weird coupling shenanigans, then
don't split it.

------
TrickyRick
Finally someone acting reasonable in this discussion. When I tell people my
startup (We're two developers, a few thousand LoC, a pretty simple web
service) is built as a monolith people look at me as if I'm crazy. Many people
don't seem to realize that microservices are are A tool, not THE tool.

------
pwm
My advice is favour places with engineers who both have the knowhow and the
power to make decisions based on cost/benefit analysis. There is no right or
wrong without context. Beware of places where engineering is driven by hype
and/or dogma.

~~~
gridlockd
You mean the engineers that have rolled out multiple monoliths and
microservice architectures across different teams with different backgrounds,
all the while keeping careful track of expenditures?

I'm sorry, these people do not exist. People are going to eyeball and wing it,
based on personal preference and their gut feeling. Dress that up with good-
sounding arguments and maybe even some metrics and you have all you need to
convince the stakeholders - who almost certainly don't understand the issue at
a deeper level, nor do they care to.

It's also made more nuanced by the fact that people talk about different
things when they mean "microservice". Anything can be split up into
arbitrarily small services. This is attractive from a management standpoint,
because you can assign engineers in a simple manner without too much
crosstalk. Most likely, nobody will ever bother to check if you're spending
10x the engineering resources to do the job.

In essence, I can wholly recommend microservices to engineering managers who
want to take full advantage of Parkinson's Law.

------
jacquesm
Do not apply rules dogmatically would be a good rule... The willy-nilly
breaking up of monoliths into microservices without a good reason to do so
other than 'everybody else is doing it too' or 'microservices are cool' are
going to result in a lot of busywork and ultimately will not serve your
business interests.

If and when the time is right to break out some part of a monolith into a
service is probably going to give some kind of net benefit. But breaking up a
monolith into > 10 services without having done a proper analysis of the
downsides and the benefits of doing so will result in wasted effort.

Monoliths aren't bad per-se, neither are services or even microservices.
Knowing when and why you choose each and what the drawbacks of these are for
any given situation is something the reason why you have CTO's and architects.
Way too often the decisions about this level of granularity are taken at the
wrong level with all kinds of predictable results.

Asking these questions is a good start. An even better start would be to ask
yourself whether _you_ are the person best positioned to answer these
questions, and if not what individual or group of people is.

Most companies (SME's, < 500 employees < 100 devs) do not need microservices
but some of them _might_ use them to their advantage. Some problems you won't
solve without, some are going to become needlessly complicated if you use
them. In most cases either a well architected monolith _or_ a couple of
services with a unified front end will work as well or better than either a
monolith or microservices. Some environments lend themselves particularly well
to microservices (Erlang, Elixer), others are next to impossible to put
together without including half of a new operating system.

Use common sense and err on the side of caution. A very good indication that
you are using microservices wrong is when they start to call each other
horizontally, effectively re-creating RPC or function calls across process
boundaries.

------
bszupnick
I was one of two developers who built a large micro-service system from
scratch. It was the correct way to do it given the requirements and
limitations. The dev-ops overhead was HUGE. Handling multiple repositories,
versions, version-dependencies, documenting/coordinating changing APIs between
the micro-services.

Even something as simple as having 12 different repositories meant 12
different Bitbucket pipeline yaml files and there was no way for repos to
share pipelines. So one change meant 12 changes.

It was good experience, and HAD to be done in that type of architecture, but
keeping it all organized was a challenge.

~~~
yonl
One of the major overhead for me was writing tests. I used to get so
frustrated because there are so many, so many things to mock / stub.

Do you have any suggestions for testing (Mostly service API testing) ?

~~~
coverj
I'm only probably a month ahead of you but with my research and initial
testing I've liked [https://stoplight.io/open-
source/prism/](https://stoplight.io/open-source/prism/) so far. There are a
lot of other options out there too if you are willing to make a swagger/open
api spec

------
epicgiga
A lot of these things do come down to manager or mid-level dev types who just
want to use hot tech, either because it's a shortcut to sound like an expert,
or they want to do it to gain experience in it.

The problem is, the tech is hot because google etc do it, and they're using it
to solve problems light years from what yours might be.

The results are absurdly engineered monstrosities. Simple blog sites with 10
different frameworks in them, running on some absurdly complex cloud
infrastructure.

------
mathw
My team's currently building a proof-of-concept microservicey replacement for
a chunk of our company's platform, based on solid understandings of the
problems the existing one has, what it'll need to do in the future etc. The
architecture offers some very compelling solutions to these problems.

But we based this on evidence, we're testing everything to destruction, we're
embracing tooling to help us manage everything (we could not do this without
Terraform or something of similar capability)... but actually, our domain maps
to microservices extremely neatly.

It's probably the first place I've ever worked where that's the case.

I like this article, because it draws attention to very real issues and
problems with these architectures, and there is an overall danger and enormous
risk in using an architecture "because it's good" or "because it's the way of
the future" rather than the only correct reason to choose an architecture:
because it's the right fit for your problem.

Oh also, because our thing is still a proof-of-concept, we may yet throw it
all away and build something else. While initial results are promising, we
haven't properly proved the concept yet.

But what a joy to work somewhere that lets us do this.

~~~
2T1Qka0rEiPr
> based on solid understandings of the problems the existing one has

This. It strikes me that developing a clean monolith with well separated
concerns _and then_ deciding to pull off chunks into microservices, as being
infinitely smarter than the reverse - finding your microservices to be higher
interdependent, and trying to glue them back together. YAGNI should be a over-
arching principle when starting out a project (and possibly, a business).

------
pibi
I'm mostly a solo developer now, and I'm working with microservices all the
time. It's very good to focus on a single domain while developing a single
part of the system, just like coding modules or classes.

That said, I'm always wondering why we are conflating so many different things
when talking about microservices: deployment and scalability, multi-repo and
code structure, integration tests and distributed transactions, and so on. I
mean: you can definitely build your application in a monolithic system with a
microservices architecture. It's just separation of concerns all the way down
and a proper abstraction for the communication channel. You don't need to
embed your system architecture in your repos and your code. These are
"framework" problems. Just use one that abstracts all the deployment details
until it's time to push the code to prod and you have to split your code in
different containers. For example, I'm now settled on Moleculer
([https://moleculer.services/](https://moleculer.services/)). It just works.

(edit: grammar)

------
BozeWolf
Working on a microservices project currently. It is very well designed.
Although i think this is not because of it being microservices. It is because
of the team of skilled engineers.

Using microservices is complete overkill here. Lots of DevOps, hard to get the
mental picture for new people. Also we share a lot of code between the repo's.
That shared code is in a separate repo. Splitting of code from one repo and
putting it in another repo. Refactoring tools dont like it that much. The
quality of the code base is what matters and that is quite alright here.

I liked this line in the article: _But you should always remember; a well
designed codebase can always be switched to microservices, as and when you
approach the threshold._

I will remember that when I design a new monolith: every "application" in that
monolith should be able to stand on its own. Every PR will be reviewed like
that.

------
highhedgehog
Isn't a monolithic service just kind of a single service micro-service system?

~~~
GrumpyNl
I dear to say that a well designed monolith has a lot of mini micro-services
build in.

~~~
highhedgehog
Yeah I agree with that

------
kureikain
We only has 8 services and already see the pain of microservices. We are
trying to merge some of them.

I think micro service is a useful technique, only when use properly at a
certain scale.

I wouldn't bother doing microservice when team is small and product isn't
mature because we still haven't figured out exactly what each service has and
may eventually has to duplicate some functionality.

With that being sad, I think thing like auth, push notification is absolutely
should be their own services.

------
hnzix
_> We replaced our monolith with microservices so that every outage could be
more like a murder mystery._

