Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A huge benefit to modules is that they are small! This means means that you have releases that are faster per module, build times that are faster per module, code that can be more easily reasoned about.

The earlier you have modular architecture built into your stack, the easier it is to continue on that path, once you're monolithic, it's a huge amount of work to go back the other way.



Have you considered what will happen when you're application has reached a muti-gig deployment? Where you have static resources commingled with business logic? Where you have rendering blended with DB access?

Modular systems are theoretically as good as SOA or microservices, but in practice they are not.

Failure can not be isolataed as easily, when there is a problem in the system, the entire thing crashes.

Also to your point; is that a single repo, or multi-repo source control system? In a single repo system your build and testing cycle becomes longer and longer for the entire service, regardless he size of changes, you have to deploy the entire thing. Every successful business with a monolithic deployment, regardless of repo structure, ends up in the same place (based on my experience): a large unwieldy beast, maintained by dozens or hundreds, or thousands of engineers, who each have limited knowledge of the runtime. It becomes slow, hard to deploy, hard to test, hard to make changes.

Microservices/SOA does not alleviate the need to good design, but it doesn't allow for the above to be true on a perservice basis, shortening turnaround for response to issues and deploying new features, it is better.


Holy crap!

How do you get multi-gb deployments? I mean at some point I suppose anything is possible but I'm used to binaries on my system being KB or low MB.


That qualifies as a microsservice in my book :)

To add more: you get there by not practicing SOA, never breaking up a service, working at a company constantly ships new product rather than focusing on restructuring the application, not having developers own both the build and deployment of the app such that they don't experience the pain; reasons, etc.


Come on, you can have million lines of code and still get binaries of few megabytes. If that counts as microservice then everything does.

This is a frequent problem when discussing microservices - nobody defines how large they actually are.


Size is not the only reason, sometimes it's about performance and system utlization.

Separation of concerns tends to be my strongest indicator for defining service boundaries.


Rumor has it that eBay had to switch to 64-bit architectures because their binary exceeded 4GB in size.

So... apparently it happens.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: