01What Is "The Cloud," Really?

Forget the fluffy icon. It's someone else's computer, rented by the minute — and five specific traits that make that renting genuinely different from renting anything else.

Here's the least mystical explanation possible: the cloud is just someone else's computer that you rent by the minute, over the internet, instead of buying and running your own. That's genuinely most of it. The interesting part is how that renting works.

An analogy: electricity, not a generator

A hundred years ago, if a factory wanted power, it built its own generator on-site — expensive, needed maintenance, and if you built it too small you'd run out of power on a busy day; too big, and you wasted money on unused capacity every quiet day.

Then the electrical grid arrived. Now the factory just plugs in and pays for what it uses, whenever it uses it. Cloud computing did the same thing to computers: instead of a company buying its own servers (the "generator"), it plugs into a provider's giant computer "grid" (AWS, Azure, Google Cloud) and pays only for what it actually uses.

The five things that make it "cloud"

There's an official definition from a US standards body (NIST) worth knowing — every course, certification, and interview will reference some form of it. In plain English:

1. On-demand self-service — you click a button and get a new server. No phone call, no waiting for someone to walk to a server room.
2. Broad network access — you reach it over the internet from anywhere, on any device.
3. Resource pooling — the provider's giant pile of computers is shared across thousands of customers, like an apartment building sharing plumbing between units.
4. Rapid elasticity — you scale up in minutes when busy and down when quiet; capacity feels basically unlimited.
5. Measured service — everything is metered, like a water meter, and billed for exactly what you used.

Cloud vs. building it yourself

When building it yourself still makes sense: computing needs so steady you'd use 100% of a server 24/7 for years, or strict legal rules that hardware must sit inside your own building. For almost every student project and startup, cloud wins.

The money side: Capex vs. Opex

This sounds like an accounting term you can ignore — it explains why companies love the cloud so much.

• Capex (Capital Expenditure) — buying a big asset upfront, like buying a car outright. It sits on the books as something you own.
• Opex (Operating Expenditure) — an ongoing bill, like a ride-hailing fare or a Netflix subscription. You never own the car; you just pay each time you use it.

Cloud shifts spending from capex (buy servers) to opex (pay a monthly bill) — a big deal for a small startup that doesn't have to raise cash upfront just to get started.

02The "As-a-Service" Menu

IaaS, PaaS, SaaS, FaaS — four letters that all answer one question: how much of the technical work does the provider do for you?

The pizza analogy

Imagine you want pizza tonight. You have four options, each handing off a different amount of the work:

A fifth, newer option doesn't fit neatly on the pizza scale: FaaS (Function as a Service) — a vending machine that bakes you exactly one slice, on demand, the second you press the button, and disappears again the moment you're done. You're billed only for that.

What each one actually is

• IaaS — raw computers, storage, networking; you choose the OS and patch it. Maximum control, maximum responsibility. Amazon EC2, Google Compute Engine, Azure VMs.
• PaaS — the provider handles the OS and runtime; you hand over your app. Google App Engine, Azure App Service, and — importantly here — Google Cloud Run.
• FaaS — you write one small function; the provider does everything else, including making it disappear (and stop costing money) when nobody's using it. AWS Lambda, Azure Functions, Cloud Run functions.
• SaaS — a complete, ready-to-use application. No infrastructure decisions at all. Gmail, Microsoft 365, Salesforce.

Two extra terms worth knowing

• CaaS (Containers as a Service) — a managed way to run containers without operating the scheduling machinery. Sits between IaaS and PaaS.
• DBaaS (Database as a Service) — a managed database. Often the very first "as-a-service" thing any small team adopts, because running your own database well is genuinely hard.

03Meet the Big Three Cloud Providers

AWS, Azure, and Google Cloud — three supermarket chains, each with a different personality.

Three companies dominate cloud computing: Amazon (AWS), Microsoft (Azure), and Google (Google Cloud / GCP). All sell "groceries," all are reliable, but each has a different specialty.

None of this means one is "the best" — the right choice depends on your team, your existing tools, and what you're building.

A quick word on "Vertex AI," "Bedrock," "Azure AI Foundry"

Each provider also has its own AI platform for building AI-powered features. We won't go deep into AI here — that's a whole additional topic in this course — but know these names refer to "which company's AI toolbox," not different concepts.

04Renting Computers the Smart Way

Virtual machines, containers, and serverless — a whole house, an apartment unit, or a hotel room billed by the hour.

The spectrum: VMs → Containers → Serverless

Imagine three ways to get a place to cook:

• Virtual Machine = renting a whole house. Full control over the plumbing, walls, everything — and you're responsible for maintaining all of it, paying rent whether you're home or not.
• Container = renting a unit in an apartment building. Your own self-contained space, sharing the building's foundation and utilities with other tenants — cheaper and faster to move into than a whole house.
• Serverless = paying for a hotel room only for the hours you sleep there. The moment you leave, the meter stops. On a quiet night, a room isn't even prepared until you check in.

Kubernetes, a name you'll hear constantly, is basically the "building manager" software that looks after a large number of containers spread across many physical machines — deciding which container goes where, restarting crashed ones, and so on. Genuinely powerful, but also a lot of machinery to learn and operate.

Autoscaling: adding more staff when the queue gets long

Autoscaling means automatically adding computing capacity when demand increases, and removing it when demand drops — like a coffee shop opening a second register the moment the line gets long, and closing it again once things quiet down. Serverless platforms can scale all the way down to zero registers open (and zero cost) at 3am.

Cold starts: the barista who's gone home

A cold start is the small delay the first time a "new" computing environment has to wake up before it can serve you — like walking into a café at an odd hour and waiting for the barista to come out and turn the machine on, versus 8am when everything's already warmed up.

You can avoid this by keeping at least one "barista" always ready (a minimum instance count) — worth doing where that first delay would be a bad experience (a payment button), not worth doing for something rarely visited (an internal admin page used twice a month).

Choosing the right option

1. Spiky or mostly idle traffic? → Serverless. You'll barely pay when it's quiet.
2. Steady, heavy traffic all day? → A regular server or right-sized container setup often becomes cheaper than serverless.
3. Need specific hardware (GPU) or full OS control? → A Virtual Machine.
4. A small, one-off task triggered by an event? → Serverless functions (FaaS) are the simplest fit.

05Where Does Your Data Live?

Warehouses of labeled boxes, filing cabinets bolted to your desk, disciplined spreadsheets, and flexible folders of documents.

Three kinds of storage

• Object storage = a warehouse of labeled boxes. Drop a whole file in with a label, fetch it back by that label; you can't edit a piece without replacing the whole box. Best for photos, videos, backups. Amazon S3, Google Cloud Storage, Azure Blob Storage.
• Block storage = your personal filing cabinet, bolted to your desk. Behaves like a hard drive attached to one machine — fast, but tied to it. What database engines typically sit on. Amazon EBS, Google Persistent Disk.
• File storage = a shared office filing cabinet everyone can open. Multiple computers open and use it at once, like a shared network drive.

Storage classes let you mark old, rarely-accessed files as "cold" storage — cheaper to keep, a little pricier to retrieve — like moving old paperwork into a storage unit across town. Riverside, which must keep years of billing records it rarely looks at, saves real money doing this.

Databases: SQL vs. NoSQL

• Relational (SQL) databases are like a very disciplined spreadsheet: strict columns, clear rules, strong guarantees that a transaction either fully happens or doesn't (critical for money). Amazon RDS, Google Cloud SQL, Azure Database.
• NoSQL databases are more like a flexible folder of documents: each entry can look different, no rigid up-front structure, built for massive scale of simple lookups. MongoDB-style stores, DynamoDB, Firestore.

Data warehouses: the big reporting library

A data warehouse (Google BigQuery, Amazon Redshift) is a separate database built for big, heavy reporting questions, instead of the fast, small day-to-day questions a regular app database handles. Most systems keep their everyday database separate from their reporting warehouse, so heavy reports never slow down the live app.

Backups and "what if something goes wrong"

• RPO (Recovery Point Objective): how much data you can afford to lose, measured in time. "1 hour RPO" means, worst case, you'd lose up to an hour of transactions.
• RTO (Recovery Time Objective): how much downtime you can afford. "30-minute RTO" means you need to be back up within half an hour.

Think insurance policy: the more protection you want, the more it costs to maintain — usually by keeping a live, ready-to-go backup running somewhere else, rather than just an occasional snapshot.

06How the Cloud Talks to the World

Private neighborhoods, restaurant hosts, local franchises, phonebooks, and checking everyone's ID at every door.

VPCs: your own private neighborhood

A VPC (Virtual Private Cloud) is your own private, isolated slice of network inside the provider's cloud — like renting a gated neighborhood with your own private streets, even though the whole city is shared by many other "neighborhoods." You decide which houses (servers/databases) get a street-facing address (public) versus sit tucked away at the back (private).

Load balancers: the restaurant host

A load balancer is like the host who greets you at a busy restaurant and seats you at whichever table/waiter is free, instead of everyone crowding one waiter while others stand idle. It also notices if a "waiter" (server) has gone missing and quietly stops sending guests their way.

CDNs: local franchise stores instead of one central warehouse

A CDN copies your unchanging content (images, videos, style files) to many small "storefronts" around the world, physically closer to each visitor — like a coffee chain opening a local branch in every city instead of making every customer travel to one central roastery.

DNS: the internet's phonebook

DNS translates a friendly name (brewbean.com) into the numeric address a computer needs — exactly like looking up a name in a phonebook. You almost never think about it until it breaks, at which point everything seems "down" even though the servers are fine.

Zero trust: checking everyone's ID, every single time

Old-school security worked like an office with a strong front door: once past security, you can wander any floor freely — "inside the building" implicitly meant "trusted." Zero trust throws that out: every door inside checks your ID again, every time, regardless of the front entrance.

This matters for Riverside: the public citizen-facing billing website being "inside the same network" as the internal HR/payroll system should not mean the billing website can freely reach payroll data.

07Keeping the Cloud Safe

Badge systems, locked diaries, safes instead of sticky notes, and safety inspections for data.

IAM: the office badge system

IAM (Identity and Access Management) answers two questions for every action: who are you, and what are you allowed to do? Like an office badge: it proves who you are (authentication), and it's programmed to open only the doors you actually need (authorization) — not every door in the building.

The single most important rule is least privilege: give people (and apps) only the access they actually need, nothing more "just in case" — the cloud-security equivalent of not handing every new employee a master key on day one.

Encryption: locking the diary and locking the mail truck

• Encryption at rest protects data sitting still on a disk — a locked diary, so a stolen notebook can't be read without the key.
• Encryption in transit protects data while moving between two places — a sealed courier bag, instead of an open postcard.

Modern platforms encrypt data at rest by default — but it's still your job to make sure data is also encrypted in transit everywhere, including the easily-forgotten app-to-database hop.

Secrets management: use a safe, not a sticky note

A "secret" is any sensitive value your app needs — a database password, an API key. The classic beginner mistake is hardcoding these directly into code (which then gets saved to GitHub for the world to see). A "secrets manager" is a proper safe with an access log, instead of a sticky note on your monitor.

Compliance: safety inspections for data

You'll hear acronyms like ISO 27001 and SOC 2 — basically independent safety inspections that prove good security practices, like a restaurant's health inspection certificate. Importantly: a cloud provider being certified does not automatically make your app secure or compliant — you still have to lock your own doors correctly on top of a secure building.

In the Philippines, the Data Privacy Act of 2012 governs how personal data must be handled, enforced by the National Privacy Commission — directly relevant to any system storing citizens' personal information.

A simple pre-launch security checklist

• No passwords or API keys typed directly into code.
• Every important human account has multi-factor authentication (MFA) on.
• Databases are not directly reachable from the public internet.
• Everything is encrypted both at rest and in transit.
• Backups exist, and someone has actually tested restoring from one.
• There's a written plan for "what do we do, and who do we tell, if data leaks."

08Watching Your Wallet

Electricity bills, storage units, roaming charges, gym memberships, and standby airline tickets.

What actually drives the bill

Pricing models: walk-in rate vs. gym membership vs. standby ticket

• On-demand: like a walk-in gym day-pass — most flexible, most expensive per visit.
• Reserved/committed: like an annual gym membership — commit in advance for a real discount, but locked in even on months you don't go.
• Spot/preemptible: like a heavily discounted standby airline ticket — very cheap, but the airline can bump you with short notice. Great for interruptible workloads, terrible for anything that must never stop mid-task.

Tagging: labeling every receipt

Tagging means attaching a small label (project: brewbean-app) to every cloud resource, so at month's end you can see which project or department is responsible for which slice of the bill — like labeling every receipt so accounting knows which budget to charge.

FinOps: a household budgeting habit

FinOps (Finance + DevOps) is just the practice of regularly reviewing and adjusting your cloud spending — like checking your bank statement monthly instead of once a year in a panic. For a small team: a monthly reminder to review the bill, a budget alert, and the discipline to delete unused things.

09Building Apps the Cloud-Native Way

Good hygiene rules, one big kitchen vs. a food court, and a notice board instead of a phone call.

The 12-Factor App: good hygiene rules

The 12-Factor App is a well-known set of good habits for cloud-friendly software. A few matter enormously:

• Keep configuration out of your code. Passwords, keys, and settings that differ between environments should live outside the code, so the same packaged app runs anywhere just by changing its settings.
• Treat your running app as disposable. Any single copy should be killable and instantly replaceable without anyone noticing — put shared state in a database or cache, not in the app's own memory. This is exactly what makes autoscaling safe.
• Send logs somewhere else. Let the platform collect and centralize logs instead of digging through files on individual machines.

Monolith vs. microservices: one big kitchen vs. a food court

• A monolith is one app doing everything — one big kitchen making every dish. Simple to run, but everything scales and deploys together, whether it needs to or not.
• Microservices split the app into many small, independently-run pieces — a food court where each stall specializes and scales independently. Powerful for large teams, but more coordination and more things that can individually break.

The middle ground — a "modular monolith": organize your one app into clean, separate internal sections without actually splitting into separate deployed services yet. Most of the organizational clarity of microservices, without the operational overhead.

Event-driven architecture: a notice board instead of a phone call

Normally, one part of a system calls another directly and waits for an answer — a phone call. In an event-driven design, a part posts a notice ("MeterReadingRecorded!") to a shared board, and any interested part reacts whenever it gets around to it — without the first part needing to know or care who's watching.

API gateways and service mesh

An API gateway is a single front desk that all requests pass through first — checking IDs, handling rate limits, routing each visitor to the right department. A service mesh is extra infrastructure that automatically handles secure communication and monitoring between many microservices — genuinely useful, but only once you have a food court with dozens of stalls that would otherwise each build this plumbing themselves.

10Bringing It All Together

One table, one story, one glossary — and where to go from here.

A short story pulling it all together

Imagine BrewBean, six months after launch, has grown into a real small business with thousands of daily orders. Here's how the ideas from this book show up in one ordinary morning:

A customer opens the app (Ch. 6: DNS resolves the name, a load balancer picks a healthy server, a CDN serves images from a nearby copy). They log in (Ch. 7: password checked against an encrypted database, connection protected the whole way). They place an order, and because it's 8am rush hour, more app instances automatically spin up (Ch. 4: autoscaling on serverless containers). The order is saved to a SQL database, because a payment must not be "half-recorded" (Ch. 5). Placing the order posts a notice that a background service picks up to email a receipt, without the main app waiting around (Ch. 9: event-driven design). At month's end, the founder checks a dashboard showing exactly how much last month cost, broken down by tag (Ch. 8), and decides whether it's time to consider a committed-use discount now that there's real usage data.

None of these ideas exist in isolation — real systems are always a combination working together.

A short glossary

API

A defined way for two pieces of software to talk to each other.

Autoscaling

Automatically adding/removing computing capacity to match demand.

Cold start

The short delay when a "sleeping" serverless environment wakes up to serve a request.

Container

A lightweight, portable package of an app and everything it needs, sharing the host machine's core with other containers.

DNS

The system that translates human-friendly names into computer addresses.

Egress

Data leaving a cloud network, often the cost that catches people by surprise.

IAM

Identity and Access Management: who you are, and what you're allowed to do.

Kubernetes

Software that manages large numbers of containers across many machines.

Load balancer

Spreads incoming traffic evenly across multiple servers.

Microservices

An app split into many small, independently deployed pieces.

On-prem

Running your own hardware in your own building, instead of using the cloud.

Serverless

Computing where the provider handles everything below your code, including scaling to zero cost when idle.

VPC

Your own private, isolated network inside a cloud provider's infrastructure.

Where to go next

This book intentionally left out most exact numbers, command syntax, and pricing details — those change constantly and are better looked up fresh when needed. Once these ideas feel comfortable:

1. Get hands-on. Every major provider has a free tier — the fastest way to make these ideas click is to deploy something small yourself.
2. Read the official docs for precision. The AWS, Google Cloud, and Azure Architecture Centers, and the official NIST definition of cloud computing, are free and authoritative.
3. Want the deeper, technical version of every chapter — exact configuration flags, exact percentages, real worked examples? Ask your instructor about the companion technical reference notes this book was distilled from.

You now have the mental map. The rest is practice.