Cloud Basics: Where Your Code Actually Runs

"The cloud" is one of those terms that sounds like it means something profound. It doesn't.

The cloud is someone else's computer, sitting in a data center, that you rent. That's it. When your app is "in the cloud," it means it's running on a physical server in a building somewhere — probably in Virginia, Oregon, or Ireland — that belongs to a company you pay monthly.

There's no floating infrastructure. No ethereal compute layer. Just racks of hardware in climate-controlled warehouses, connected to the internet with fat fiber cables. You rent time on those machines instead of buying your own.

The entire cloud industry is built on this one idea: it's cheaper and easier to rent compute than to own it.

The Big Three

Three companies dominate cloud infrastructure: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Together, they control roughly two-thirds of the global cloud market.

AWS was first. Amazon launched it in 2006, originally as a way to sell excess server capacity. It now offers over 200 individual services. You can run virtual servers, manage databases, process machine learning workloads, stream video, send emails, and about 195 other things. AWS is the default choice for most enterprises and startups with significant infrastructure needs.

Azure is Microsoft's answer. It integrates tightly with the Microsoft ecosystem — Windows Server, Active Directory, .NET, SQL Server, Visual Studio. If your organization already runs on Microsoft tools, Azure is the path of least resistance. It's the dominant choice in enterprise environments that have existing Microsoft contracts.

GCP is Google's platform. It's strong in data analytics, machine learning, and Kubernetes (which Google originally created). GCP has the smallest market share of the three, but it's a serious platform with loyal users, particularly in data-heavy and ML-focused organizations.

Here's the thing about all three: they're massive, complex, and designed for scale. Their dashboards have hundreds of menu items. Their documentation runs to millions of pages. Their pricing calculators need their own tutorials. For a beginner trying to put a web app on the internet, this is like renting a 747 to fly across town.

You probably don't need any of them yet.

The Developer-Friendly Options

A different category of cloud platforms exists specifically to make deployment simple. These platforms abstract away the infrastructure complexity and let you focus on your code.

Vercel specializes in frontend deployment. Built by the team behind Next.js, it's optimized for static sites, React apps, and serverless functions. You connect your GitHub repo, push code, and your site is live. It's genuinely that simple for frontend projects. The free tier is generous enough for most personal projects and portfolios.

Netlify does essentially the same thing as Vercel. Static sites, serverless functions, automatic builds from Git. The two platforms are direct competitors with nearly identical feature sets. Pick whichever interface you prefer.

Railway focuses on backend deployment. You need to run a Node.js API? A Python Flask server? A database? Railway gives you a clean interface, connects to your repo, detects your stack, and deploys it. No Dockerfiles required (though it supports them). It's what Heroku used to be before Salesforce gutted it.

Render covers both frontend and backend. Static sites, web services, background workers, databases, cron jobs — all from one platform. It positions itself as the modern Heroku replacement and does a solid job of it.

DigitalOcean sits between the developer-friendly platforms and the big three. It offers simple virtual servers (called Droplets) starting at $4/month, plus managed databases, Kubernetes, and app hosting. You get more control than Vercel or Railway, but less complexity than AWS. It's the middle ground where you learn real infrastructure without drowning in it.

Vultr occupies similar territory to DigitalOcean — straightforward virtual servers, block storage, and managed databases at competitive prices. Another solid option for developers who want more control without AWS-level complexity.

When to Use What

This is the decision tree that matters. Stop overthinking it.

Static site or frontend app (HTML, CSS, JavaScript, React, Next.js): Use Vercel or Netlify. They're purpose-built for this. Free tier handles it. Deployment takes seconds.

API or backend service (Node.js, Python, Go, anything that listens on a port): Use Railway or Render. Connect your repo, configure a few environment variables, deploy. Monthly cost is typically $5-20 for small projects.

Full control over a server (you want to SSH in, install whatever you want, configure nginx, run multiple services): Use a DigitalOcean Droplet or Vultr instance. You get a Linux virtual machine that you manage yourself. This teaches you real operations skills.

Enterprise requirements (compliance certifications, specific geographic regions, complex networking, services that only exist on big platforms): Use AWS or Azure. But if you're reading a beginner article about cloud basics, this isn't you yet.

Database hosting: Most of the developer platforms offer managed databases. Railway and Render both include PostgreSQL. DigitalOcean has managed databases. For learning, any of these work. For production with serious data, you'll eventually want a dedicated database service.

Key Concepts You'll Encounter

A few terms that come up constantly in cloud computing.

Regions: Cloud providers operate data centers in multiple geographic locations. When you deploy, you choose a region. Pick one close to your users. If your audience is mostly in North America, don't deploy to a Singapore region. Latency is physics — data can only travel so fast through fiber.

Scaling: Running more copies of your app when traffic increases, and fewer when it decreases. Vertical scaling means a bigger server. Horizontal scaling means more servers. Most developer platforms handle this automatically. On AWS/Azure, you configure it yourself.

Pay-as-you-go: You pay for what you use. Run a server for three hours? Pay for three hours. Serve 10,000 requests? Pay for 10,000 requests. This is great in theory. In practice, it means your bill is unpredictable if you don't set limits.

Free tiers: Every cloud provider offers something for free. This is how they get you in the door.

The Free Tier Trap

Free tiers are real and useful. They're also carefully designed to become not-free at exactly the moment you're too invested to switch.

AWS gives you 12 months of a tiny virtual server for free. Month 13, you get a bill. Azure gives you $200 in credits for 30 days. Day 31, the meter starts. GCP gives you $300 in credits for 90 days. You see the pattern.

The developer-friendly platforms are more straightforward. Vercel's free tier is genuinely free for personal projects — no time limit, no credit card tricks. Railway gives you $5 of free usage per month. DigitalOcean doesn't have a free tier at all, which is honestly more transparent.

The rule: always know what triggers billing. Set up billing alerts. Put a spending cap on your account if the platform allows it. A misconfigured auto-scaling policy on AWS can run up hundreds of dollars overnight. It happens to professionals. It will definitely happen to beginners.

What a Deploy Actually Looks Like

On Vercel, deploying a site works like this:

1. Write your code locally and push to GitHub

2. Sign up for Vercel, connect your GitHub account

3. Import your repository

4. Vercel detects your framework, configures the build

5. Every git push to your main branch triggers a new deployment

# You write code, commit, and push
git add .
git commit -m "Add contact page"
git push origin main
# Vercel automatically builds and deploys
# Your site is live at your-project.vercel.app within seconds

That's it. No servers to configure. No SSH. No nginx. No SSL certificates. Push code, site updates. This is why platforms like Vercel are the right starting point — they remove every obstacle between writing code and having it live on the internet.

When you're ready for more control, the workflow gets more involved. A DigitalOcean Droplet means you're managing a Linux server: installing dependencies, configuring a web server, setting up SSL, handling updates. More work, but more understanding.

The Path Forward

Start simple. Complicate later.

Phase 1: Deploy a frontend project to Vercel or Netlify. Get comfortable with the Git-based deploy workflow. Understand what a production URL is, how environment variables work, how builds run.

Phase 2: Deploy a backend service to Railway or Render. Connect it to a database. Learn about environment configuration, logs, and monitoring. Understand what happens when your service crashes at 2 AM (answer: it restarts automatically, usually).

Phase 3: Spin up a DigitalOcean Droplet. Set up a Linux server from scratch. Install your runtime, configure a reverse proxy, get an SSL certificate. This is where you learn what all those platforms were abstracting away from you.

Phase 4: Use AWS or Azure when a specific project demands it. By then, the dashboards won't intimidate you because you'll understand the concepts underneath.

Learning Path Complete

This is the final post in the DevOps Without Jargon learning path. You've gone from understanding what DevOps actually means, to containers, to CI/CD, and now to where your code runs in production.

The concepts in this path connect directly to several others. If you're building the things you want to deploy, the Web Development Fundamentals path covers the code side. If you're interested in the data your deployed apps produce, the AI and Machine Learning path picks up from there. And if you're thinking about quality — making sure the things you deploy actually work correctly — the Software Quality path addresses that directly.

The cloud isn't complicated. The information about the cloud is complicated. Vendors have every incentive to make their platforms seem essential and irreplaceable. The reality is simpler: you need a computer connected to the internet that runs your code. Everything else is choosing how much of that setup you want to manage yourself.