31–40 of 134 posts
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.
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…
I don't need another process. I can use a thread. 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 u…
Earlier quoted context omitted.
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…
so why do you need this to be distributed and why can you not use a monolithic server application, perhaps with background threads?
... which perhaps just shifts the question to "why do you need multiple independent teams and not just use a monolithic development team?"
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?
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"
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…
Earlier quoted context omitted.
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…
so why do you need this to be distributed and why can you not use a monolithic server application, perhaps with background threads?