A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled. Plus if you use something like nanomsg you can keep the services on the same host, and use something like ipc:// for minimal latency, then just switch the protocol and move the service to a new host with no other changes when it's time to scale up.
No matter how good your concurrency primitives, you cannot escape the network. Yes, I know, Erlang is awesome and has excellent distribution and concurrency capabilities out of the box, but you cannot write all the things in Erlang, nor should you want to. Different languages/services have to talk to each other somehow and at some point.
A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled.
It can be much harder. Let's say that you have a zipcode<->address conversion library and you're deciding whether to use it within the web stack (option A) or to create an additional service with a REST API on a separate machine (option B). Microservices!
Option A means that it scales with your web stack. If you have 5 application servers today behind a load balancer and your load doubles then tomorrow you will need 10.
Option B means an entirely new set of servers. Not only do you still need those 5 application servers, you need an entirely new server for handling zipcode<->address translation. Let's say it's maxed out.
What happens when your load doubles then?
Well, you'll still need to scale up those 5 application servers running behind a load balancer, but you ALSO need an entirely new load balancer and two servers behind it for the zipcode<->address translation service.
Different languages/services have to talk to each other somehow and at some point.
This doesn't mean that you need for them to talk over a network layer.
I don't see why would you need to have a load balancer for the zipcode service; if the service truly scales linearly with the number of application servers, you can simply tie them together 1-on-1 with simple configuration.
Comments
A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled. Plus if you use something like nanomsg you can keep the services on the same host, and use something like ipc:// for minimal latency, then just switch the protocol and move the service to a new host with no other changes when it's time to scale up.
No matter how good your concurrency primitives, you cannot escape the network. Yes, I know, Erlang is awesome and has excellent distribution and concurrency capabilities out of the box, but you cannot write all the things in Erlang, nor should you want to. Different languages/services have to talk to each other somehow and at some point.
It can be much harder. Let's say that you have a zipcode<->address conversion library and you're deciding whether to use it within the web stack (option A) or to create an additional service with a REST API on a separate machine (option B). Microservices!
Option A means that it scales with your web stack. If you have 5 application servers today behind a load balancer and your load doubles then tomorrow you will need 10.
Option B means an entirely new set of servers. Not only do you still need those 5 application servers, you need an entirely new server for handling zipcode<->address translation. Let's say it's maxed out.
What happens when your load doubles then?
Well, you'll still need to scale up those 5 application servers running behind a load balancer, but you ALSO need an entirely new load balancer and two servers behind it for the zipcode<->address translation service.
This doesn't mean that you need for them to talk over a network layer.
I don't see why would you need to have a load balancer for the zipcode service; if the service truly scales linearly with the number of application servers, you can simply tie them together 1-on-1 with simple configuration.
What, so one extra zipcode server for every application server?
Or N-to-1. You still don't need load balancing, if it truly scales linearly, just configuration.