Cloud Computing: Your Code in the Sky

10:00:00 AM: The Booking Window Opens

Every day, the Indian Railways opens its Tatkal booking window for a class of train tickets at exactly 10:00 AM. In the seconds before that, all over the country, people are sitting with the IRCTC website or app open, refreshing the page, fingers hovering over the "Book Now" button — students heading home for a festival, families planning a wedding trip. The instant the clock ticks over to 10:00:00, an enormous burst of "book this seat" requests lands on the railway's computers within the same one or two seconds.

Now picture what would happen if IRCTC ran this entire booking system on a single desktop computer sitting in an office — the same kind of machine your school computer lab has, just a bit more powerful. That one machine has a fixed amount of processing power (its CPU), a fixed amount of working memory (its RAM), and a fixed-size network connection. It can only do a certain number of things per second. Beyond that limit, new requests have nowhere to go — they either wait in a growing queue, or the machine runs out of memory and crashes.

Yet booking portals like this survive their busiest minute of the day, every day. They do it by using cloud computing: instead of depending on one fixed machine, the system automatically borrows extra computing power from a huge, distant pool of computers the moment demand spikes, and hands that power back the moment it's no longer needed. Nothing about this is magic — it is a specific engineering idea, and by the end of this chapter you will be able to work out, with real numbers, exactly how many "extra computers" a system like this needs to borrow.

What One Computer Can (and Cannot) Do

To see why cloud computing exists, it helps to be precise about what a single computer is doing when you use a website or app. When you open the IRCTC app, your phone is the client — it sends a request over the internet asking, "Is seat 34 on train 12951 available?" Somewhere else, a server — a computer whose job is to listen for such requests and answer them — receives that request, checks its records, and sends back a reply. This request-and-reply pattern is called the client-server model, and it underlies almost every app you use: your phone (or laptop) is nearly always the client, and some computer you never see is the server.

What is actually running on that server is ordinary code — the same kind you might write yourself. Suppose a school's results portal, when it receives a request for a roll number, runs a function like this:

def get_result(roll_number):
    results = {
        "8A07": {"name": "Aditi Sharma", "marks": 91},
        "8A08": {"name": "Rohan Verma", "marks": 84},
    }
    if roll_number in results:
        return results[roll_number]
    return "Roll number not found"

print(get_result("8A07"))
print(get_result("8A19"))

Trace it: get_result("8A07") looks up "8A07" in the results dictionary, finds it, and returns the value stored there, so print(get_result("8A07")) outputs {'name': 'Aditi Sharma', 'marks': 91}. The second call, get_result("8A19"), checks the same dictionary, does not find "8A19" as a key, falls through to the final line, and returns the string "Roll number not found" — so print(get_result("8A19")) outputs Roll number not found. This is precisely the kind of program that "lives in the cloud": it sits on a server, waiting, and every time a student's browser sends a request, the server runs this function once and sends the returned value back. If forty students in Class 8A open the portal in the same minute, the server (or several servers, working together) runs get_result() roughly forty times in quick succession — one call per request.

A server, physically, is not fundamentally different from your own computer — it has a processor, memory, storage, and a network connection. The difference is only in scale and in job: it is built and configured to sit in a room and answer requests all day. But scale still has a limit. Suppose one modest server can process 500 booking requests every second — reading a request, checking the seat, and sending back a reply, 500 times in one second. That number, 500, is the server's capacity. On an ordinary afternoon, when only 200 people per second are checking train seats, one such server handles the load comfortably, with room to spare. But at 10:00:00 AM on a Tatkal morning, if 12,000 requests arrive in a single second, one server rated at 500 requests/second is hopelessly outmatched — it would need 24 times its own capacity to keep up.

Before cloud computing became common, an organisation solved this by buying more physical machines and installing them in its own building — this is called running things on-premise ("on-prem" for short). But that creates a new problem: you would have to buy and maintain 24 servers just to survive a spike that lasts a few minutes, and then watch 23 of those servers sit almost completely idle for the other 23 hours and 55 minutes of the day, still drawing electricity, still needing security updates, still ageing towards obsolescence. Buying for your peak moment wastes money every other moment; buying for your average moment means crashing during your peak moment. Cloud computing exists to resolve exactly this tension.

Renting Computers Instead of Owning Them

Cloud computing means using computing power — processing, memory, storage, networking — that belongs to someone else, housed in their buildings, and accessed by you over the internet, where you pay only for what you actually use, for as long as you use it. The "someone else" is a cloud provider — companies such as Amazon (through Amazon Web Services), Microsoft (Azure), and Google (Google Cloud) — and each one owns enormous buildings called data centers: warehouse-sized facilities packed with rack after rack of physical servers, cooling systems to stop the equipment from overheating, and backup power supplies. These buildings are real and geographically specific — for example, Amazon Web Services operates a data center region located in Mumbai, and Indian companies that want their servers to respond quickly to Indian users often choose to run their applications from there, because physical distance still affects how long a signal takes to travel.

When a school, a startup, or a government service like IRCTC "uses the cloud," what they are actually doing is renting a slice of computing capacity inside one of these data centers, rather than buying and housing physical machines themselves. This single shift — from owning hardware to renting capacity on demand — is what makes it possible to have 500 requests/second of capacity on a quiet afternoon and 12,000 requests/second of capacity for the two minutes that matter, without paying for 24 idle machines the rest of the time.

One Physical Machine, Many Virtual Ones

The mechanism that makes renting-by-the-minute possible is called virtualization. A single powerful physical server inside a data center can be divided, using special software called a hypervisor, into several independent virtual machines (VMs). Each virtual machine behaves, from the outside, exactly like its own separate computer — it has its own operating system, its own slice of processing power and memory, and its own storage — even though underneath, several virtual machines are sharing the same physical hardware.

Think of a physical server as an apartment building, and the hypervisor as the building's management office. The building itself has one shared foundation, one set of water pipes, and one electrical mains connection — but each flat inside it has its own front door, its own electricity meter, and its own lock. A tenant in Flat 3B cannot walk into Flat 3A's kitchen, and a power cut caused by Flat 3A's faulty wiring (in a well-built system) does not spill over and disable Flat 3B. Two completely unrelated organisations — say, a school's results portal and a small business's online store — can have virtual machines running on the very same physical server in a data center, fully isolated from each other, with neither one aware the other exists.

This is the technical trick that lets a cloud provider serve thousands of different customers off a comparatively small number of physical machines, and it is also what lets a single customer's application "grow" almost instantly: starting five new virtual machines on hardware the provider already owns takes seconds, whereas buying, delivering, and installing five new physical computers would take days or weeks.

The Elastic Server: Doing the Math

This ability to add and remove virtual machines automatically, in response to real-time demand, is called elasticity or auto-scaling, and it can be described with a small, exact formula rather than a vague promise. If a system knows how many requests per second it is receiving, and how many requests per second a single server can handle, it can calculate exactly how many servers it needs at that moment:

import math

def servers_needed(requests_per_second, capacity_per_server=500):
    return math.ceil(requests_per_second / capacity_per_server)

print(servers_needed(200))     # an ordinary Tuesday afternoon
print(servers_needed(12000))   # first two seconds of Tatkal, 10:00 AM

Trace through this exactly as Python would. On an ordinary afternoon, requests_per_second is 200 and capacity_per_server is 500, so the function computes 200 / 500, which is 0.4. Since even a fraction of a server still means you need one whole server to serve it, the function rounds this up using math.ceil (the "ceiling" function, which rounds any non-integer up to the next whole number) — math.ceil(0.4) is 1. So print(servers_needed(200)) outputs 1. During the Tatkal spike, requests_per_second is 12000, so the function computes 12000 / 500 = 24.0, and math.ceil(24.0) is 24. So print(servers_needed(12000)) outputs 24.

A real cloud auto-scaler runs a check very much like this function, over and over, every few seconds, watching how many requests are arriving. When the number climbs, it starts new virtual machines using the apartment-building trick you just read about, and adds them behind a component called a load balancer — a piece of software that sits in front of all the servers and decides, for each incoming request, which server should handle it, spreading the 12,000 requests roughly evenly across the 24 available machines instead of sending them all to one. When the spike passes and demand falls back to 200 requests/second, the same logic shuts the extra 23 virtual machines back down, and the provider stops billing for them. You are billed roughly by server-minutes used, not by servers owned — which is why this model is often described as pay-as-you-go.

Three Ways to Rent: IaaS, PaaS, and SaaS

Not every customer wants the same amount of control, and cloud providers offer several different "levels" of renting, best understood through cooking. If you cook a meal entirely at home, you own the kitchen, buy every ingredient, and do every step yourself — this is like running your own on-premise server, with full control and full responsibility. Cloud computing offers three steps away from that:

• Infrastructure as a Service (IaaS): you rent a fully equipped commercial kitchen — stove, oven, gas connection, workspace — but you bring your own ingredients and cook every dish yourself from scratch. In cloud terms, the provider gives you a bare virtual machine with processing power, storage, and a network connection, and you install and manage your own operating system, database software, and application code on top of it. Examples include Amazon EC2 and Google Compute Engine.
• Platform as a Service (PaaS): the kitchen also comes with basic prepped ingredients and equipment already arranged — you only bring your recipe. The provider manages the operating system, the runtime, and often the database for you; you just hand over your application's code, and the platform runs it. Examples include Google App Engine and Heroku.
• Software as a Service (SaaS): you order a fully cooked meal, delivered ready to eat — no kitchen, no ingredients, no cooking. The entire application is built, hosted, and maintained by someone else; you simply use it through a browser or app. Gmail, Google Docs, Zoom, and Netflix are all SaaS — you never install, update, or manage any server for them at all.

Notice what changes as you move from IaaS to SaaS: you give up control in exchange for giving up responsibility. With IaaS you could configure absolutely anything about your virtual machine, but you are also responsible for patching its operating system and configuring its security. With SaaS you can configure almost nothing about how Gmail works internally, but you are also never responsible for keeping Gmail's servers running — Google is.

Public, Private, and Hybrid Clouds

Cloud computing also comes in different deployment models, describing who the underlying physical infrastructure is shared with. A public cloud is infrastructure owned by a provider like AWS, Microsoft Azure, or Google Cloud, and shared — through virtualization — among many different, unrelated customers at once; this is what most apps and websites you use run on. A private cloud is infrastructure dedicated to a single organisation alone — for instance, a bank that must keep tight, exclusive control over sensitive customer data might run its own data center that no other company's virtual machines ever share, even though it may use the very same virtualization techniques internally. A hybrid cloud mixes the two — an organisation might run its public-facing website on a public cloud provider for elasticity and reach, while keeping certain sensitive records on infrastructure it fully owns and controls, with the two systems connected to work together.

Common Misconception: "The Cloud" Isn't Actually a Cloud

It is worth directly correcting a very natural but wrong mental picture. Because it is called "the cloud," and because you access it wirelessly through the air on your phone, it is tempting to imagine that cloud computing means your data floats somewhere immaterial, not stored on any actual machine. This is false, and it matters that it's false: every photo you back up, every request IRCTC's app sends, and every line of the get_result function from earlier in this chapter runs on real, physical hardware — spinning fans, blinking status lights, generating real heat — sitting in a real warehouse, in a real city, drawing real electricity from the power grid, needing real air-conditioning to avoid overheating. The name "cloud" actually comes from a much older habit: for decades before cloud computing existed, network engineers drawing diagrams of computer networks would sketch a cloud-shaped symbol to represent "the rest of the internet, whose internal wiring we don't need to detail here." When companies began offering computing power that you access over that same abstracted network — without you needing to know or care which exact physical machine answers your request — the old diagram symbol became the name for the whole idea.

A second, related mix-up is treating "the cloud" and "the internet" as the same thing. The internet is the global network of cables, routers, and wireless links that carries data from one machine to another — it is the road. Cloud computing is a particular way of using computers that happen to be reached over that road: renting processing and storage on demand from someone else's data center, instead of owning the hardware yourself. A UPI payment app, for instance, depends on the internet to carry its messages, but "the cloud" specifically refers to the rented servers running the app's code and storing its data — not the wires and towers the messages travel through to get there.

Why Redundancy Matters

One more idea completes the picture: physical machines fail. Hard drives wear out, power supplies burn out, and entire buildings can lose electricity in a storm. If your only copy of a database sat on one physical server and that server failed, your data would be gone with it — no amount of auto-scaling helps if the single machine holding your information stops working. Cloud providers address this with redundancy: they automatically keep multiple copies of your data on different physical machines, and often in entirely different data centers in different cities, a process called replication. If one copy becomes unreachable, the system quietly switches to reading from another copy, and most users never notice anything happened. It is the same idea as keeping a copy of an important school project on your laptop and a second copy on a pen drive at home — except cloud providers do this automatically, across many machines, for every customer, all the time.

Test Yourself: The Cloud In Action

1. A live cricket-final ticket sale runs on servers each rated at 800 requests/second. In the first second after tickets go live, the app receives 9,600 requests. Using servers_needed = ceil(requests_per_second / capacity_per_server), how many virtual servers should the auto-scaler bring online?
2. Classify each of the following as IaaS, PaaS, or SaaS: (a) opening Gmail in a browser to check your inbox; (b) renting a bare virtual machine and installing your own MySQL database on it yourself; (c) uploading your Python application's code to a platform that automatically manages the operating system and runtime for you.
3. True or false, and explain in one sentence: "Cloud servers have no fixed physical location, which is why it's called the cloud."
4. A school wants its results portal to survive the traffic spike on report-card day without spending money on idle hardware for the other 364 days of the year. Explain, using the idea of elasticity, why a cloud provider solves this better than the school buying one very powerful server outright.
5. Explain, in your own words, how virtualization lets one physical server in a data center safely run a school's results portal and an unrelated company's online store at the same time.

Answer key: (1) 9600 ÷ 800 = 12.0, and ceil(12.0) is 12, so 12 servers. (2) (a) SaaS — you use the finished application with no management of any kind; (b) IaaS — you manage the operating system and software yourself on rented raw infrastructure; (c) PaaS — the platform manages the operating system and runtime, you supply only the code. (3) False — cloud servers are physical machines sitting in specific, real data center buildings in specific cities (such as AWS's Mumbai region); the name "cloud" comes from an old network-diagram symbol representing abstraction, not from the servers being locationless. (4) Buying one very powerful server means paying for enough capacity to survive the single busiest day, then watching almost all of that capacity sit unused every other day; a cloud provider lets the school rent a small amount of capacity most of the year and automatically scale up to many virtual servers only for the hours around report-card day, paying only for the extra capacity while it is actually in use. (5) A hypervisor divides the one physical server into several isolated virtual machines, each with its own operating system and its own slice of the physical CPU, memory, and storage; the two organisations' virtual machines run side by side on the same hardware but cannot see or access each other's data or processes, in the same way that two flats in one apartment building share a foundation but have separate, locked front doors.

Summary

• Cloud computing means renting computing power, storage, and databases from a provider's data center over the internet, paying only for what you use, instead of buying and housing physical machines yourself.
• A single server has a fixed capacity (requests it can handle per second); demand beyond that capacity causes queuing or crashes unless more capacity is added.
• Virtualization, run by a hypervisor, splits one physical server into several isolated virtual machines, letting many customers safely share the same hardware and letting new capacity be created in seconds rather than weeks.
• Elasticity (auto-scaling) means the number of active virtual servers grows and shrinks automatically to match real-time demand, calculated as servers_needed = ceil(requests_per_second / capacity_per_server); a load balancer spreads incoming requests across all currently active servers.
• The three service models — IaaS (rent bare infrastructure), PaaS (rent a ready platform, supply only your code), and SaaS (use a fully finished application) — trade control for reduced responsibility as you move from IaaS toward SaaS.
• Deployment models — public (shared provider infrastructure), private (dedicated to one organisation), and hybrid (a mix) — describe who the underlying hardware is shared with.
• "The cloud" is not immaterial — it is real hardware in real data center buildings; the name comes from an old network-diagram abstraction symbol, and cloud computing is a way of using computers over the internet, not the internet itself.
• Redundancy, through automatic replication of data across multiple physical machines, protects against hardware failure so that one broken server does not mean lost data.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where cloud computing: your code in the sky is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting cloud computing: your code in the sky to at least 3 other topics you have studied.