Cloud — Someone Else’s Computers, Done Right

The day your SplitEase API needs to be reachable by someone other than you, the question stops being “does my code work” and becomes “where does it run when my laptop is closed.” That place is the cloud — a data centre somewhere in Mumbai or Singapore renting you a slice of a machine by the second. This track teaches you what you’re actually renting, so you can pick the cheap right thing instead of the expensive default.

The Goal

By the end of this track you can:

• Explain what cloud actually is — renting compute and managed services instead of owning servers
• Choose where a zero-budget learner starts, honestly, instead of cargo-culting AWS
• Map the handful of services that matter across AWS, GCP and Azure so the skill transfers
• Deploy SplitEase the free way and know the AWS equivalent it maps to
• Protect yourself from the two beginner disasters — a surprise bill and a leaked key

The Lesson

What “the cloud” actually is

Strip the marketing and the cloud is one idea: you rent computers by the second instead of buying them. Someone else owns the building, the machines, the power, the cooling and the network. You request capacity over an API, use it, and pay for exactly what you used.

Compare the two worlds for running SplitEase:

Two terms interviewers use for this shift:

• Capex → Opex. Owning servers is capital expenditure — a big lump of money spent upfront, before you know if anyone wants your product. Cloud turns it into operating expenditure — a monthly bill that scales with usage. For a startup with no revenue, not betting lakhs on hardware before the first customer is the entire point.
• Elasticity. You can grow and shrink capacity on demand. A college-results site that gets hammered for two days a year runs one small server the other 363. Owning enough hardware for the spike means it sits idle 99% of the time; renting means you pay for the spike only while it happens.

The mental trap to kill now: the cloud is not magic and it is not “serverless means no servers.” It is always someone’s real, physical computer in a real building. You just stopped being the one who buys, racks and babysits it.

In one picture: how much you hand off

Cloud isn’t one thing — it’s a spectrum of “how much do I want to manage myself.” The more you hand to the provider, the less control and the less babysitting:

flowchart LR
    A["On premise: you own everything, the building, the machine, the OS"] --> B["IaaS: rent the machine, you manage the OS and up, like EC2"]
    B --> C["PaaS: push code, the platform runs it, like Railway or Render"]
    C --> D["SaaS: just use the finished app, like Gmail"]

Read it left to right as letting go of work. IaaS (Infrastructure-as-a-Service) rents you a raw virtual machine — maximum control, you patch the OS. PaaS (Platform-as-a-Service) takes your code and runs it for you — you stop thinking about servers. SaaS is someone else’s finished product you just log into. As a beginner shipping SplitEase, you want PaaS first: most of the benefit, almost none of the babysitting.

Toggle between the four models below and watch the stack layers flip from “you manage” to “provider manages” — that’s the whole spectrum in one control:

Before the rest of the lesson sinks in, take the before photo — answer from what you think now, then re-read after the track:

The big three — and where you actually start

Three providers own most of the market. You will see all three on job descriptions:

The skills transfer. A virtual server is a virtual server whether the button says EC2, Compute Engine or Virtual Machines — which is why the next module maps every core service across all three. Learn the concepts on one provider and you can read the other two.

Each provider has a free tier — a real way to learn without a bill:

• AWS: a mix of 12-month free allowances and always-free limits — aws.amazon.com/free
• GCP and Azure have equivalents with starter credits

But here is the honest part most courses won’t tell you. The AWS free tier is not the easiest place for a beginner to put a first real app. It hands you raw building blocks — a bare Linux server, a separate database, networking rules, IAM permissions — and expects you to assemble them. That is great for learning what the pieces are, and miserable for just getting SplitEase online tonight.

For your first real deployment, a PaaS (Platform-as-a-Service) like Railway or Render is genuinely better: you point it at your repo, it builds and runs the container, gives you a URL and a managed Postgres, and you are live in minutes with no IAM or VPC to configure. That is exactly the zero-budget path Month 3, Week 9 walks you through, and it is the recommended way to ship first.

The plan, then: deploy on a PaaS to get live and keep momentum, and use AWS’s free tier to learn what those pieces actually are underneath. Both, in that order — not AWS-first because a job ad said “AWS.”

The shared-responsibility model, in one line

The single most important security idea in cloud, compressed: the provider secures the cloud; you secure what you put in it.

AWS keeps the data centres, the physical machines and the hypervisor safe — that is their half. Your half is your code, your data, who you give access to, and not committing your secret keys to a public repo. Most cloud breaches you read about are not the provider being hacked; they are someone’s half — a public storage bucket, a leaked access key, an over-permissive role. Module 03 makes this concrete; for now, burn in the one line.

This track

Start with Cloud 01 — once the vocabulary clicks, the rest is hands-on.

Check Yourself

Module done? Add it to today’s tracker