Understanding Scaling in Software Engineering
Every time a user is added to the Software application a load is increased in the system. This is a common requirement in every software application and is considered a Non-Functional System Requirement i.e., a software application should accommodate the incoming loads and should behave normally. Suppose a transactional system is running. New users are being registered regularly.
With each new user, comes new transactions. New transactions mean more calling to internal and external services. More read and write operations. More database operations, more procedures calling, and more requests and responses to the end-user. Hence more and more load on the system.
To have the system function normally, a software system can be either vertically scaled or horizontally scaled. This depends upon the software architecture which requires careful planning and studying of the requirements and the existing infrastructure.
In this post, we shall see both ways how software can be scaled.
In the vertical scaling strategy, there is only one instance of the software application. This instance is responsible for every software action. But how do cope with the increasing workload? This is done by increasing the resources of the system. Do you want more memory? Add more RAM. If you want more storage, add more hard drives. Need more compute power? Add in more cores to accommodate for the needed computing power.
Problems with Vertical Scaling Strategy
The issue with the vertical scaling strategy is:
- The reliability of the system remains the same no matter how many resources your add in. This is because the instance of the system is only one. Hence if one instance goes down the whole system becomes unavailable.
- Adding more and more resources to the system is costly. Suppose you have peak work times only during nights. If you increased the resources on the system, they would not be utilized until the system gains load.
- When adding more and more resources, downtime has to be planned for the system.
- Lastly, the system cannot be scaled beyond the limit. There is always a hardware limitation as to how much a system can be scaled. Every machine has a threshold for RAM and storage.
In a horizontal scaling strategy, a single system is broken down into multiple instances of the same systems. In Horizontal scaling, more and more nodes of the same system are configured and brought to life. Incoming requests are directed to the nodes and the load is shared. Suppose you have a system that accepts user requests and produces a response. As the load increases, another instance of the application is added. Hence the load is divided into two systems. If now workload further increases, another instance of the system is added, dividing the load among three systems.
Horizontal scaling is complex to achieve but it is very cheap to achieve. Before we see the pros and cons of horizontal scaling, let’s first see how we bring the application instances up and down.
The horizontal scaling strategy gained popularity after the introduction of containerization technology. Containerization is a technology used to run instances of multiple systems on a single layer of the software system or operating system. Unlike Virtualization which is a costly way of running more than one operating system on the same machine, containerization does not need to have a whole operating system installed. Every application runs in its own secured and isolated space.
Every time a new instance is needed; a new container is started. There are templates that can bring up as many instances as needed. This operation completes within minutes. Now if the load comes down, excessive instances can be brought down as well.
Docker is one of the most widely used containerization technology. Docker comes with its registries as well as external repositories such as JFrog to provide ready-to-use Docker images.
Any software application has certain features. These features include reading and writing to databases and other resources. If we break the system into smaller chunks or services, we will have smaller and simpler systems. Now suppose you have a system for video streaming. You break the system into user registration and video streaming. Here users are not frequently coming in, hence user service can be lightweight. The video service is more in demand and hence can occupy more resources.
Which Scalping Strategy is For You?
Depending upon your application, you have to come up with a scaling strategy. Some strategies can work for one use case but not for others. Below we list the goods and bads of horizontal scaling:
- Horizontal Scaling is cheaper than vertical scaling since the resources are not increased significantly, rather the workload is distributed.
- Horizontal Scaling ensures that as soon as the peak times are over, left-over instances are brought down saving cost and money.
- Horizontal Scaling is light on your pocket but comes with more complexity in terms of system design. One such complexity is how to design a database that maintains consistency in reading and writing operations by multiple nodes.
- Horizontal Scaling comes with lower downtime than Vertical Scaling.