Nothing about cloud computing is conceptually new — it's servers, storage, and networking, the same as a machine under your desk. What changed is how it's provisioned: instead of buying hardware and waiting for it to arrive, you request a virtual machine through an API and have it running in under a minute, paying only for the time you use it.
IaaS (Infrastructure as a Service) — you get a virtual machine and manage the OS, runtime, and everything above it yourself. Maximum control, maximum responsibility. Think AWS EC2.
PaaS (Platform as a Service) — you hand over your code, the platform handles the OS, scaling, and infrastructure. Less control, far less operational overhead. Think Render, Heroku, or Google App Engine.
SaaS (Software as a Service) — you use a finished product over the internet and manage none of the infrastructure at all. Gmail, Slack, this site's contact form's email delivery — all SaaS from the user's side.
Most projects starting out are better served by PaaS: you get 90% of the benefit of "the cloud" without needing to become a systems administrator first.
Vertical scaling means giving one server more resources — more RAM, a faster CPU. It's simple, but has a ceiling, and that one server is a single point of failure. Horizontal scaling means running multiple smaller servers behind a load balancer that distributes traffic between them. It has no hard ceiling and survives individual server failures, but requires your application to not depend on local, in-memory state that only one server knows about — which is why session data and file uploads in a horizontally-scaled app usually live in a shared database or object storage, not on any one server's disk.
Block storage behaves like a hard drive attached to a specific server — fast, but tied to that machine. Object storage (like AWS S3) stores files as independent objects accessible over HTTP from anywhere, which is why it's the default choice for user uploads, backups, and static assets in a cloud-native app. Managed databases are a third category — the cloud provider handles backups, replication, and patching, so you're not running your own database server and its maintenance schedule.
A container packages your application together with everything it needs to run — dependencies, runtime, configuration — so "works on my machine" stops being a real risk. Docker is the tool that made this mainstream; Kubernetes is the layer above it that manages many containers across many machines, restarting failed ones and distributing load automatically. Kubernetes is genuinely more infrastructure than most small projects need — reach for it when you have enough scale and enough services that manual coordination has become the actual bottleneck, not before.
Cloud pricing is usage-based, which is cheap at small scale and can become expensive in ways that are hard to predict — a traffic spike, a misconfigured auto-scaling rule, or an accidentally-public storage bucket serving large files to the whole internet can all produce a surprising bill. Setting billing alerts from day one is one of the highest-value five-minute tasks in any cloud project.
Deploy something real on a PaaS before touching raw infrastructure or containers. The concepts click faster once you've felt the actual problem — a slow database query, a server restart under load, a storage bucket permission — that each piece of "real" cloud infrastructure exists to solve.
Comments