21–30 of 134 posts
Earlier quoted context omitted.
Well, I mean really most of the micro service architectures are just monoliths with network calls between the components.
That's called distributed monolith. It's pretty much guaranteed to happen if the developers don't introduce a lot of redundancy while splitting up the services.
Hopefully by redundancies, you dont mean sharing data access logic
Anyway, I only skimmed the article, but I had a chuckle seeing the title of this article pop up on HN at all.
Earlier quoted context omitted.
Well, I mean really most of the micro service architectures are just monoliths with network calls between the components.
yeah, so what about locking? it must be a nightmare to make sure that the components all work together as intended...
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)
While this satisfies some idle curiosity, I don't really get what justifies spending the resources in posting such stuff. Is this a recruitment tactic somehow for such companies?
Can I get promoted to Manager if I get a degree in Hamburger-data-ology? From what I can tell the career path is into Corporate hell. https://www.uopeople.edu/blog/hamburger-education-inside-mcd...
While this satisfies some idle curiosity, I don't really get what justifies spending the resources in posting such stuff. Is this a recruitment tactic somehow for such companies?
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?
In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service. Unless you're confounding microservices w/ async architectures and saying to drop asynchronous pattern…
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.
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?
In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service. Unless you're confounding microservices w/ async architectures and saying to drop asynchronous pattern…
Earlier quoted context omitted.
yeah, so what about locking? it must be a nightmare to make sure that the components all work together as intended...
So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to create parallel routes. 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…
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?
To your point, Shopify's monolith was handling 1.27M requests/sec on Black Friday: https://twitter.com/ShopifyEng/status/1597983918900510720 Thread: https://threadreaderapp.com/thread/1597983918900510720.html
I’d hate to get that AWS bandwidth bill.