News for hackers. Stuff that matters.
Re:Meta’s Microservice Architecture [pdf] by RicDan on Tuesday July 11, 2023 @12:19PM (#36683180)
So you have to take care of routing etc.

I see how it works, and I completely agree that to start out, so going from PoC to first business implementation, a monolith is the way to go (unless the goal from the start is 100 million concurrent users I guess).

But after that initial phase, does it really matter if you use one or the other? You can overengineer both and make them a timesink, or you can keep both simple. I do agree on things like network latency adding up, but being able to completely isolate business logic seems like a nice gain. But Im also not talking about real micro level (i.e. auth login and registration being different services), but more macro (i.e. security is one, printing another(pdf,csv,word etc), BI another one

Re:Meta’s Microservice Architecture [pdf] by fvdessen on Tuesday July 11, 2023 @12:44PM (#36683574)
Interestingly Meta went with a django monolith for their new app and their goal was definitely in the order of 100 million concurrent users.
Re:Meta’s Microservice Architecture [pdf] by RicDan on Wednesday July 12, 2023 @03:08AM (#36691309)
Which is perfectly fine - 100 million concurrent users aren't the same for app x and app y, as the business logic the backend run isn't also the same.

Not saying it can't handle everything as well. Just saying the modularity of microservices makes it, in my pov, easier to handle large complex real time systems.

Maybe that's also something that comes with experience - as a rather "newish" guy (professional SE, so one level above Jr), it makes it easier to work on our project.

Re:Meta’s Microservice Architecture [pdf] by philjohn on Wednesday July 19, 2023 @11:46AM (#36788312)
That's just for the interface layer though.
Re:Meta’s Microservice Architecture [pdf] by charcircuit on Tuesday July 11, 2023 @12:50PM (#36683682)
>So you have to take care of routing etc.

The routing of just load balancing is much simpler than the routing of exectution jumping between many microservices.

>You can overengineer both and make them a timesink

I agree, but a microservice architecture starts you out at a higher complexity.

>but being able to completely isolate business logic seems like a nice gain

That can also be done by having that business logic live in its own library.

Re:Meta’s Microservice Architecture [pdf] by RicDan on Wednesday July 12, 2023 @03:11AM (#36691326)
> The routing of just load balancing is much simpler than the routing of exectution jumping between many microservices

Not necessarily at all, i.e. using GRPC it's all self discovered.

> I agree, but a microservice architecture starts you out at a higher complexity.

Definitely

> That can also be done by having that business logic live in its own library.

That's true, having it in it's own library is certainly a possibility -> but then it's also not that far off micro/macro services anyway, except you deploy it as one piece. And basically this is my argument: If you're having it all as libraries, and you all work in a mono repo anyway, the only real difference between micro/mono is the deployment, and that with micro you _could_ independently scale up whatever the current bottleneck is, which we've used plenty of times