Deploying to the Cloud

Deployment from an application developer's seat is mostly about making your app portable and configurable, then letting a platform run it.

The twelve-factor app is the checklist most modern platforms assume. The parts that bite: config comes from the environment, not from files checked into the repo, so one artifact runs in every environment. Processes are stateless — anything written to local disk vanishes, because the filesystem is ephemeral and the next request may land on a different instance. Backing services are attached resources, addressed by URL, so swapping a local database for a hosted one is a config change.

Containers package your app with its dependencies into an image, so the thing that ran on your machine is the thing that runs in production. That is immutable infrastructure: you do not patch a running server, you build a new image and replace it. Rollback becomes redeploying the previous image.

Configuration versus secrets. Both come from the environment; only one is safe to log, print in an error, or show in a dashboard. Secrets belong in a managed store with restricted access and rotation, not in the same place as your feature flags.

Scaling. Horizontal scaling adds instances and requires statelessness; vertical scaling makes one instance bigger and eventually runs out of machine. Platforms scale horizontally, which is why session state in memory is the classic thing that breaks on the second instance.

Serverless trades always-on capacity for per-request billing and automatic scaling, at the cost of cold starts — the latency of spinning up an instance that was not already running — and time limits on execution.

Health checks come in two kinds and conflating them causes outages. A liveness probe asks "is this process wedged and in need of a restart?". A readiness probe asks "should this instance receive traffic right now?". An instance warming up is not ready, and restarting it does not help.