Cloud and Compute: What Your Code Actually Runs On
· Jerwin Arnado ·
Part six of the full-stack series. The last post put your app on a server. This one asks what that server is. “The cloud” sounds ethereal; it’s a rack of real machines in a building with good air conditioning, sliced up and rented by the hour. Understanding the slices is how you stop overpaying and stop being surprised by the bill — and, as a homelab person, how you decide what to rent versus run yourself.
The three shapes of compute
Cloud compute comes in three forms, trading control for convenience — the same spectrum as hosting, one level down:
| Shape | What you get | You manage | Bills by |
|---|---|---|---|
| VM / instance | a whole virtual machine | OS and up | the hour it’s on |
| Container | an isolated process, shared kernel | the image + orchestration | usually the hour/resources |
| Serverless / function | code that runs on a trigger | only your function | per invocation + ms of runtime |
A VM (DigitalOcean droplet, EC2) is a computer you fully control — and pay for whether it’s busy or idle. A container packages your app with its dependencies so it runs identically on your laptop, CI, and prod (this is the “works on my machine” cure). Serverless runs only when called and scales to zero — you pay nothing when idle, but cold starts and execution limits are the catch.
vCPU and RAM: the two dials that matter
Strip away the marketing and a compute instance is two numbers:
- vCPU — virtual CPU cores, how fast and how parallel it works. PHP-FPM workers, queue workers, and request concurrency all want cores.
- RAM — working memory. Run out and the OS swaps to disk (catastrophically slow) or the kernel’s OOM killer starts shooting processes. A database loves RAM; so does a cache.
Most small-to-mid apps are RAM-bound before CPU-bound — the database and cache eat memory long before the CPU saturates. Size for that, and watch the actual graphs in your monitoring instead of guessing.
Containers, briefly
A container image is a recipe: base OS, PHP, extensions, your code, locked together.
FROM php:8.5-fpm-alpine
RUN docker-php-ext-install pdo_mysql opcache
COPY . /var/www
# the exact same image runs in CI, staging, and prod — no drift
The value isn’t the buzzword — it’s identical environments everywhere. The image that passed CI is byte-for-byte the image in production. Orchestrating many containers across many machines is Kubernetes’ job, and that’s a real operational cost — most apps are happier on a managed platform or a couple of droplets until scale genuinely forces the issue. Don’t adopt k8s for a side project.
The bill is part of the architecture
Cloud cost is an engineering concern, not just finance’s problem. The classic surprises:
- Idle instances billed 24/7 while serving nothing. Turn off staging overnight.
- Egress / bandwidth — moving data out often costs more than storing it. A CDN cuts this directly.
- Over-provisioning “to be safe” — paying for an 8GB box doing 1GB of work.
- Forgotten resources — an orphaned load balancer, an unattached volume, a snapshot from 2024 quietly accruing.
This is exactly why I run a Proxmox homelab for steady, predictable workloads — local AI inference, media, internal tools. Fixed hardware cost beats a metered bill for anything that runs constantly. The cloud wins for spiky and global; owned hardware wins for steady and predictable.
Caveats and best practices
- Right-size from real metrics, not vibes. Start small, watch CPU/RAM under real load, scale the dial that’s actually saturated.
- Set billing alerts on day one. A runaway loop or a misconfigured autoscaler shouldn’t first announce itself as a four-figure invoice.
- Treat servers as cattle, not pets. Anything you can’t recreate from a script is a liability. Reproducible infra > a lovingly hand-tuned box nobody dares reboot.
- Pick boring regions close to your users. Latency is physics; a server near your users beats a fancier one far away.
Conclusion
Shapes → VM (control) ↔ container (portability) ↔ serverless (scale-to-zero)
Dials → vCPU (speed/parallelism) + RAM (usually the limit first)
Cost → idle, egress, over-provisioning, forgotten resources
Choose → cloud for spiky/global, owned hardware for steady/predictable
The cloud is just rented computers, and knowing what you’re renting — cores, memory, and the billing model — turns a scary abstraction into a set of dials you control. Next: CI/CD and version control, the automation that ships your code to all this compute safely.