
How to Start Using Microservices - savovaleks
https://hackernoon.com/how-to-start-using-microservices-0e1z3u47
======
marcus_holmes
This is complete bullshit, top to bottom.

Microservices add complexity, they don't remove it.

Monolithic architecture doesn't force tight coupling. Tight coupling doesn't
depend on an architecture. Making a monolith crash-proof is easier than
dealing with intermittently-functioning microservices.

Being able to change microservices without that affecting any other services
is a design goal, not an architectural feature.

Microservices are not inherently more scalable than monoliths. They have to be
designed that way. And monoliths can equally well be designed to be scalable
(just add more instances!).

When to use microservices? When one part of your monolith can easily be broken
out and run on its own server as a service, and that would improve some
performance bottleneck that you need because you can see a point where it will
matter in the near future. Otherwise "never".

~~~
com2kid
Microservices can solve a lot of organizational problems:

1\. Fewer merge conflicts, easier branching/merging strategy. If you have 200
people checking into a monolith then it is easy to start stomping all over
each other.

2\. Large changes(say upgrading to a new major version of a library for
security reasons) can result in the code base being in a state of conflict
hell, or just frozen, while work gets done. With microservices you can upgrade
them one at a time.

3\. The build/test/deploy pipeline for any given team is shorter. Large code
bases take a long time to build and run through tests. If instead everyone has
to have well defined interfaces to their microservices then it is possible to
test the interface points of a given microservice that is being committed to.

4\. Serious screw-ups in one part of the code don't impact code in other
places. If someone starts leaking memory in one microservice, then one part of
the system has degraded functionality. Worst case it is a critical
microservice and your system goes down. Best case it isn't on the golden path
for users and it isn't a major outage.

5\. It makes you think about deployment and configuration up front. I have
seen _major_ systems (billions of dollars, systems you've used in the past)
where only tribal knowledge of how to "get it running" existed. There was no
formal deployment plan, and deployments could take days.

Microservices force organizations to solve deployment up front.

~~~
bszupnick
I've worked on a large-scale micro-service architecture and I had a great
time! I don't "pick a side" of this almost idealistic argument, but I do have
some pushback for you:

1) You're right that there aren't merge conflicts, but you swap out merge
conflicts with interface changes. Meaning let's say programmer A is working on
Microservice B that consumes from Microservice C and she changes the "what I
expect from Microservice C" interface. Who changes Microservice C? In THEORY
it could be whoever "owns" it, or Programmer A, but in practice sometimes it
falls between the cracks.

2/4) We ended up actually writing our own Python packages that did end up
being shared amongst some of the microservices. If you want to abide by DRY
(not juts as dogma but you just don't want to implement the same thing twice),
you do need some shared code. Maybe that "breaks" the microservice "model" and
we didn't do it "right"? Maybe. But with what we did, we still did have
"internal Python package" updates intended for one Microservice that effected
another

This is all from my personal experience so it could be that we just didn't
follow best practices or fell into some traps.

~~~
jeffbee
You don't change interfaces. It is that simple. There's not a paradox here.

To change your RPC protocol in a distributed system, you may add optional
fields to the request but you must not add required fields nor change the
semantic meaning of any field. You can add new services and methods but you
must not disable one that anyone calls.

~~~
marcus_holmes
Which is surely an argument for "never start a project using microservices"?

Who knows exactly what their interfaces are going to be, across their entire
project, on day 1, and gets that right every time?

~~~
com2kid
> Who knows exactly what their interfaces are going to be, across their entire
> project, on day 1, and gets that right every time?

Same problem exists for binary interfaces, or source code interfaces.

Or for a client system that talks to a cloud service.

Or for a cloud service that exposes APIs for other cloud services to call.

Technologies exist to version APIs. It is sad that JSON is the standard
interchange format, since it is pretty miserable at this entire problem.

~~~
marcus_holmes
I agree completely, but all this is exacerbated if you have to make your
interfaces immutable from the first version

~~~
jeffbee
They aren't immutable. You can safely add fields and you can add methods or
entire services. It is easy to change microservice interfaces, you just do it
in a particular way.

------
jimbokun
How to Start Using Microservices:

1\. Write a monolith.

2\. If the project fails or doesn't really need to scale in terms of code or
hardware, you don't need microservices.

3\. If the project succeeds, and the code size and team size starts to grow,
start looking for parts of the monolith that make sense to encapsulate as
their own services.

3a. Also look to see if some parts of the monolith need to scale more than
others. This can also indicate part of the code to break out into its own
microservice.

4\. Now that you have identified potential microservices, very carefully think
through the API for each microservice. APIs are very difficult to change after
they are widely used, so its important to get it as close to right as possible
the first time. API design does not lend itself to "agile" very well.

5\. Now you are ready to create your "two pizza" teams and start implementing
your microservices.

6\. Don't bother thinking about Kubernetes too much before this point. Until
you really need to scale, it just adds unnecessary complexity. (But when you
need it, you really need it!)

6a. Same may or may not be true for Docker, it can potentially simplify
deployments, but if what you have works and isn't creating significant toil,
you can always introduce it later.

~~~
rand_r
For 3, I would say organize your code into modules as a first step, and make
sure you get the dependencies between them flowing in the right direction.

You can do a lot with module separation and a good dependency tree within a
single repo before actually requiring microservices.

------
sonnyp
An interesting thing to do here is to ask who wrote this and why?

> Microtica is abstracting complex cloud setup and automation on AWS

[https://microtica.com/](https://microtica.com/)

Microservices aren't necessarily a bad idea but keep in mind that the company
behind this article has an incentive to encourage developers to build complex
systems.

~~~
Maria_micro
Hi sonnyp, This is Maria from Microtica. We want to bring the cloud setup and
automation (which can be complex for someone new to it) closer to developers,
but not encouraging microservices over monolith or any other technology or
framework. It’s up to them to choose. The article is meant for developers that
want and need to build with microservices.

~~~
sonnyp
Thank you for clarifying. Then I would suggest rephrasing the following
sentence

> Microservices are an alternative to the monolith approach that gives
> developers the flexibility, scalability, and simplicity they need to build
> complex software applications.

------
crispyambulance
I don't understand these impulsive "don't do it" reactions.

Why can't folks just assess their own situations, review/learn about possible
solutions, try stuff out and then eventually go with something?

There's going to be unpleasant problems no matter what you choose. There's no
silver bullet. Projects fail for many different reasons, only one of them is
because of wrong "technology platform choice."

~~~
foobiekr
At least my personal feeling from having watched multiple projects arrive at
hundreds of microservices, some of which end up amplifying inbound requests
into a nearly exponential number of internal requests, the problem is that
most teams have no thesis at all for when it makes sense to separate two
functions, when you should make a function a service, etc. this means you get
a massive amplification of cost and complexity and, honestly, not a lot of
gain most of the time.

------
rutthenut
Three steps:

1\. Don't do microservices

2\. Don't do microservices yet

3\. Do some larger, more sensible, level of service integration

------
lykr0n
> the freedom to choose the technology stack they prefer best

Might be the worst possible reasons to adopt Microservices. If your Account
Management service runs in a different language then your Email service, then
guess what? You now need to hire different developers to maintain each
service.

Don't. Do do it for this reason, or any reason until your business demands
them.

~~~
lolsal
That mantra is less about using arbitrary programing languages and more about
using something like redis (or some other niche/useful/existing tech) instead
of recreating the wheel in python/java/node/whatever.

~~~
lykr0n
That doesn't require a microservice to do.

If you're breaking an app apart so one part can use redis, you have something
seriously wrong in your engineering culture.

~~~
lolsal
You are right of course - my example sucks. I'm trying to think of a more
appropriate example, but my heart is not in it.

~~~
lykr0n
lol it's all good.

------
NicoJuicy
Microservices aren't easy. But I do suggest reading up on domain driven
design.

~~~
savovaleks
We have a blog post about Domain Driven Design also:
[https://microtica.com/the-concept-of-domain-driven-design-
ex...](https://microtica.com/the-concept-of-domain-driven-design-explained/)

------
tjchear
@ Facebook engineers: to my knowledge, Facebook still adopts a monolith
architecture for their servers. How do you deal with regression in one area
potentially bringing down the whole system?

~~~
jeffffff
never worked at facebook but the answer is 1) testing 2) rolling/canary/blue-
green deploys 3) feature flags 4) having a rollback plan

------
mementomori
Microservices is for scaling applications that need to handle a high volume of
transactions (millions+) with the expectation of high growth in transaction
volume. It became a solution for Uber and Netflix when the exploding user
requests caused their monoliths to become difficult to manage/modify/deploy.
An application that handles hundreds to thousands of transactions doesn't
necessarily have the problem that requires the microservices solution. The
main tradeoff of microservices is that it increases the complexity of
software, and has a lot of moving parts that need to be done right to achieve
the advantage. The hype of encourage every to-do app creator to use
microservices may be an overkill. The writer of the post does have the
incentive to encourage the use of microservices and the utilization of their
services.

~~~
Maria_micro
I agree with your statement, and the post explains the pros, but also the
challenges of microservices. Our service does not depend on the project
architecture, it can run with microservices, monoliths and hybrid systems just
the same. It’s in our best interest to support all variates :)

------
unnouinceput
I love microservices. Why? Because when customer is left in the wind with a
myriad of small problems, due to previous developer(s) making a simple big
problem into a complex array of microservices, they then pay big bucks to me
for solving. What I usually do is integrate them back into the monolith they
should've been to begin with.

Consequently there are customers left in wind with a tiny problem on their
monolith that could've been easily solved if the original architect would've
split it in 3 or 4 parts, which I usually do at the time.

I love hypes and I love the culture HN is spreading in developers world. It
means a lot of code needs me to fix it and as a freelancer I make sure to get
the big money while posing as the God's gift to them clueless clients.

------
greenie_beans
microservices have made my life hell because we just blindly followed the herd
and didn't really know what we were doing. now we have 300 lambda functions
for a team of 6 !!!

~~~
jeffbee
If you don't know what you are doing, your life is going to be Hell
regardless.

------
mamon
Adopting Microservices in two steps:

1\. Don't do it

2\. Don't do it yet

