
So you want to learn Microservices? - charlysl
https://dev.to/kgoralski/deep-dive-into-microservices-architecture-h54
======
danmaz74
One of the points listed as the promises of microservices is: "Easy to test"

A microservice might be easy to test in isolation, but testing a microservices
based system is FAR more difficult than testing a monolith - personally, I
find that to be the worst part of microservices architecture. I would put
"easy to test" as probably the main advantage of monoliths.

~~~
cousin_it
I think the other listed advantages of microservices also aren't entirely
serious. "Easier deployment than monoliths" are you sure? "Polyglot
persistence" why is that a good thing? "Scalable" no idea what it means. "High
performance" now you're just messing with me.

In my experience, you can have a huge binary doing tons of things that's
nevertheless quick to build and run. And it will be easier to step through,
which is super important.

~~~
jayd16
You should actually try microservices in a larger team before dismissing all
these. Having large feature sets behind a load balancer and having the rest of
the app fail gracefully when a feature goes down, means you can have worry
free deployments. You can deploy a single feature, you can do a tiered role
out on a feature, without impacting any other service. You can also easily
deploy more instances of a service. As long as you've done the work to make
your internal requests stateless then you should be able to maintain high perf
by scaling instances.

Beyond Polygot, I would instead phrase it as new features can roll out without
dealing a large legacy tier of code. Most of your code can be Java with a
single high performance service written in C++, lets say. If you're
compressing video in an async manner, do you really want to throw that in your
RESTful Spring service?

------
cle
Very vague article. I would say that the #1 reason to split a monolith is if
your engineering team has grown too big. The main advantage in my experience
of “microservices” is that they allow groups of engineers to build & deploy
with much less inter-group communication. It’s a great way to scale an
organization.

There are other reasons to split a monolith of course, like in high-
availability high-traffic services, where isolating specific call patterns on
separate fleets makes the system behavior much easier to predict. But
primarily I think microservices solve organizational problems.

~~~
mping
Article is thin but had loads of links. It's more of a compendium than an
article.

I completely agree that microservices are more organizational related than
tech related.

~~~
kgoralski
Yes, this is just the collection of links or compendium. Not really an
article.

btw. This is why I mentioned there "Microservices solve organizational
problems and cause technical problems"

------
turc1656
Admittedly off-topic, but the GIF they have on that site on the right side of
the page with Mac from The Nightman Cometh episode of Sunny to promote the
site's dark mode is just too perfect to not mention.

------
sfuller808
I find it interesting that for every article on HN about the power of
Microservices there are 10 more discussing the complexity and difficulty of
getting them to work sustain-ably. What _is_ the best usage pattern of
Microservices?

------
AzzieElbab
microservices are event loops with network boundaries. a gateway to serverless
and maximizing your cloud provider profitability

