Hacker News new | ask | show | jobs
by didip 406 days ago
Micro services show their benefits in a large organization.

It’s a tool to solve people issues. They can remove bureaucratic hurdles and allow devs to somewhat be autonomous again.

In a small startup, you really don’t gain much from them. Unless if the domain really necessitates them, eg. the company uses Elixir but all of the AI toolings are written in Python/Go.

3 comments

If your application has different load or resource requirements, you should build separate services, even in a startup.

You can put most of your crud and domain logic in a monolith, but if you have a GPU workload or something that has very different requirements - that should be its own thing. That pattern shouldn't result in 100 services to maintain, but probably only a few boundaries.

Bias for monolith for everything, but know when you need to carve something out as its own.

At scale, you're 100% correct.

microservices can also cause organizational dependencies and coordination that wouldn't otherwise be necessary. i've seen it create at least as many people issues as solve them. one seemingly innocuous example is the policy of 'everybody just uses whatever services they want', which can hugely increase the ongoing maintenance requirements and seems to require that everyone learn everything in order to be functional. which never happens, which means you're always chasing people down.
I probably just haven't checked these comment threads enough yet because I'm surprised I haven't seen this posted, but even though this is a bit old now, https://youtu.be/y8OnoxKotPQ, there is a reason it resonated with so many. It's spot on with the downsides microservices can inflict.

I've certainly seen microservices be a total disaster in large (and small) organizations. I think it's especially important that larger organizations have standards around cross-cutting concerns (e.g. authorization, logging, service-to-service communication, etc.) before they just should "OK, microservices, and go!"

One of those teams need to go.
If they're doing two very different things, why?
At a larger organization this could be, but there is nothing elixir could possibly be doing for the startup that go would not do.

Remember the whole topic here is avoiding this tax

I was starting from the assumption that Elixir does something they need, but yeah in most cases Golang would cover the same thing. Even then, you probably have separate Golang and Python, or just two separate Python services.