So far, we have seen some different server setups and scaling concepts. In this section, we are going to explain how to incrementally scale a production application.
This server is usually used in development and low-traffic production applications. It starts with all the components in the same server:
Figure 7: Single server setup
This is the simplest setup possible, where everything (database, webserver, or an application) is on the same server.
The next step is to add an additional application instance to be able to perform zero-downtime upgrades. This way, we can roll the application updates one instance at a time, without taking the site down for maintenance.
Figure 8: Multiple app instances in one server
For managing the two application instances, we are using Nginx as a load balancer and reverse proxy. We are also serving static files directly from Nginx without touching NodeJS for better performance. Notice that the number of app instances are given by the number of CPUs available in the server (two CPUs in our case). This is vertical scaling, since we increased the performance of the server (two CPUs) while keeping everything in one server.
As the number of users starts to grow, the database and application instances start fighting for the server's resources. At this point, we need to have each service in its own server as that makes more sense.
Figure 9: Horizontal scaling with multiple servers
The following are the guidelines for splitting up the services into multiple servers:
- Instead of serving static files with Nginx, delegate static files to different servers or services such as CDNs and Amazon S3. CDNs have the advantage of being distributed data centers on multiple locations (closer to the user).
- Split the database's instances to its own servers in a primary/secondary setup. There you can scale up or down to many database replicas as needed.
- Add a load balancer so that you can scale up or down with app servers as needed.
Micro-services (specialization of Service Oriented Architecture) aim to divide (monolithic) applications into small and independent processes that communicate through an API. This way, we can scale each one as needed. Let's imagine that the setup in phase two is for the store. When we need to add new features into the same code base, we should consider adding them as a separate service, as it makes more sense:
Figure 10: Micro-service architecture
Each one of the micro services can be deployed independently, and scaled up or down following the description in previous phases.