4 ms·

> But the problem with microservices is that there is nothing to prevent you from creating these types of potentially incompatible dependencies. Sure, it's tot

> But the problem with microservices is that there is nothing to prevent you from creating these types of potentially incompatible dependencies. Sure, it's totally a matter of idiom - this is why I stated that a big problem with microservices is people jumping into it thinking it's SOA. Microservices, as a discipline, requires some care. It could be argued that the care required is too high to be worth it though. > If you are separating functionality using functions, the compiler helps you spot problems. If using classes or libraries, the linker can help spot problems. Maybe you could be more specific? I don't see how a compiler will help prevent coupling of modules/ internal components. What problems are you referring to? I agree about microservices being an idea without an obvious implementation - that's a fair criticism.

speedplane 7y ago
>> If you are separating functionality using functions, the compiler helps you spot problems. > Maybe you could be more specific? I don't see how a compiler will help prevent coupling of modules/ internal components. A super simple but effective way compilers prevent bad behavior is by preventing circular includes/imports. In a programming language, if module A imports module B, then module B can't easily import module A.* The compiler/interpreter will complain about circular/infinite imports. This general rule motivates developers to organize their code hierarchically, from high level abstractions down to lower level, and militates against inter-dependencies. In contrast, there's nothing to stop microservice A from contacting microservice B, which in turn contacts back to microservice A. It's so easy to do, that many will do it without even realizing it. If you're developing microservice B, you may not even know that microservice A is using it. Designed correctly, microservices can be another great way to separate functionality. The problem is actually designing them correctly, and keeping that design enforced. * Sure, there are ways of effectively doing circular imports in programming languages, but they usually require some active choice by the developer. It's hard to do it by accident.

speedplane 7y ago

>> If you are separating functionality using functions, the compiler helps you spot problems. > Maybe you could be more specific? I don't see how a compiler will help prevent coupling of modules/ internal components. A super simple but effective way compilers prevent bad behavior is by preventing circular includes/imports. In a programming language, if module A imports module B, then module B can't easily import module A.* The compiler/interpreter will complain about circular/infinite imports. This general rule motivates developers to organize their code hierarchically, from high level abstractions down to lower level, and militates against inter-dependencies. In contrast, there's nothing to stop microservice A from contacting microservice B, which in turn contacts back to microservice A. It's so easy to do, that many will do it without even realizing it. If you're developing microservice B, you may not even know that microservice A is using it. Designed correctly, microservices can be another great way to separate functionality. The problem is actually designing them correctly, and keeping that design enforced. * Sure, there are ways of effectively doing circular imports in programming languages, but they usually require some active choice by the developer. It's hard to do it by accident.