A scalability plan is a document that describes all the different components of your application and the necessary steps to scale the application as soon as it is needed. The scalability plan is a live document, so you need to review it and keep it updated frequently.
There is no master template ready to fill as the scalability plan is more an internal document with all the information you need to make the right decision about the scalability of your app. Our recommendation is to use the scalability plan as your guide, including all the contents of your capacity plan, you can even add how to hire new workers to this document.
Some of the sections you can have in your scalability plan can be the following ones:
- An overview of the application and its components
- Comparison of cloud providers or places where you will deploy your application
- Resume of your capacity plan and theoretical limits of the application
- Scalability phases or steps
- Provisioning times and costs
- Organization scalability steps
The preceding sections are only a suggestion, feel free to add or remove any section to fit in your business plan.
Here's an overview of some sections of the capacity plan. Imagine that we have our example microservices application ready and want to start scaling from the minimum resources available. First, we can describe the different elements we have in our application as a basic inventory from which we evolve our application:
- Battle microservice
- NGINX
- PHP 7 fpm
- Location microservice
- NGINX
- PHP 7 fpm
- Secret microservice
- NGNIX
- PHP 7 fpm
- User microservice
- NGINX
- PHP 7 fpm
- Data storage layer
- Database: Percona
As you can see, we have described each component needed for our application, and we have started sharing the data layer between all the microservices. We didn’t add any cache layer; also, we didn’t add any autodiscovery and telemetry service (we will add extra features in the following steps).
Once we have our minimum requirements, let’s take a look at the different steps we can have in our scalability plan.
In this step, we will have all our requirements in one machine even though it is not production ready yet because your application cannot survive an issue in your machine. A single server with the following characteristics will be enough:
- 8 GB RAM
- 500 GB disk
The base OS will be RHEL or CentOS, with the following software installed:
- NGINX with multiple vhosts setup
- Git
- Percona
- PHP 7 fpm
In this step, the provisioning time can be a few hours. We not only need to spin up the server, but also need to set up each one of the required services (NGINX, Percona, and others). Using tools such as Ansible can help us with the quick and repeatable provisioning.
At this point you are getting the application ready for production, choosing between VM or containers (in our case, we have decided to use containers for flexibility and performance), splitting the single server configuration into multiple servers dedicated to each service required, like our previous requirements, and adding autodiscovery and telemetry services.
You can find a small description of the architecture of our application at this step:
- Autodiscovery
- Hashicorp Consul container with ContainerPilot
- Telemetry
- Prometheus container with ContainerPilot
- Battle microservice
- NGINX container with ContainerPilot
- PHP 7 fpm container with ContainerPilot
- Location microservice
- NGINX container with ContainerPilot
- PHP 7 fpm container with ContainerPilot
- Secret microservice
- NGINX container with ContainerPilot
- PHP 7 fpm container with ContainerPilot
- User microservice
- NGINX container with ContainerPilot
- PHP 7 fpm container with ContainerPilot
- Data storage layer
- Database: Percona container with ContainerPilot
The provisioning time in this step will be reduced from hours, like the preceding step, to minutes. We have an autodiscovery service (HashiCorp Consul) in place and, thanks to ContainerPilot, each of our different components will register itself in the autodiscovery register and it will auto setup. In a few minutes, we can have all the containers provisioned and set up.
In this step of your scalability planning, you will be adding cache layers to all the application microservices to reduce the number of requests and improve the overall performance. To improve the performance, we decided to use Redis as our cache engine, so you need to create a Redis container on each microservice. The provisioning time for this step will be like the previous one but measured in minutes.
In this step, you will be moving the storage layer to each microservice, adding three Percona containers in Master-Slave mode with automatic setup with ContainerPilot and Consul.
The provisioning time for this step will be like the previous one, measured in minutes.
In this step of the scalability plan you will be studying the load and usage patterns of the application. You will add load balancers in front of the NGINX containers to have more flexibility. Thanks to this new layer, we can do A/B testing or Blue/Green deployments, among other features. Some interesting and open source tools you can use in this case are Fabio Proxy and Traefik.
The provisioning time for this step will be like the previous one, measured in minutes.
At this final step you will be checking again the application infrastructure to keep it up to date and scaling up and horizontally when necessary.
The provisioning time for this step will be like the previous one, measured in minutes.
As we told you before, the scalability plan is a live document, so you need to revise it frequently. Imagine that a new database software is created in a few months and it is optimal for high loads; you can review your scalability plan and introduce this new database in your infrastructure. Feel free to add all the information you consider important for the scalability of your application.