4 ms·

Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like runni

by cjfd 5y ago

Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.

jayd16 5y ago
So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
- imwillofficial 5y ago
  I didn’t read any of that. I read it as more tools in the toolbox.
  - jayd16 5y ago
    Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?
    - imwillofficial 5y ago
      Right, you’re taking it as a suggestion, as in a positive nudge to single instance monolithism. However, I read it as merely making GP aware of other options that are on the table.
- cjfd 5y ago
  Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
  - jayd16 5y ago
    >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
    - ratww 5y ago
      Running a single instance doesn’t mean not having a backup.

by cjfd 5y ago

jayd16 5y ago

So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?

imwillofficial 5y ago
I didn’t read any of that. I read it as more tools in the toolbox.
- jayd16 5y ago
  Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?
  - imwillofficial 5y ago
    Right, you’re taking it as a suggestion, as in a positive nudge to single instance monolithism. However, I read it as merely making GP aware of other options that are on the table.
cjfd 5y ago
Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
- jayd16 5y ago
  >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
  - ratww 5y ago
    Running a single instance doesn’t mean not having a backup.