Mostly harmless, conspicuously useful
The Hitchhiker's Guide to Becoming a Cloud Engineer
A cloud engineer designs, provisions, secures, and operates computing infrastructure that lives in someone else's building, which is a perfectly reasonable arrangement until you remember that the building can evict a region, bill you for the privilege of being evicted, and greet the morning with a service whose name implies permanence but whose status page speaks only in present tense. You learn to translate "we need somewhere to run this" into accounts, networks, identities, storage, compute, and a dashboard of promises that a billing system later audits for optimism. The cloud is not a place; it is a very large number of other people's datacenters, a catalogue of managed services, and a charge that accrues while you sleep. This guide travels from reading one region's price tag to setting organisation-wide platform strategy, with practical stops at provisioning, networking, identity, failure, recovery, cost, and the recurring discovery that a resource marked "available" is merely available to bill. The grand objective is dependable service at a defensible cost; the daily evidence is usually a deployment that converges, an alert that names its cause, and a monthly invoice that fails to surprise anyone except the finance team, who have learned not to be surprised by their lack of surprise.
Level 1 · Novice
Read the region before asking the catalogue to deploy civilisation
You inspect cloud accounts, regions, services, pricing, and documentation without creating resources, learning how a perfectly polite wizard can provision a small fortune before you finish reading its terms.
You begin with read-only artifacts: an account's service catalogue, region list, pricing pages, managed service descriptions, sample architectures, and a billing dashboard expressing recent opinions. A region is a cluster of datacenters a provider operates in a geography; a service is a managed capability the provider sells, priced in units you did not write and cannot negotiate. You review these with developers, security staff, finance, and an experienced engineer so everyone can trace how compute, storage, and network connect before anyone clicks a button whose confirmation dialog is also a purchase order.
Suppose a team wants to run a new reporting job "in the cloud." In a sandbox account with no production access, you read the pricing for two candidate regions, compare on-demand compute to a managed serverless option, estimate monthly hours, and note that egress charges apply whenever data leaves the provider's building, which data tends to do. You record the estimate, assumptions, and the single line item that exceeds all others. One brisk spreadsheet is an anecdote with good posture, not an architecture; but it prevents the team from commissioning a region for a job that runs four minutes a month.
Words from the spaceship manual, translated
- Region
- A set of provider datacenters in one geography, offered as a unit for placing workloads. Resources in different regions can talk to each other, for a price, and at a speed that suggests they are on speaking terms rather than close friends.
- Managed service
- A capability the provider operates on your behalf — compute, storage, databases, queues — priced per use and configured through an API or console. The provider handles the hardware; you handle the consequences of having asked for it.
- Pricing unit
- The measurable increment a provider bills — an hour, a second, a gigabyte-month, a request — and the small print that decides whether "approximately $X" means $X or $X plus a quiet monthly surcharge for optimism.
- Egress
- Data leaving the provider's network for the internet or another cloud, usually billed per gigabyte. The cloud is welcoming on the way in and commemorative on the way out.