Scalability is the ability of a system to be able to support increased processing/traffic by increasing a system's resources (scaling up) or increasing the number of systems supporting the process (scaling out). To be scalable, the relationship between resources and supported processing needs to be linear. A system has poor scalability if it takes four times as many resources to support a 50% increase in the number of users. Some systems are not scalable because of bad or limited architecture. No matter the number of resources added, you will not get an improvement (or may even experience decreased support).
Elasticity is the ability to scale up/down and out/in as a response to the processing needs of the system. For example:
- A shipping company may need to increase resources during a holiday season, then reduce them after the holiday.
- A stock trading site may be very active during trading hours, but have very little traffic outside of exchange hours.
Because of elasticity, a company no longer has to maintain support for peak use at all times. Companies can improve user experience by increasing resources at peak usage, and reduce costs by reducing resources when they are no longer needed.
There are cloud offerings that include elasticity with no effort from the consumer. You will simply see changes in cost based on use. Other products require your input. In these cases, elasticity does include some automation to complete the task of adding/removing resources. Performing such steps manually would be prohibitive in many scenarios. However, the decision to increase/decrease resources does not necessarily need to be automated. This can be a complex decision, and the ROI of automating the decision needs to be considered.
Elasticity assumes scalability, but it is not a hard requirement. If a system has poor scalability, you can still scale to support traffic. However, the ROI will be terrible.
See the definition of elasticity from AWS and Azure below.