Cloud Infrastructure Platform

What it is

A multi-service architecture running on Google Cloud: containerised services orchestrated by Kubernetes, fronted by an Nginx reverse proxy, with a Prometheus and Grafana stack watching the whole thing. Every piece is declared rather than configured by hand, so the cluster can be described, reviewed and recreated.

The services are independent — each one builds, deploys and scales on its own schedule — but they share the platform concerns: how traffic reaches them, how their health is judged, what happens when they fail, and who finds out.

Deployments that verify themselves

A deployment is not finished when the container starts. It is finished when the container is serving correctly, and those are different events separated by anything from a second to never. Health checks are what close that gap: the orchestrator probes the new instance and only shifts traffic once it answers properly, so a container that boots and immediately fails never receives a request.

That makes rollback a property of the platform rather than an emergency procedure. Because the previous version's definition is still declared and the rollout is incremental, backing out is a state change the orchestrator already knows how to perform — not a scramble to remember what was running an hour ago.

• Rollouts are incremental, so a bad build degrades a fraction of capacity instead of all of it.
• Traffic only reaches an instance that has proven it can serve, not one that has merely started.
• Rollback is a declared previous state, which is why it is fast enough to be the first response rather than the last.

Observability as a precondition, not an addition

Prometheus scrapes metrics from the services and the cluster itself; Grafana turns them into the view you actually look at during an incident; alerting closes the loop so a problem announces itself rather than waiting to be noticed. The ordering matters — instrumentation added after an outage is instrumentation you didn't have during the outage.

The practical test of a monitoring stack is not whether it produces dashboards. It is whether, at the moment something breaks, the dashboard answers the first question you ask. That is what drove which metrics are collected and how they are grouped.

The edge

Nginx sits in front as the only thing exposed: it terminates TLS, balances across service instances, and sets the security headers that are trivial to add centrally and tedious to add in every service. Putting it at the edge means the services behind it can speak plain HTTP on a private network and never need to know about certificates at all.

It is also the right place for the concerns that are genuinely global — request size limits, timeouts, and which hostnames are answered at all. Enforcing those once, in front, beats enforcing them six times inconsistently.