Scalability : Think in Terms Of TCO
Scalability : Think in Terms Of TCO
With appropriate scaling and best practices, the impact of a scaleable architecture can be minimal.
Join the DZone community and get the full member experience.Join For Free
A system that has the ability to easily scale resources to meet the increasing workload without affecting the performance is known as a scalable system. The workload could refer to anything from an increase in users, storage, or a number of transactions.
To make an easy-to-scale system, it is crucial to have an evolutionary way of thinking about the software development cycle. An architect should focus on designing a scalable software architecture from the early phase of the product life cycle.
Why? Because it will impact the Total Cost of Ownership (TCO) of your software in a big way. A late-stage consideration of improving scalability requires rewriting a big chunk of application code. Think of regression issues.
This blog provides vantage points to understand the best practices in achieving ease of scalability and a checklist on scalability that architects can copy and bring to the business meetings where requirements/efforts are being discussed.
Before you look at the checklist (which you can do by scrolling down), you must understand the kind of scalability that we are talking about. Let’s peep into client requirements that you will be required to scale for.
Understanding the Kind of Scalability You Need
First, let’s talk about the popular version of scalability — dynamic scalability. A dynamically scalable system has the ability to handle an extra load by scaling within a minute or no notice.
Think of Uber. If your app shows some error during peak booking hours, you expect that if you close the app and open it again, the problem should be gone. A dynamically scalable system should be able to handle loads at that speed.
Or, think of Netflix. The load on their servers increases substantially during weekends. So, their systems should be able to distribute and respond to the extra load during weekends dynamically.
In enterprise applications, the scalability requirements are not so desperate or fast changing. Yet you might be required to design dynamically scalable modules. For example, think of a CRM or a salary processing system during a month-end scenario. In these systems, simultaneous access by users or the number of transactions can increase drastically during month-ends. Sometimes up to 10x the average load. You will need to design these systems for a sudden rise in performance requirement.
Typically, in an enterprise application space, scalability becomes important at a later stage in the software’s life cycle when the number of users, transactions, or the memory records increase considerably, and the performance bottlenecks start appearing in the usage of the application regularly. Whether you will hit the bottleneck in six months or three years depends on how fast the business grows.
This means enterprise applications architects must pay close attention to design patterns which will impact the ease of scaling of the application in the future. At the same time, dynamic scaling is an overkill.
To understand how you can do that, you should understand two types of scaling — vertical and horizontal.
Vertical scaling is also commonly referred to as “scaling up” in many instances. When you scale a system vertically you increase the power of the current system. This can mean greater memory, faster storage, or more advanced processors. It is the more convenient between the two methods since a very little configuration is required at the software level.
For handling a month-end load, consider a vertically scaled set up.
Horizontal scaling is also known as “scaling out,” where you increase the number of servers to balance the load across multiple systems. In this one, software adopts to scalability not by adding powerful hardware but by spreading the workload across new set-ups. Nevertheless, scaling out comes with the price where it adds more complexity to the system. Moreover, having multiple servers require general administrative tasks such as security, monitoring, data, and backups.
Consider horizontal scaling when current average performance hits a dead-end.
Best Practices to Build a Scalable System
One last topic before we craft the checklist. Let’s first look at some of the best practices that architects use for designing easy to scale systems.
- Loose coupling: Building loosely coupled code enables an application to scale much faster with less cost. In such a design, the bottlenecks can be easily recognized. You can increase the capacity of one component without disturbing the overall application. In addition, you are not haunted by regression issues when you undertake to scale.
- Asynchronous components: It is important to carefully analyze the application design to determine whether to keep components synchronous or asynchronous. Building asynchronous components makes scaling easy.
- Cache: While designing a scalable system it is important to offload the database as much as possible. Cache helps to achieve this objective especially for retrieving information from the database in read-only mode. It is advisable to use in-memory cache rather than on-disk cache or relational database.
- High Cohesion: A strong cohesion amid subsystems results in less round excursions since classes are logically grouped and reside in the same tiers. This can greatly reduce local and remote calls to complete a logical operation. This makes scaling easy.
- Decentralization: A distributed system is a group of subsystems operating on independent servers. This ensures ease of high availability by increasing the number of servers.
- Position: Important components should be kept as close as together. For instance, it is less cumbersome to go through the content delivery network than to go through a load balancer, web server, and database for content retrieval.
- Less network chatter: Design network as untalkative as possible since network communications tend to be slower as compared to in-memory ones.
- One resource, one function: Make sure one resource caters to one function in case of multiple requests for the same resource. If you don’t do this, then, despite scaling the system, you will be bogged down by slow performance.
Finally, now, what are the points you must keep in mind when undertaking a new application development project? We have prepared this short checklist which we feel is absolutely important for architects when it comes to ease of scalability.
This checklist will help make that scalability has been thoroughly discussed during business requirement gathering.
- Have you considered month-end scenarios?
- How much will the load increase during month-ends or any other periodic business cycle?
- Are there any directly stated scalability requirements from the client?
- What is the estimated increase in the number of users or transactions in the next 6 months, 1 year, 2 years?
- Have you calculated the increase in storage requirement in the next 6 months, 1 year, and 2 years?
- Have you figured out processes which should be made asynchronous?
- Have considered all options to increase software performance?
- Is your design optimized for frequent and crucial tasks?
- Have you figured how often the system should use a cache?
- Do you have a distributed system in place?
- Do you have load balancing software in place?
- Is the database scalable?
- Are you making sure the developers are strictly following the single responsibility principle?
- Does your code review guideline, include the single responsibility principle, as an important check?
- Can you simulate peak loads in test cases? Has the testing team considered test-cases with 5X or 10X increase in transaction/user load?
Have we missed anything? Are there any more critical points which should be included in this checklist? Write to us in the comments below
Opinions expressed by DZone contributors are their own.