4 ms·

> They are not better than modules. They are. You don't control your runtime environment with modules, nor your deployment. You create problems due to the need

> They are not better than modules. They are. You don't control your runtime environment with modules, nor your deployment. You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem. You are unable to pick and choose what technologies you use. Etc etc etc. With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that.

naasking 4y ago
> You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem. These problems still exist with microservices, you just don't see the problems at build time but in failures at runtime. You yourself admitted this in your last paragraph: > With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that. So basically you've moved code problems into infrastructure problems, and eliminated standardized build and testing pipelines in favour of a free-for-all/not-my-problem. And if you think microservices are special in some way, I could also say "with modules you just tell everyone where to download the package, the interface and documentation is bundled with it, and leave everyone else to link to it and use it how they see fit". The only real difference is that the module is guaranteed to work according to the interface specification you're expecting because this is enforced by the language. Not so with deploying runtime services. Edit: I also don't understand this at all: > You don't control your runtime environment with modules, nor your deployment. Why would you need to control your runtime or deployment with modules? The language already specifies the semantics of modules' runtime behaviour and their linking requirements, and the standard build process is deployment.

naasking 4y ago

> You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem. These problems still exist with microservices, you just don't see the problems at build time but in failures at runtime. You yourself admitted this in your last paragraph: > With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that. So basically you've moved code problems into infrastructure problems, and eliminated standardized build and testing pipelines in favour of a free-for-all/not-my-problem. And if you think microservices are special in some way, I could also say "with modules you just tell everyone where to download the package, the interface and documentation is bundled with it, and leave everyone else to link to it and use it how they see fit". The only real difference is that the module is guaranteed to work according to the interface specification you're expecting because this is enforced by the language. Not so with deploying runtime services. Edit: I also don't understand this at all: > You don't control your runtime environment with modules, nor your deployment. Why would you need to control your runtime or deployment with modules? The language already specifies the semantics of modules' runtime behaviour and their linking requirements, and the standard build process is deployment.