4 ms·

Modules aren't an alternative to microservices in a reasonable way though. And for all modules solve the modularization problem at the code level, they don't r

by TimPC 4y ago

Modules aren't an alternative to microservices in a reasonable way though. And for all modules solve the modularization problem at the code level, they don't really solve modularization at the service level. The main alternative to microservices is monoliths and for many applications I far prefer microservices to monoliths. I want modularization in how I scale my app, I don't want to spin up a whole bunch of servers that can serve almost any possible function in production. I'd prefer more delineated responsibilities. I don't think modularization solves this if after the modules you just throw all your modules in one big bucket and serve that up.

ebiester 4y ago
I think what is missing here is that it doesn't have to be an either-or at the organizational level. If you have a particular piece of the system that needs to be scaled, you can take that module out when it becomes necessary. You can alter your system such that you deploy the entire codebase but certain APIs are routed to certain boxes, and you can use batch processing patterns with a set of code outside the codebase. You can have an admin application and a user application, and both of them are monoliths. They may or may not communication using the database or events or APIs. However, you don't make this on the single bounded context guideline.
michaelsalim 4y ago
That's exactly what the comment you're replying is saying though. You're talking about scalability which they say modules doesn't exactly solve. And I do agree that most people need less of those than they think.
esailija 4y ago
Just because the monolith image contains all code doesnt mean each deployment needs to run all that code. Or even same version of the code. A deployment can run only a small portion of the code determined by deployment args. It can even run an older version than other deployments
- zbobet2012 4y ago
  That's just a microservice enabled by configuration.

by TimPC 4y ago

ebiester 4y ago

I think what is missing here is that it doesn't have to be an either-or at the organizational level. If you have a particular piece of the system that needs to be scaled, you can take that module out when it becomes necessary. You can alter your system such that you deploy the entire codebase but certain APIs are routed to certain boxes, and you can use batch processing patterns with a set of code outside the codebase. You can have an admin application and a user application, and both of them are monoliths. They may or may not communication using the database or events or APIs. However, you don't make this on the single bounded context guideline.

michaelsalim 4y ago

That's exactly what the comment you're replying is saying though. You're talking about scalability which they say modules doesn't exactly solve. And I do agree that most people need less of those than they think.

esailija 4y ago

Just because the monolith image contains all code doesnt mean each deployment needs to run all that code. Or even same version of the code. A deployment can run only a small portion of the code determined by deployment args. It can even run an older version than other deployments

zbobet2012 4y ago
That's just a microservice enabled by configuration.