why does everything have to be microservice oriented and what's wrong with a simple monlithic application that runs the whole thing?
also, when are those ice cream machines going to get fixed?
also, when are those ice cream machines going to get fixed?
Thread: https://threadreaderapp.com/thread/1597983918900510720.html
Go (and now Rust) is really only used for very low level services with a high SLA (Like Infrastructure). Almost all business logic is Ruby + Rails.
I don’t think any other company could do that.
I’d hate to get that AWS bandwidth bill.
It's a bit like saying Magento served 1M rps on Black Friday leaving out the small but important detail that each individual store has separate infrastructure and manageable load.
Divide and conquer works, congrats to the Shopify team that their design decisions worked out for their use case. And obviously some parts of the system are still shared but my guess is that they are not part of the monolith.
Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.
If the teams you are talking about never heard of threads and only know about microservices, then there is something seriously wrong with their CS education. Maybe they all were hired via leetcode. That could explain it.
I'm not confounding anything. Distributed programming has its applications and uses, but if you don't have a good reason to use it, then don't, and use a thread in a single process for background processing.
What makes it a service soup is the soup of services on the other side of the queue processor. If those components weren't services, the application would be a monolith.
Anyway, there many reasons to organize your code on services, and McDonalds is large enough for them to be perfectly valid. But if you take a closer look, those components on the article aren't the ones that do anything, they are just new queue processors that may or may not finally deliver your messages to the destination. That's an irksome architecture.
The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build)
As to why "microservices" versus a few "normal" sized services
I'm not sure why it's always "monolith" or "microservices"
POST /lock
This is only a slight exaggeration over some of the stuff I've seen people try to pull.
You need to lock when you write a shared area from multiple sources with no opinion on write ordering.
But say your pipeline is client-> decorator -> processor -> observer with client publication -> external partner, each input will go into a set of instances different from the previous and next one, and rejoin at the output who will queue and order them. You have parallel heavy work and sequential light result publication. Your simple output must be as fast as the sum of your parallel routes to minimize queueing.
Ofc it s more complex, and I prefer 0 network hop myself, but I work on a large investment bank micro service system and we do not lock, and the component are both simple and complex enough that when one disappear, everything else waits or rebalances, and when it reappears it can catch up automatically, and go on. It consumes large amount of memory to keep a duplicated state in each component and persistence is not guaranteed to be on time (in fact, our persistence layer was 30 minutes behind by mid day, for years, until we dug into the 30yo sql)
... which perhaps just shifts the question to "why do you need multiple independent teams and not just use a monolithic development team?"
Hopefully by redundancies, you dont mean sharing data access logic