Scalability, Elasticity and Agility in Cloud Computing

Previously, we said that cloud computing is, underneath the marketing, just the delivery of computing services over the internet.

Gone are the days when you would have needed physical servers sitting in an overheated cupboard. Previously, you would have had to maintain that local infrastructure yourself and employ specialist staff to keep everything running.

Cloud computing is a shift of that responsibility to the provider. That shift sounds administrative, but it does change what your systems can do. This article is about three of those changes, and three words that get used very loosely: scalability, elasticity and agility.

They do overlap a bit, and beginners can mix them up, so it is worth taking them one at a time.

Scalability

One of the biggest advantages of cloud computing is scalability.

Scalability means a system can grow or shrink depending on demand.

Imagine you have an online shop. On a normal day, the website may only need a modest amount of computing power. But during a major sale, the number of visitors might suddenly increase. If your system cannot handle that extra demand, the website becomes slow or stops working, usually at the exact moment you most wanted it to stay up.

Scaling helps solve that problem. There are two main ways to do it:

vertical scaling
horizontal scaling

Vertical scaling means changing the size or power of an existing resource. For example, you might give a server more CPU, more memory, or faster storage. If you make the resource more powerful, you are scaling up. If you reduce its power, you are scaling down.

Horizontal scaling means changing the number of resources. Instead of making one machine more powerful, you add more machines, or more instances of an application running alongside each other. If you add resources, you are scaling out. If you remove them, you are scaling in.

%%{init: { "flowchart": { "htmlLabels": true, "nodeSpacing": 55, "rankSpacing": 65 } }}%% flowchart LR subgraph V["Vertical scaling"] direction TB V1["Start with one server"] V2["Make the same server bigger"] V3["Add more CPU, memory, or storage"] VS1["Small server"] VS2["Larger server"] V1 --> V2 V2 --> V3 V3 --> VS1 VS1 --> VS2 end subgraph H["Horizontal scaling"] direction TB H1["Start with one server"] H2["Add more servers alongside it"] H3["Share the work between them"] HA["Server A"] HB["Server B"] HC["Server C"] H1 --> H2 H2 --> H3 H3 --> HA H3 --> HB H3 --> HC end V1 ~~~ H1 V2 ~~~ H2 V3 ~~~ H3 classDef card fill:#F1F5F9,color:#111827,stroke:#CBD5E1,stroke-width:1px classDef server fill:#FFFFFF,color:#111827,stroke:#64748B,stroke-width:1px classDef invisible stroke:transparent,stroke-width:0px,color:transparent class V1,V2,V3,H1,H2,H3 card class VS1,VS2,HA,HB,HC server linkStyle 9 stroke:transparent,stroke-width:0px linkStyle 10 stroke:transparent,stroke-width:0px linkStyle 11 stroke:transparent,stroke-width:0px %% cc-caption: Vertical scaling means making one existing server more powerful. Horizontal scaling means adding more servers and sharing the work between them.

Both approaches are useful, but they solve the problem in different ways. A simple way to think about it is this:

Vertical scaling makes the existing thing stronger, while horizontal scaling adds more things

Animated GIF showing a large robot labeled “Vertical Scaling,” followed by multiple smaller robots popping into view one by one to illustrate “Horizontal Scaling.”

Which one you reach for depends on the workload.

Vertical scaling is often the easier change to make, because nothing about the shape of your system changes. The same machine simply has more to work with.

For example, if a database is running slowly because it does not have enough memory, moving it to a machine with more RAM may allow it to keep more data in memory and respond faster.

But there is a ceiling. At some point you cannot buy a bigger single machine, and even before that point the cost of the very largest machines starts to climb faster than the extra power you get back. A server that is twice as powerful is not always twice the price. It may be three, four, or ten times the price, especially at the high end.

Horizontal scaling avoids that ceiling by adding more machines instead of making one machine bigger. This is useful when the work can be split across many servers. A common example is a website or web application. If one server can handle 1,000 visitors, then several servers behind a load balancer can handle far more. Each incoming request can be sent to whichever server is free, and no single server has to carry the whole load.

Horizontal scaling is also useful for reliability. If a vertically scaled system depends on one large machine and that machine fails, the whole service may go down. With horizontal scaling, failure can be less dramatic. If one server fails, traffic can be routed to the remaining servers. The system may slow down, but it does not necessarily stop.

There is also a practical cost advantage. Many smaller machines can be cheaper and more flexible than one very large machine. You can add capacity gradually as demand grows, rather than making a large upfront bet on a single oversized server. This fits especially well with cloud computing, where servers can be created and removed on demand.

The trade-off is that horizontal scaling asks more of your application. The work has to be something that several machines can share safely. That is straightforward for a stateless web front end, but much less straightforward for something like a single large database, where many machines may need to coordinate reads and writes to the same data.

Elasticity

Elasticity is closely related to scalability, but it focuses more on automatic change.

A system is elastic when it can scale dynamically as demand changes.

Think about a streaming service. Usage might be lower in the early morning, then much higher in the evening. It would be wasteful to run the maximum amount of infrastructure all day if people only need it for a few hours in the evening.

With elasticity, the system can add resources when demand increases and remove them when demand drops, without someone watching a dashboard and adjusting things by hand. You set the rules for when to scale, and the platform acts on them.

This is the difference that tends to get lost. Scalability is a property: the system can change size. Elasticity is about that change happening on its own, in response to what is actually going on, rather than because you remembered to log in. A system can be scalable without being elastic. Plenty of older systems could be made bigger, but only slowly, and only by hand.

Elasticity is also one of the reasons cloud computing can be cost-effective, though we will not really do that idea justice until the article on consumption-based pricing, which is coming up shortly.

The short version is that you are not forced to permanently pay for capacity you only need occasionally. If it is configured well, the system grows and shrinks roughly in step with the work it is being asked to do, and the bill follows. That last part only holds if the scaling-in actually happens, which is worth checking rather than assuming.

--- config: themeVariables: xyChart: plotColorPalette: "#CBD5E1, #111827" --- xychart-beta title "Demand and allocated capacity over a day" x-axis "Time of day" ["00:00", "02:00", "04:00", "06:00", "08:00", "10:00", "12:00", "14:00", "16:00", "18:00", "20:00", "22:00", "24:00"] y-axis "Relative demand and capacity" 0 --> 100 line "Demand" [22, 16, 12, 18, 30, 38, 45, 52, 66, 84, 94, 58, 32] line "Allocated capacity" [26, 22, 20, 22, 34, 42, 50, 58, 72, 90, 98, 64, 38] %% cc-caption: The pale line shows demand rising through the day and peaking in the evening. The darker line shows allocated capacity following that pattern, increasing ahead of the evening peak and scaling back overnight.

Agility

Agility is about speed.

In traditional on-premises environments, getting new infrastructure can take a long time. A company may need to order hardware, wait for it to arrive, install it, configure it, connect it to the network, and only then make it available to the team. That process can take days, weeks, or even months.

In the cloud, resources can often be created in minutes. Sometimes seconds.

This gives teams much more freedom to experiment and adapt. If a developer needs a test environment, they do not necessarily need to wait for a physical server to be ordered and racked. If a company wants to try a new idea, it can create the resources quickly and remove them later if they turn out not to be needed.

That is agility in a cloud context. It does not really mean moving quickly for the sake of it. It means reducing the delay between having an idea and being able to act on it. When standing up an environment takes ten minutes rather than ten weeks, you are far more willing to try something that might not work, because the cost of being wrong is small. For a lot of businesses, that change in what feels affordable to attempt matters more than any single technical feature.

Why these three sit together

It is tempting to treat scalability, elasticity and agility as three items on a list, but they describe one shift from slightly different angles. Scalability is the system being able to change size. Elasticity is that change happening automatically in response to demand. Agility is how quickly any of it can happen in the first place, including the creation and removal of whole environments.

%%{init: { "flowchart": { "htmlLabels": true, "nodeSpacing": 45, "rankSpacing": 55 } }}%% flowchart LR subgraph E[" "] direction TB E0["ELASTICITY"] E1["Responds to temporary rises and falls in demand"] E2["Resources can increase or decrease as needed"] E3["Useful for variable traffic, seasonal peaks, or short bursts"] E4["Focuses on matching capacity to current usage"] end subgraph S[" "] direction TB S0["SCALABILITY"] S1["Supports longer-term growth in workload"] S2["Resources are expanded as demand becomes larger"] S3["Useful when users, data, or activity keep increasing"] S4["Focuses on making the system able to handle more over time"] end subgraph A[" "] direction TB A0["AGILITY"] A1["Helps teams move quickly from idea to working service"] A2["Resources can be created without waiting for hardware"] A3["Useful for experiments, new projects, and rapid changes"] A4["Focuses on speed, flexibility, and faster delivery"] end E0 ~~~ E1 E1 ~~~ E2 E2 ~~~ E3 E3 ~~~ E4 S0 ~~~ S1 S1 ~~~ S2 S2 ~~~ S3 S3 ~~~ S4 A0 ~~~ A1 A1 ~~~ A2 A2 ~~~ A3 A3 ~~~ A4 E0 ~~~ S0 S0 ~~~ A0 E1 ~~~ S1 S1 ~~~ A1 E2 ~~~ S2 S2 ~~~ A2 E3 ~~~ S3 S3 ~~~ A3 E4 ~~~ S4 S4 ~~~ A4 classDef header fill:#F59E0B,color:#FFFFFF,stroke:#F59E0B,stroke-width:2px classDef card fill:#F1F5F9,color:#111827,stroke:#E2E8F0,stroke-width:1px class E0,S0,A0 header class E1,E2,E3,E4,S1,S2,S3,S4,A1,A2,A3,A4 card

None of this makes the cloud automatically cheaper or automatically better. A system that can scale out can also scale out into a surprising bill if nobody set sensible limits. The point is that these capabilities exist and are quick to use, which is genuinely different from the world of ordering hardware and hoping you guessed the demand correctly. Most of the rest of this series is, in one way or another, about using that difference sensibly rather than just enthusiastically.