Ask HN: How to convince my team that microservices are not a good idea to us? | Hacker News Reader

Ask HN: How to convince my team that microservices are not a good idea to us?

8 pointsmxh_ht11 comments

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.

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.

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.

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?

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.

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'm really new in the startup environment and I don’t know how everyone else solve this kind of problem.

Any suggestion would be nice. Thanks.

PS: The team is just 4 developers + CTO.

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.

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.

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?

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.

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.

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.

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!

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.

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.

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

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

Reply on news.ycombinator.com