3 ms·

I find that small, separate, decoupled services make for easier, more complete testing. Designs like that also tend to minimize race conditions. Multi-thread al

I find that small, separate, decoupled services make for easier, more complete testing. Designs like that also tend to minimize race conditions. Multi-thread all you like if there are no races! I haven't heard anyone talking about new, safe ways to do threading to avoid those problems. Nor have I heard anyone talking about how to constrain individual parts of a monolith so that it can be reasoned about in any way other than a big ball of goo with potentially magical behaviors. I'm also somewhat concerned that GraphQL is becoming the new monolith. Or at the very least, the new single point of failure. So . . . I, for one, don't think "balance" is moving back to more tightly coupled code. And I worry that we don't know where to go from here so we'll revert to yesterday's problems (new again!).

tracker1 3y ago
Don't use static variables and shared state in service code and you won't have race conditions. Use rpc, cqrs or a number of other service oriented approaches. Go, as an example tends to embrace an approach that scales well and doesn't have the issues you mention. Of course properly using mutexes and locking can help, so can serially shared state where state is mutated by a single process with request/response. Or you can use something like Nude, where there's only a single language execution thread. Most can leverage an RDBMS as the source of truth for state. Tighter coupling doesn't mean ignoring ways to reduce certain risks and complexity. A more monolithic code base doesn't have to be muddy. As to the smaller services, what happens when you have literally hundreds of smaller services to orchestrate? Is that really reasonable for an application that will never have even a million users? It comes down to balance and simplicity over complexity. Micro services don't remove complexity, they only shift it. And if the same people are responsible it becomes more to try to reason with.

tracker1 3y ago

Don't use static variables and shared state in service code and you won't have race conditions. Use rpc, cqrs or a number of other service oriented approaches. Go, as an example tends to embrace an approach that scales well and doesn't have the issues you mention. Of course properly using mutexes and locking can help, so can serially shared state where state is mutated by a single process with request/response. Or you can use something like Nude, where there's only a single language execution thread. Most can leverage an RDBMS as the source of truth for state. Tighter coupling doesn't mean ignoring ways to reduce certain risks and complexity. A more monolithic code base doesn't have to be muddy. As to the smaller services, what happens when you have literally hundreds of smaller services to orchestrate? Is that really reasonable for an application that will never have even a million users? It comes down to balance and simplicity over complexity. Micro services don't remove complexity, they only shift it. And if the same people are responsible it becomes more to try to reason with.