
Ask HN: How to convince my team that microservices are not a good idea to us? - mxh_ht
Two months ago I’ve started to work on a startup as a developer. This startup has a SaaS product and ~3000 users. The code behind the product is not as good as it could be: There’s some design flaws and a lot of depreciated dependencies…  hard to test, hard to maintain, etc. Despite that, fix all the flaws would require a lot less effort than recreate from scratch.<p>With that in mind the team have decided last year(before I’ve joined) that they are going to change from the monolithic architecture we have today to a microservice architecture.<p>At first sight I had no problem with that but in the last month I’ve done some research about microservices. Now I believe that microservice is a horrible idea in our case.<p>I’m not going into details of why I think microservices is a bad idea, this is not the point here. The point I need some guidance is: How should I approach this question?<p>I tried to start a discussion about it with some people of the team, then I discovery that there’s a really strong confirmation bias in favor of microservices around there. Their arguments were just some common sense that I could easily refute. But just an informal talk with everyone had no result, just some more common sense.<p>I’m thinking about write a document with all my arguments and some facts to send it to the team. Would this be a good approach? I&#x27;m really new in the startup environment and I don’t know how everyone else solve this kind of problem.<p>Any suggestion would be nice. Thanks.<p>PS: The team is just 4 developers + CTO.
======
lastofus
Instead of arguing against microservices, it would be better to ask the team
to plan out solutions to the hard problems associated with microservices,
namely the hard problems associated with distributed systems.

Things like:

* How will transactions across multiple services be handled, and as a followup, how will rollbacks happen when an error happens mid-transaction

* When all the data is distributed across multiple service DBs, how consistency be enforced? What happens when data is no longer consistent (e.g. data in one DB references data in another DB that is no longer there, or has been updated)?

* [basically, how will anything related to ACID be handled when you no longer have a single ACID DB?]

* How will errors be handled with various permutations of individual services being unavailable? If a single service going down brings down the site, has anything really been gained?

* How will distributed logging be done such that bugs can be tracked down in production. How will a given single request be tracked across services?

* How will automated tests be written when everything is now a network call instead of a function call? Mocking out all the things gets old fast and introduces its own set of problems relating to testing code that isn't the actual production code.

* How will API versioning be handled for each service, especially if different services are being built in silos by different developers?

If they have solutions for things like this, great! If not, perhaps they
should before pushing forward.

~~~
MrGando
I can't agree more with this approach. These are usually the things people
selling micro services overlook. Also, I think in general questioning how to
address the hard challenges with a given framework/architecture/infrastructure
is the path that leads to more sustainable progress.

------
deepaksurti
If you pitch it directly to the team who have (most likely) done their own
homework about moving to micro services, that it is not a good decision, even
though your point could be valid, may not be well taken as it can
subconsciously be interpreted as you being non-consensus driven/jumping to
conclusions.

Why not: 1. Draft an email with a subject 'Second opinion on moving to micro
services 2. Let the email body be a very succinct description that a. you have
done some research, b. you respect the team's decision but c. would like their
opinion on your research. Also seek a time for a 30 minute presentation and 30
minute feedback/discussion. Don't send your document with the email, keep that
for your presentation. That way you will be seen in positive light, as a team
member with his own opinions but also a team player.

Also, have you asked them what was the data from their research that made them
take the decision to move to micro services?

------
brudgers
You don't. You've had your say. People listened and the consensus was to
continue pursuing micro-services. That's pretty much how teams work as teams.

Good luck.

------
sheepmullet
Do you have a lot of equity? Do the other developers?

Most likely the developers want to learn about microservices.

It's honestly one of the main reasons people join startups - to work with cool
new tech/approaches.

If they wanted to take the low risk approach they would work at a big company.

If this is the case expect nothing but friction.

------
jon-wood
I've made almost exactly this move from big ball of mud to micro services with
a similar sized team.

Overall I think it was a net positive, but only because the velocity hit from
working on the big legacy application is worse than the hit from working with
smaller distributed services which all need managing. That's a very real
overhead - you're now managing dependencies and deployment for n services
rather than 1, and realistically the big application you're trying to move
away from isn't going anywhere soon. We've got an API routing layer which
purely exists to allow migrating individual endpoints to new services while
allowing the legacy platform to continue serving everything else.

------
exception_e
Maybe it's not a bad idea in the long run. I would have a meeting with the
team and talk about "stages":

1) Start to split out monolith in separate packages ("services")

2) Use RabbitMQ to "talk" between the services / Simply have one package that
is the REST portion and reference the other packages inside of it (which
aren't REST... just libraries, basically)

3) Patch up design flaws

4) Slowly move towards true microservices

Step 2 would be deploying everything as monolith but at least it's split up.

This gradual approach may just work for your team!

------
anaganisk
Since you say it's just four developer, why not have a coffee with 2 team
members, individually and talk to them about what you think, I see you know
your stuff so I don't need to help you there? You dont have to convince all of
them of you can convince a part of your team, you can standup. You can atleast
have a brainstorming session with a few "educated" ones on your side.

------
murukesh_s
One option would be to delay the migration and instead persuade the team to
fic the flaws and improve quality.

Put a list of objectives the team want from the product. Prove that you can
achieve that without using microservices.

------
the_arun
What is the Target state you want to see(not how, what?)?

------
Sevii
Why don't you start with persuading one of the other developers to your side?

