Maybe I'm dumb, but doesn't splitting up a web application into micro services have many other benefits such as modularity, constraining complexity, code reuse etc.?
You can get those with a straight library without introducing the complexity of message-passing, RPCs, and distributed systems.
(I'm a big fan of SOAs/microservices for companies that operate at Google-scale. Most companies do not, and for the rest of us - plain old libraries are very underrated. You can always slap an RPC layer or message broker on top of a library's API, but there's no reason to pay that cost until you need to. The real reason to break things up into microservices is when you run out of RAM on the box, or alternatively when you want better cache hit rates by focusing the processor on a small amount of code. You typically don't get there until you're serving thousands of QPS against a data set in the terabytes.)
Modularity: No. Your headache in creating a system of micro services will just be that much greater if you don't have modular code. I wouldn't call that a benefit even if it does end up with you writing more modular code.
Constraining complexity: It actually makes complexity worse (what do you do when microservice A goes down? times out? returns data you can't deserialize? takes too long?). These things you do not have to worry about if you are not doing any inter process or inter-server communication.
Bingo! It's extra funny when someone that dislikes distributed systems is pro SOA. How do SOA advocates not realize they are signing up for distributed systems? If you think keeping business logic decoupled is hard, try keeping network logic decoupled, oh and that unreliability thing, too.
Comments
Maybe I'm dumb, but doesn't splitting up a web application into micro services have many other benefits such as modularity, constraining complexity, code reuse etc.?
You can get those with a straight library without introducing the complexity of message-passing, RPCs, and distributed systems.
(I'm a big fan of SOAs/microservices for companies that operate at Google-scale. Most companies do not, and for the rest of us - plain old libraries are very underrated. You can always slap an RPC layer or message broker on top of a library's API, but there's no reason to pay that cost until you need to. The real reason to break things up into microservices is when you run out of RAM on the box, or alternatively when you want better cache hit rates by focusing the processor on a small amount of code. You typically don't get there until you're serving thousands of QPS against a data set in the terabytes.)
Modularity: No. Your headache in creating a system of micro services will just be that much greater if you don't have modular code. I wouldn't call that a benefit even if it does end up with you writing more modular code.
Constraining complexity: It actually makes complexity worse (what do you do when microservice A goes down? times out? returns data you can't deserialize? takes too long?). These things you do not have to worry about if you are not doing any inter process or inter-server communication.
Code reuse: No. Why would it help code reuse?
Additionally....
https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
Bingo! It's extra funny when someone that dislikes distributed systems is pro SOA. How do SOA advocates not realize they are signing up for distributed systems? If you think keeping business logic decoupled is hard, try keeping network logic decoupled, oh and that unreliability thing, too.