Cloud infrastructure from
deployment to operations

Infrastructure work goes wrong in a predictable order. The platform is chosen before the workload is understood, environments drift because they were created by hand, and the first real incident reveals that nobody can answer whether the system is broken or merely slow.

None of those are platform problems. They are sequencing problems.

Start from the workload

Before any provider decision, a handful of properties determine most of the architecture:

• Traffic shape. Steady throughput and spiky event-driven load lead to different compute choices.
• State. What must be durable, what must be consistent, and what can be rebuilt.
• Latency budget. Where the user is, and how much round-trip time the interaction tolerates.
• Data residency and compliance. Often the single hardest constraint, and the one discovered last.
• Recovery objectives. How much data you can lose and how long you can be down — stated as numbers, agreed with the business.

Answer those and the platform question mostly answers itself. Skip them and you get a migration eighteen months later.

Responsibilities stay constant; services do not

A reference architecture is more useful as a set of responsibilities than as a vendor diagram. The layers below hold on every major platform. What changes underneath them is the managed service, and occasionally the shape of a layer.

As an illustration of the mapping, an edge layer is CloudFront and AWS WAF on AWS, Front Door and Azure WAF on Azure, Cloud CDN and Cloud Armor on Google Cloud. The responsibility is identical; only the implementation moves.

Some layers genuinely differ. On Azure, Entra ID usually already exists in the estate, so identity anchors the design from the start rather than being added at the end. On Google Cloud, if reporting is part of the brief, BigQuery belongs in the data layer on day one instead of being bolted on.

Infrastructure as code, or environment drift

There is no third option. Any environment created through a console will diverge from the others, and the divergence will be discovered during an incident.

Practical requirements, in order of how often they are skipped:

• The same definitions produce development, staging, and production — differing only in parameters.
• State is stored remotely and locked, so two engineers cannot apply simultaneously.
• Plan output is reviewed before apply. A plan that nobody reads is a deployment with extra steps.
• Manual console changes are treated as incidents to be reconciled, not as normal operations.

Release, and the way back

A deployment pipeline is judged by its worst day. The question is not how quickly it ships but how quickly it stops shipping and reverts.

That requires a few things to be true simultaneously: artifacts are immutable and versioned, so the previous release still exists; database migrations are backward-compatible for at least one version, so application rollback does not require schema rollback; and the rollback path is exercised, not assumed. A runbook step that has never been run is a hypothesis.

Observability tied to symptoms

Dashboards full of CPU graphs do not shorten incidents. Alerts should map to conditions a user would notice: elevated error rate on a critical path, latency past the agreed budget, a queue growing faster than it drains, a scheduled job that did not run.

Two properties matter more than tooling. Every alert names an owner and links to a runbook. And anyone on call can answer is it broken? within about a minute — if they cannot, the platform is not finished regardless of how much telemetry it emits.

Migration and modernization

Lift-and-shift moves the problem and the bill. Rewriting everything before moving rarely survives contact with a delivery schedule. The pragmatic path is to move the workload with minimal change, instrument it properly, then modernize the parts the telemetry shows are actually expensive or fragile.

Sequencing that works in practice: establish the landing zone and identity model first; move stateless services; move data with a tested restore, not an assumed one; cut over behind the edge layer so rollback is a routing change; then decommission — deliberately, because forgotten environments are a recurring cost and security line item.

Hybrid, when it is a real requirement

Hybrid is a legitimate design when regulation, latency, or an existing system of record requires data to stay in a specific place. It is a poor default chosen to avoid a decision.

When it is real, the seam is the design. A message broker of record sits between environments, everything crossing it is asynchronous and replayable, and identity is federated rather than duplicated. Synchronous cross-environment calls on a critical path turn two systems into one system with twice the failure modes.

Security as a property of the platform

Least-privilege roles issued to workloads rather than to long-lived keys. Secrets in a managed store with rotation. Network paths that are explicit. Audit logging that is enabled before you need it, since it cannot be enabled retroactively.

None of this is exotic. It is simply easier to build in at the landing-zone stage than to retrofit across a running estate.

The through-line

Design around the workload, express the result as code, make releases reversible, and instrument for the questions people actually ask during an incident. The platform decision matters less than most vendor material suggests — and it is far easier to change when the first four are in place.

This is the approach we take in Cloud Infrastructure work. The cost consequences of these same decisions are the subject of FinOps as an engineering discipline.