Why write components running on it's own process

Transcript

1. 1 process running on 1 server
2. this is a process, it uses resources like: 1. cpu 2. memory 3. network bandwidth 4. network/disk io
3. requests grows, the process uses more resources, at certain time the process exhaust all this server resources
4. when this happen, find the bottleneck in the process
5. take the bottleneck part out to a new process on a new server rpc calls
6. requests grows more, you find out that the process is still the bottleneck, which means resources it is using grows faster rpc calls
7. then put the same process on more servers, so each of them use fewer resources rpc calls
8. continue find out which part of the process eating resources faster, adding more servers, splitting out more components
9. finally you find out: 1. any scalable system is composed with different type of components 2. which running as process on different servers 3. which connect each other through network with rpc calls
10. It is inevitable to do between process/computer communications for handling more requests
11. between processes communication means network rpc calls
12. although it adds overhead and complicity when doing rpc, but in order to scale to more computers, it has to be done
13. already known between process communications: 1. nginx <=> your app 2. your app <=> mysql database 3. your app <=> redis So it is natural to put nginx in one server, and mysql into another server
14. So. instead of writing one bloated process, which can not scale, Let’s build smaller component that do one kind of thing well, standalone as process, and can talk to outside with it’s open interfaces. this could bring: 1. smaller isolated codebase 2. easier to grasp, understand 3. easier to maintain 4. easier to test 5. more importantly it brings scalability, and high availability
15. we could unify the interfaces rpc call definition with protocol buffers and gRPC for example. (OK.. this is an AD for gRPC)