3 ms·
It's a lot about trusting your infrastructure, your development process, your overall plan with respect to state and communication etc. If you need to make it m
by vintermann 3y ago
It's a lot about trusting your infrastructure, your development process, your overall plan with respect to state and communication etc. If you need to make it more complicated later, can you? Probably. If you see you could have done something simpler, can you de-complicate it? Sounds harder to me in general.
- doctor_eval 3y agoProbably not your point but > If you see you could have done something simpler, can you de-complicate it? this is why I think microservices are generally better - because they increase the friction to create coupling, and coupling creates complexity, and in particular makes it very difficult to de-complicate things. Put another way, microservices make coupling far more obvious, and the presence of strong coupling in a microservice architecture should be a massive red flag - one that's really easy to miss in a monolith. The unfortunate thing about participating in these exchanges, however, is that it's impossible to explain ourselves in sufficient detail, so in the monolith vs microservice debate, we all end up just speaking across each other.
- vintermann 3y agoNo, I see your point. It's just that in my experience, the friction didn't do much to prevent coupling, because the friction was just that you had to write a lot of boilerplate code - not hard, just boring - and they were willing to do that rather than having a design meeting with me...