Developer guide

Cloud and production

3 min read

Evolution This page describes how the platform gets from a laptop to a deployment a Partner can rely on. It is about operations, not about the transfer path.

Target topology

The production architecture on Google Cloud is defined before it is built: which services run, how they reach each other, where state lives and where the trust boundaries are. Writing it down first means the infrastructure work implements a decision rather than making one on the way.

The Partner Signer Gateway is the boundary that matters most. It runs in the Partner's own environment, so the platform's cloud account never holds the keys that move the Partner's funds.

Environments

There are two deployed environments beyond the local profiles. A development environment is where components are integrated and exercised together, and a staging environment is meant to differ from production in data and scale, not in shape — a staging environment that is architecturally different does not test the thing that will run.

Infrastructure as code

Environments are described as code, so they can be recreated from scratch, reviewed like any other change, and compared against each other. A manually configured environment cannot be trusted to still match its description a month later.

Observability, backups and restore

Operations that move money need metrics, logs and traces that can answer what happened to a specific operation, not only whether the service was up. Backups are held to a stricter standard than existing: a backup that has never been restored is a hypothesis, so the restore drill is part of the capability rather than a follow-up.

Rollout

Releases reach production progressively, with a rehearsed way back. The point is not to avoid bad releases — it is to make a bad release affect a slice of traffic for a short time instead of everyone until someone notices.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

  • Cloud portability — One chart deploys the suite, and what it needs from a cloud is written as a list of requirements — a container runtime, a managed database, a secret store, a queue — rather than as the name of a provider. The GCP implementation of that list is the first one.

  • GCP staging equivalent to production — A pre-production environment with the same services, the same network topology and the same configuration as a Partner's production deployment, differing only in the volume of data and the scale it runs at.

  • Observability, backups and restore drill — Metrics, logs and traces that let one specific operation be followed across every service. Backups run on a schedule, and restoring them into a clean environment is exercised to confirm that they work.

  • Canary, pause and rollback — A release to a production deployment reaches a fraction of the traffic first and is compared against the previous version before continuing. It can be paused at any point, and going back is a single step that has already been tested.