Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You want microservices, but do you need them?

docker.com

Post reply on HN
Print view View original

41–50 of 151 posts

Re: You want microservices, but do you need them?

#41

Post by echelon »

stoneman24 wrote: post #16

I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been chosen and the new shiny tech has people entranced. What we do (physics simulation software) doesn’t need all the complexity (in my option as a long time software developer & tester) and software engineering knowledge that splitting stuff into micro services re…

If you have workloads with different shapes, microservices make sense.

If not, do the monolith thing as long as you can.

But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices.

If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith.

If your microservice is as thin as leftpad.js and hosts only one RPC call, maybe don't do that. But if you need to carve out a thumbnailing service or authC/authZ service, that's a good boundary.

There is no "one size fits all" prescription here.

Re: You want microservices, but do you need them?

#43

Post by yowlingcat »

mjr00 wrote: post #25

I feel like this has been beaten to death and this article isn't saying much new. As usual the answer is somewhere in the middle (what the article calls "miniservices"). Ultimately 1. Full-on microservices, i.e. one independent lambda per request type, is a good idea pretty much never. It's a meme that caught on because a few engineers at Netflix did it as a joke that nobody else was in on 2. Full-on monolith, i.e. e…

I see a lot of value in spinning up microservices where the database is global across all services (and not inside the service) but I struggle more to see the value of separate core transactional databases for separate services unless/until the point where two separate parts of the organizations are almost two separate companies that cannot operate as a single org/single company. You lose data integrity, joining ability, one coherent state of the world, etc.

The main time I can see this making sense is when the data access patterns are so different in scale and frequency that they're optimizing for different things that cause resource contention, but even then, my question would become do you really need a separate instance of the same kind of DB inside the service, or do you need another global replica/a new instance of a new but different kind of DB (for example Clickhouse if you've been running Postgres and now need efficient OLAP on large columnar data).

Once you get to this scale, I can see the idea of cell-based architecture [1] making sense -- but even at this point, you're really looking at a multi-dimensionally sharded global persistence store where each cell is functionally isolated for a single slice of routing space. This makes me question the value of microservices with state bound to the service writ large and I can't really think of a good use case for it.

[1] https://docs.aws.amazon.com/wellarchitected/latest/reducing-...

Re: You want microservices, but do you need them?

#44

Post by scuff3d »

The other problem is that very very few people actually know how to design a microservice based architecture. I've worked with half a dozen different teams who claim they're building microservices, but when you look at the system it's just a giant distributed monolith. Most of them are people who worked in legacy code bases, and while they like the idea of microservices, they can't let go of those design patterns. So they do the exact same thing but just out everything behind network calls. Drives me absolutely fucking nuts

Re: You want microservices, but do you need them?

#48

Post by AJRF »

Another good use case for a microservice - if you are going to have to change the compute size for your monolith just to accommodate the new functionality.

I had an architect bemoan the suggestion we use a microservice, until he had to begrudgingly back down when he was told that the function we were talking about (Running a CLIP model) would mean attaching a GPU to every task instance.

Re: You want microservices, but do you need them?

#49

Post by stackskipton »

cyberax wrote: post #34
LaurensBER wrote: post #19

Earlier quoted context omitted.

> What I want is a lightweight infrastructure for macro-services. I want something to handle the user and machine-to-machine authentication (and maybe authorization). > I don't WANT the usual K8s virtual network for that, just an easy-to-use module inside the service itself. K8s makes sense if you have a dedicated team (or atleast engineer) and if you really need need the advanced stuff (blue/green deployments, scali…

I tried to use K8s several times, and I just can't make it work. It's fine as a deployment platform, but I just can't justify its complexity for local development. We're using Docker/Podman with docker-compose for local development, and I can spin up our entire stack in seconds locally. I can attach a debugger to any component, or pull it out of the Docker and just run it inside my IDE. I even have an optional local…

I wouldn't use K8s for local development unless you have some system where there is a dev cluster and you can route traffic for particular pod to your local workstation.

Docker Compose for local development is fine. If your K8s setup is crazy complex that you need to test it locally, please stop.

Re: You want microservices, but do you need them?

#50

Post by asdfman123 »

davnicwil wrote: post #31
honkycat wrote: post #3

The one thing I would like to preserve from microservices is stuff about database table hygiene. Large, shared database tables have been a huge issue in the last few jobs that I have had, and they are incredibly labor intensive to fix.

In my experience basically everything being good in software is downstream of good data modelling. It's partly why I've realised more over time that learning computer science fundamentals actually ends up being super valuable. I'm not talking about anything particularly deep either, just the very fundamentals you might come across in year one or two of a degree. It sort of hooks back in over time as you discover that…

I learned this early and as a result I'm the guy who's trying to clean up other people's crap while they ship features and get promoted
Post reply on HN