5 ms·
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
by solmag 5y ago
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
- cjfd 5y agoThings 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 agoSo you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
- imwillofficial 5y agoI didn’t read any of that. I read it as more tools in the toolbox.
- jayd16 5y agoWithout 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 agoRight, 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 agoNot 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.
- wongarsu 5y agoPlenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir
- foobarian 5y agoSplitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.
- Sebb767 5y ago> Splitting a system into microservices can help individual teams be better stewards of their part of the system. Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.
- yakshaving_jgt 5y agoGiven your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
- foobarian 5y ago> There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.