In the previous subchapter, we saw that traditionally, offering a service on the internet meant buying and maintaining physical servers. It worked, but it had some very specific headaches. The cloud was born to solve them. Let’s look at them one by one with real examples.

To set up your service, you needed to buy the servers before having a single customer.

Real example: A startup wants to launch an online store. It estimates it will need 10 servers. Each one costs €5,000. Before selling anything, it has already spent €50,000. If the business doesn’t work out, that money is almost lost.

This initial expense on physical goods is called CapEx (Capital Expenditure). The cloud turns it into OpEx (Operational Expenditure): you pay small monthly amounts for what you use, like an electricity bill.

You had to decide how many servers to buy without knowing how many people would come. There were only two outcomes, and both are bad:

• You fall short: lots of people arrive, the servers get overloaded, and the website crashes. You lose sales just when demand is highest.
• You overdo it: you buy too many “just in case” and most of the time those expensive servers are running doing nothing.

Real example: A concert ticket sales website has normal traffic all year, but the day tickets for a famous artist go on sale it gets 100 times more visits for one hour. Do you buy 100 times more servers to use them for one hour a year? Or do you let the website crash that day?

The cloud solves this with elasticity: you add capacity in minutes when needed and remove it when it’s not, paying only for the hours you used it.

Buying and installing physical servers took weeks or months: requesting quotes, waiting for delivery, assembling, cabling, installing the operating system, configuring the network…

Real example: Your boss asks you for a new server to test an idea. In a traditional datacenter, it could take 6 weeks to have it ready. In the cloud, you have it running in 2 minutes from a web page.

The cloud turns a weeks-long task into a minutes-long one. That allows for cheap and fast experimentation.

Physical servers break: hard drives fail, power supplies die, fans get stuck. Someone had to:

• Be on call 24/7.
• Keep spare parts in stock.
• Physically replace broken hardware.

All that costs money and specialized personnel. In the cloud, the provider takes care of the hardware. If a physical disk fails, it’s AWS’s problem, not yours.

If your datacenter is in Madrid, a user in Japan will notice the website is slow because their data has to cross half the planet. Setting up your own datacenter in Japan would be extremely expensive.

Real example: A Spanish company wants to sell in Latin America. Instead of building a datacenter in Mexico, it rents servers in the AWS region closest to its customers and serves them quickly from there. It does this in minutes, without traveling or building anything.

The cloud offers global presence: you have datacenters available in dozens of countries ready to use.

What happens if your server room floods, there’s a fire, or a prolonged power outage? With a single datacenter, you lose everything. Having a second backup datacenter was extremely expensive.

The cloud allows you, affordably, to replicate your data and systems in multiple locations so that if one fails, another keeps running.

• The cloud didn’t invent the internet; it solved the economic and operational problems of having your own servers.
• The two key ideas are pay-as-you-go (no upfront investment) and elasticity (you pay only for what you use, when you use it).
• It also brings speed, global reach, and resilience at an affordable cost.

In the next subchapter, we’ll compare the three major deployment models: on-premise, cloud, and hybrid, so you know when each one is appropriate.