Cloud & DevOps engineering on AWS, Google Cloud and Azure

A staging environment is only useful if it is wrong in ways you already know about. If staging runs a different PHP or Node version, a different database engine, a different queue driver or a machine a tenth of the size, then a green result on staging proves very little.

We build staging from the same definition as production and let it differ on purpose, in a short written list rather than by accident.

Everything else is held identical — runtime versions and extensions, cache and queue drivers, web server and PHP-FPM configuration, cron entries, and the deploy process itself. The point is that the release going to production has already been rehearsed on something that behaves like production.

Every unlisted difference is a place where a green staging run means nothing. Where one cannot be removed — a payment provider with no sandbox for a particular flow, an integration with hardware that exists in exactly one place — we say so and test that part deliberately in production behind a feature flag, rather than pretending staging covered it.

A server assembled by hand in a web console is a server nobody can rebuild. Which firewall rule was opened for that one payment integration, which cron entry was added at two in the morning, why the swap file is that size, which package was installed from a third-party repository — all of it lives in one person's memory and leaves when they do.

We describe infrastructure in code instead: the cloud resources declared in version-controlled definition files, and provisioning scripts or images for what runs inside them. The environment becomes a file in your repository, reviewed like any other change, with a history that explains why each rule exists. Rebuilding a machine after an incident, adding a second one, or standing up a separate region for a client with data-residency obligations turns into an ordinary task rather than an archaeological dig.

On a small project this stays deliberately modest: one definition per environment, a variables file for the handful of things that differ, and a plan output reviewed in the pull request before anything is applied. You do not need a platform team to get the benefit.

They get sold as one word, and the difference shows up at the worst possible moment.

• Monitoring is the current state. CPU, memory, disk, queue depth, response times, certificate expiry, and whether the site answers at all from outside your own network.
• Logging is what happened. Application errors with stack traces and request context, web server access logs, slow query logs — retained long enough to investigate a problem that gets reported a week late.
• Alerting is the narrow part that interrupts a human being. It is the only one of the three that costs you something when it is wrong in either direction.

So we keep the alert set deliberately small and make each one answerable: it fires on a symptom a user would actually notice, it reaches a named person or an on-call rotation rather than a shared inbox, and it carries enough context — which host, which endpoint, which error, what changed recently — for someone to start work without opening five dashboards.

Anything that fires regularly and needs no action is either fixed or deleted, because leaving it there is worse than having no alert at all.

If you only ever have one check, make it an external one: a request to a real page, from outside your own network, on a short interval. An unreachable machine is in no position to report that it is unreachable, and an expired certificate or an edited DNS record looks perfectly healthy from the inside.

Autoscaling adds and removes instances behind a load balancer as demand moves. It is the right answer for traffic that genuinely varies — a campaign, a seasonal peak, a service that is quiet overnight — and for surviving the loss of a single machine without anyone noticing.

It also assumes the application can scale horizontally at all. Sessions and uploaded files have to live somewhere shared rather than on local disk, scheduled tasks must not run once per instance, and the database has to absorb the extra connections that arrive with each new node.

We look at the profile before the instance count, and the cheaper answer is often an index, a cache and a queue — the application-side groundwork described on our web development page.

Cloud bills grow by accretion, and the usual sources are repetitive enough to check against a list:

• Instances sized for a launch spike that never came back down.
• Volumes and snapshots left behind by machines terminated months ago.
• Load balancers, NAT gateways and static addresses attached to nothing.
• Logs kept at full verbosity forever in the most expensive storage class.
• Egress — the charge for data leaving the provider, which hides well because no line on the invoice is named after the feature causing it.

Before any of that, one sanity check: open the provider's cost report grouped by service for the last three months and find the largest line. It is often not the one people assume, and tidying the small lines first is how a cost review ends up costing more in effort than it saves.

Then we tag resources so every line has an owner, right-size against measured usage rather than the original guess, apply lifecycle rules to logs, snapshots and backups, and put static assets behind a CDN so origin egress falls. Committed-use or reserved pricing comes last, once the shape of the usage is stable, because committing to the wrong size for a year is an expensive way to save money.