Cloud Application Development

The Order the Work Runs In

The decisions that are expensive to revisit come first: which provider and which region, how tenants are separated, whether the core runs as containers or as functions, and where state lives. Those come out of a short discovery pass against real numbers, and they get written down with the reasoning attached, because everything built later inherits them and somebody will ask in a year why it is this way.

The first thing deployed is deliberately trivial. One request that enters through the real entry point, touches the real data store, returns a real response, and gets there through the same pipeline that will ship every later change. That slice proves the parts nobody demos, which are identity, networking, permissions, and deployment, at a point where there is almost no application code to confuse the diagnosis. Feature work after that is a series of slices through the same path, rather than layers assembled separately and integrated at the end under time pressure.

• Discovery: load shape, the systems it has to call, data that cannot leave a jurisdiction, and the constraints that come from regulation rather than preference.
• Account and environment layout with the identity and permission model, defined as code before anything is created by hand in a console.
• The thin end-to-end slice, deployed through the pipeline, so the first release happens while it is still small enough to debug.
• Feature work in vertical slices, each one deployable on its own and each one behind the same automated checks.
• Load and failure exercises in a non-production environment: peak traffic, a dependency that times out instead of failing outright, an instance that disappears mid-request.
• Handover: the repository, the pipeline configuration, the infrastructure definitions, account access, and a runbook for whichever alerts exist.

What Has to Exist on Your Side

Schedule damage on a cloud build usually comes from access, not from code. Every item below sits behind somebody outside the project: a DNS change waits on whoever holds the domain, a sandbox tenant waits on an identity administrator, and vendor test credentials wait on the vendor's own process. They are worth starting during discovery, when each one costs an email, rather than at integration time, when they block a team that is otherwise ready to work.

Regulated data adds paperwork with its own lead time. If the application will handle protected health information, the Business Associate Agreement with the cloud provider is executed by whoever owns the cloud account, and it covers only the services that provider publishes as HIPAA-eligible, which is a subset of the catalog and varies by region. Cardholder data has the same outline: the provider attests for the infrastructure, and how the application stores and transmits the data is assessed separately, which is an argument for keeping that data inside as few components as possible.

• A decision about which organization's cloud account the resources live in and which billing account they roll up to, settled before the first resource exists rather than renegotiated afterward.
• Control of the DNS zone for the name the application will answer on, or a subdomain delegated to it, since certificate issuance and automated renewal both depend on records there.
• A test tenant in the identity provider when sign-in is federated, plus an administrator who can register an application and consent to the scopes it requests.
• For each system the application has to call, a reachable non-production endpoint and credentials for it, or a written decision that a stub stands in until launch.
• Data that matches production in shape and volume, synthetic where the real thing cannot be used, because a query plan that looks fine over a thousand rows is not evidence about a million.
• One person who can settle a scope question within a day and one who can approve spend, which are frequently not the same person.

The Bill Has Line Items Nobody Estimates

Compute is the number people estimate, and it is usually the one they get closest to. Overruns come from data movement and from observability, both of which track traffic and retention rather than feature count. Two habits carry most of the benefit: tag every resource with an owner and an environment as it is created, because an untagged account can report the total and nothing more useful than that, and leave commitment-based discounts alone until there are months of real usage to commit against, since a one-year or three-year commitment sized against a guess costs more than paying list price.

The items below are worth pricing while the architecture is still on paper, when moving a component into a different subnet or changing a retention setting is a text edit instead of a migration.

• Data leaving the provider network. Inbound transfer is generally free and outbound is billed per gigabyte, so an API that returns large payloads to consumers outside the cloud pays that charge on every response.
• NAT gateways, which carry an hourly charge per gateway plus a per-gigabyte processing charge on everything routed through them, including calls to the provider's own services that a private endpoint could have served instead.
• Cross-zone traffic between components that were spread across availability zones for resilience and then talk to each other on every single request.
• Log and metric ingestion, billed on volume ingested and again on how long it is kept. Debug-level logging left on in production is a recurring charge, not a one-time one.
• Capacity that never scales to zero: load balancers, allocated database instances, reserved concurrency, and non-production environments running through nights and weekends.
• Accumulation nobody deletes: snapshots, old container images, and object versions retained by a versioning setting that was switched on once and never revisited.

The Failures That Only Appear Under Load

Early production incidents on a new cloud system are usually not defects in feature code. They are limits nobody reached during development, and they share a diagnostic signature: the application logs look clean, because whatever failed happened outside the application's own request handling. That is the tell. When a caller reports an error the service has no record of, examine the layers between them before examining the code.

These are the checks that catch most of it, and every one of them is cheaper before launch than after.

• Service quotas. Provider limits are set per account and per region, at defaults chosen for typical use rather than for your launch day. Raising one is a request that goes into a queue, so the reading happens weeks ahead of the traffic, not during it.
• Timeout alignment. If the load balancer's idle timeout is shorter than the application's own, the caller receives a gateway error while the service logs a slow success. Set each layer's timeout slightly longer than the layer it calls, so the innermost one fires first and the error names the real cause.
• Connection budgets. Function-based compute scales out to hundreds of concurrent executions, while a relational database has a fixed maximum connection count tied to its instance size. Without a pooler in front of the database or a concurrency ceiling on the callers, connections start being refused exactly when traffic is highest.
• Recovery amplification. When a failed dependency returns, every waiting client retries at the same moment. Exponential backoff with random jitter spreads that return; backoff without jitter only regroups the clients into fewer, larger spikes.
• Certificate renewal. Automated issuance renews only while its validation method still works, so a DNS validation record removed during an unrelated cleanup breaks a renewal that is not due for months. Alert on days remaining rather than on renewal failure.

When This Is Not the Work to Buy

Some requirements do not justify a build. Where commodity software already covers the process and the gap is configuration rather than function, buying it wins, and the useful engineering question becomes what the integration around it looks like. Where the system is internal, has a bounded and known user count, and has no elasticity requirement at all, a managed host running a single deployable is proportionate: the architecture this page describes starts paying when load varies, when downtime has a cost attached, and when the system has to keep growing after the first release.

The boundary with cloud migration is not whether a system already exists. It is whether its code is coming along. Lifting a running application onto cloud infrastructure keeps the code and changes what it sits on. Replacing that application keeps the data and the business rules and discards the code, which is a new build even though something is running today. Naming which of the two is intended, in writing, prevents a later argument about what finished means, because the two carry different risks and different tests for success.

• A commodity process such as payroll, ticketing, or expense handling, where the requirement differs from what the market already sells by a configuration setting.
• A reporting problem, where the real need is a warehouse and a reporting tool over data you already hold, not an application that draws charts on top of it.
• A single scheduled job. One function on a timer, with logging and an alert, is a complete answer, and wrapping it in an application is the expensive version of the same thing.