The cloud is someone else’s hardware wrapped in APIs, billing meters, and managed services. Its real value is not avoiding servers. It is choosing what you operate, where it can fail, and how quickly you can replace it.
🎙️ Published & recorded: ·
A region is a geographic market containing multiple isolated availability zones. A zone is one or more data centers with separate power, cooling, and networking. Providers connect zones with fast private links, but latency and transfer charges still exist. Choose a region for users, data residency, service availability, and recovery needs. Choose zones to survive a local facility failure.
Region: eu-west
Availability Zone A: web-1, database replica A
Availability Zone B: web-2, database replica B
Availability Zone C: spare capacity or third replica
Single-zone app → zone outage can stop the service
Multi-zone app → needs load balancing and replicated state
Multi-region app → needs explicit data and failover designInfrastructure as a service gives you virtual machines, disks, and networks. Platform services manage more of the runtime, deployment, scaling, or database. Software as a service gives you the finished application. Every step upward removes control and operational work together. The right question is not “Which is most cloud native?” It is “Which undifferentiated work can we safely stop owning?”
On-premises: hardware + network + OS + runtime + app + data
IaaS: network + OS + runtime + app + data
PaaS: app + data + configuration
SaaS: users + configuration
# Ownership never disappears completely
You still own: identity, data classification, access decisions,
configuration, monitoring, recovery tests, and your application code.My default for a small team is a managed database and the simplest managed compute that meets the workload. Running a database on a hand-built VM is not a badge of engineering seriousness. Do it only when a requirement justifies patching, replication, backups, failover, and recovery yourself.
A virtual machine behaves like a computer with virtual CPU, memory, network interfaces, and disks. It suits legacy software, unusual operating-system requirements, long-running processes, and workloads needing kernel or host control. It also makes your team responsible for images, patches, process supervision, disk growth, certificates, and replacement.
# VM bootstrap should be repeatable, not a shell history
1. Launch from a versioned image
2. Attach a machine role, never a copied user key
3. Fetch configuration and secrets at runtime
4. Start under a process supervisor
5. Emit logs and health signals centrally
6. Replace the VM to test reproducibility
# Useful Linux evidence
systemctl status my-app
journalctl -u my-app --since "15 minutes ago"
df -h
ss -lntpA container image packages an application and its user-space dependencies. Containers share the host kernel, start quickly, and make deployment artifacts consistent. A container service or orchestrator schedules them, checks health, replaces failures, and can scale replicas. It does not make state, networking, security, or debugging disappear.
# Build once; identify the immutable artifact
docker build -t registry.example.com/orders:git-a1b2c3 .
docker push registry.example.com/orders:git-a1b2c3
# Runtime rules
listen on 0.0.0.0:$PORT
write logs to stdout/stderr
store durable data outside the writable container layer
handle SIGTERM and stop before the platform deadline
expose separate liveness and readiness signalsError response from daemon: pull access denied for orders, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. One: record the exact registry, repository, and tag the deployment requests. Two: verify that exact image was pushed. Three: test registry authentication using the workload identity, not your laptop login. Four: grant read access only to that repository. Five: redeploy by immutable digest and inspect the pulled digest. Rebuilding as latest makes the evidence worse.Serverless functions and managed runtimes start code in response to requests or events. The provider handles machine allocation and scales instances within configured limits. You pay by request and execution for many products. This is excellent for bursty APIs, webhooks, queues, scheduled jobs, and glue code. It is poor for a steady workload that needs special hosts, long execution, or predictable low latency at all times.
Design each invocation as disposable:
input event → validate → perform idempotent work → record result
Keep outside the instance:
- durable state
- job ownership
- secrets
- retry counters
Configure explicitly:
- timeout
- memory and CPU allocation
- maximum concurrency
- retry policy and dead-letter destination
- warm or provisioned capacity when latency demands itCold starts are only one issue. Database connection storms, duplicate delivery, hidden retries, and runaway concurrency cause more painful incidents. Make handlers idempotent. Bound concurrency before downstream services collapse. Put a deadline on every network call. Serverless removes host maintenance, not systems design.
Object storage keeps named blobs behind an API. It is the default for uploads, backups, logs, static assets, and data lakes. Block storage presents a disk to a machine and suits operating systems and databases. File storage presents shared directories and familiar file operations. Choose by access pattern, consistency, latency, sharing, durability, and recovery, not by which product name you remember.
Object: bucket/key → GET, PUT, LIST
use for: photos, archives, artifacts, backups
Block: volume → filesystem → one or limited hosts
use for: VM boot disk, database data volume
File: share/path → concurrent filesystem clients
use for: shared content, legacy file workflows
# A backup policy needs all four
frequency + retention + separate failure boundary + restore testA virtual network contains address ranges and subnets. Route tables choose where packets go. An internet gateway or public load balancer accepts public traffic. A NAT gateway gives private workloads outbound access without accepting unsolicited inbound connections. Security groups and firewall rules decide which flows are allowed. DNS gives stable names to changing addresses.
internet
↓ HTTPS :443
public load balancer [public subnets, zones A and B]
↓ app port
application replicas [private subnets, zones A and B]
↓ database port only
database [private subnets, no public address]
Outbound from private subnet:
private route → NAT gateway → internet gateway → destinationconnect ETIMEDOUT 10.0.3.24:5432. One: run the test from the failing workload and confirm the resolved address and port. Two: check the destination is listening on the private interface. Three: inspect source and destination security rules for TCP port five thousand four hundred thirty-two. Four: inspect subnet routes and network ACL return traffic. Five: use flow logs or packet counters to find the rejecting boundary. Opening the database to the whole internet is not a diagnostic step.Identity and access management combines a principal, an action, a resource, and conditions. Humans should use federated identities with strong authentication. Workloads should use short-lived machine identities attached by the platform. Policies should grant the smallest useful permission. Long-lived access keys copied into source files or VM environment files are avoidable liabilities.
Decision = principal + action + resource + conditions
Example intent:
principal: orders-production workload
allow: object:Get
resource: receipts-production/*
condition: request comes through approved network endpoint
Do not grant:
principal: every workload
allow: *
resource: *An error occurred (AccessDenied) when calling the GetObject operation: Access Denied. One: identify the principal from workload identity logs; do not assume your shell identity. Two: record the exact action and object resource. Three: evaluate identity policy, resource policy, explicit denies, organization controls, and key permissions. Four: add the narrow missing grant or correct the resource path. Five: retry as the workload and review the audit event. Administrator access hides the cause and creates a larger incident later.Cloud bills combine provisioned capacity, execution time, storage, operations, support, public addresses, managed control planes, and data transfer. Small hourly amounts become real monthly commitments. Data moving between zones, regions, or out to the internet can dominate a design that looked cheap on a compute calculator.
Before launch, estimate:
compute hours or request volume
+ database instances, replicas, storage, and backups
+ object operations and retained versions
+ inter-zone, inter-region, and internet transfer
+ load balancers, NAT processing, logs, metrics, support
During operation:
owner tag + service tag + environment tag
budget alerts at useful thresholds
weekly anomaly review
actionable rightsizing, not automatic blind downsizingHigh availability means the service keeps working through expected failures. Disaster recovery means you can restore it after a larger loss. Decide the recovery time objective, which is how long restoration may take, and the recovery point objective, which is how much recent data may be lost. Those numbers should drive the architecture and the test.
Workload
[ ] Region chosen for users, law, latency, and service support
[ ] Capacity runs across zones; health checks test real readiness
[ ] Compute is replaceable from versioned artifacts
[ ] Timeouts, retries with jitter, and concurrency are bounded
Data
[ ] Replication matches the failure boundary
[ ] Backups are versioned or immutable where needed
[ ] Restore is tested; measured RTO and RPO meet the target
Access and network
[ ] Workloads use short-lived identities and least privilege
[ ] Databases have no unnecessary public path
[ ] Routes, firewall intent, DNS, and certificates are documented
Operations and cost
[ ] Logs, metrics, traces, alerts, owners, and runbooks exist
[ ] Budgets and anomaly alerts reach someone who will act
[ ] Zone loss, bad deploy, expired credential, and restore are drilledDo not begin with multi-region active-active because a diagram looked mature. Start with replaceable compute across zones, a managed data service, tested backups, narrow identities, and observable failure. Add another region when a measured recovery requirement pays for the consistency, routing, operational, and cost complexity.