Cloud and production
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.
Defined GCP production architecture — The production topology is written down: which services run, how they talk to each other, where the data lives and which parts run inside the Partner's environment. The infrastructure work implements that document.
Infrastructure as code applied to a project — The development environment is described in infrastructure-as-code files and applied to a real project, so it can be created, destroyed and recreated by running them, and a change to it is reviewed like any other change.
The whole suite deployed in a cloud environment — Every service of the suite — the API, the signer gateway, the portal, the reference Partner and the conversational bot with its dashboard — runs deployed in the development environment, against a managed database, rather than only on a workstation.
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.
Structured logs correlated by operation and tenant — Every service writes structured logs carrying the operation identifier and the tenant, so one operation can be followed across the services it passed through. Keys, tokens, seeds and personal data never reach them.
GCP staging equivalent to production — A pre-production environment with the same services, the same network topology and the same configuration as production, 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 and production — A release reaches a fraction of the traffic first and is compared against the previous version before continuing. If it fails, going back is a single step that has already been tested.