Cloud computing changed one thing above all: it turned infrastructure from something you buy and forecast into something you rent and adjust. Instead of ordering servers months ahead of demand, you request compute, storage and networking by API and pay for what you use. Everything else — the pace of experimentation, the shape of engineering teams, the way cost is managed — follows from that.
A short history
The ideas are older than the name. Mainframe time-sharing in the 1960s let many users rent slices of one machine; virtualisation in the 2000s let one physical server host many isolated virtual ones. Amazon Web Services turned that into a product in 2006 with S3 and EC2, and the model spread: Microsoft Azure (2010), Google Cloud Platform (2011), and a long tail of specialised providers. Today the three hyperscalers run the majority of the world's rented compute, and the largest single driver of new capacity is AI training and inference.
The three service models
The classic way to slice cloud services is by how much the provider manages for you.
- Infrastructure as a Service (IaaS) gives you virtual machines, virtual networks, and block or object storage. You assemble them; you patch the operating systems. Maximum control, maximum responsibility.
- Platform as a Service (PaaS) takes the code and runs it. You configure scaling rules and environment variables; the platform handles runtimes, load balancing and rolling updates. Managed databases, message queues and container platforms sit here too.
- Software as a Service (SaaS) is a finished application on subscription — email, CRM, analytics. You customise within the product's limits and never think about servers.
In practice most systems mix all three, and the most consequential decision is usually how far up the stack to go. Managed services cost more per unit and constrain your choices; they also eliminate whole categories of operational work. Serverless is the logical end of that trade.
Migrating and adopting
Moving existing systems is rarely one project. The common strategies, roughly in order of effort and payoff:
- Rehost ("lift and shift"): move the VM as-is. Fast, low risk, and you keep paying for idle capacity you no longer need to own.
- Replatform: swap components for managed equivalents — your self-run PostgreSQL for a managed one, your cron box for a scheduler service.
- Refactor: restructure the application to use cloud-native patterns such as autoscaling, queues and object storage. Highest effort, and where most of the economic benefit actually lives.
- Retire or repurchase: sometimes the honest answer is that the workload should become SaaS, or shouldn't exist.
The technical migration is the easy half. The harder half is cultural: teams need to own their infrastructure as code, deploy continuously, and treat operations as engineering. Organisations that lift-and-shift without changing how they work usually end up with a more expensive data centre.
Security: the shared responsibility model
Providers secure the facilities, hardware and the control plane. Customers secure everything they put on top: identities and permissions, data, application code, network boundaries and configuration. The line moves depending on the service — with a managed database, patching is the provider's problem; with a VM, it's yours — but identity and data are always yours.
The practical baseline is well established: least-privilege access with multi-factor authentication on every human account; encryption in transit and at rest; secrets in a dedicated vault rather than config files; private networking so nothing sensitive is reachable from the internet by default; and automated policy checks in CI that reject misconfigurations before deployment. Nearly every headline cloud breach traces back to a public storage bucket, an over-permissioned role or a leaked key — not a failure by the provider. We cover this in depth in Cloud Security.
Cost management and FinOps
Cloud bills grow quietly. Forgotten test environments, over-provisioned instances, unattached disks, data egress and untagged resources nobody owns can add up to a third of spend. The discipline of managing this — FinOps — blends engineering habits with financial visibility:
- Tag every resource with an owner and purpose, and alert on anything untagged.
- Set budgets with alerts per team, not just for the whole account.
- Match pricing to workload shape: reserved or committed-use discounts for steady baseline, spot/preemptible instances for interruptible batch work, autoscaling for everything bursty.
- Watch egress and cross-region traffic; data movement is frequently the surprise line item.
- Review right-sizing recommendations monthly — the providers' own tools will tell you what's idle.
Hybrid and multi-cloud
Not every workload moves, and not everything that moves goes to one provider. Hybrid architectures keep some systems on-premises — for regulation, data gravity, latency or sunk cost — and connect them to cloud services. Multi-cloud spreads workloads across providers to reduce concentration risk, satisfy customer requirements, or pick a best-fit service (one provider's AI platform, another's data warehouse).
Both are legitimate; both add real overhead in tooling, skills and networking. The mistake is drifting into them by accident. Write down why you span platforms, and revisit the reason yearly. Meanwhile the direction of the industry is steady: more managed services, more serverless, and compute pushed outward to the edge where latency demands it.
- Cloud's core value is elasticity — capacity as a utility rather than a capital purchase.
- Choose how far up the stack to go deliberately; managed services trade control for eliminated toil.
- Security failures in the cloud are overwhelmingly identity and configuration failures on the customer side.
- Cost is a continuous engineering concern, not a quarterly finance surprise.