Bank of Anthos: Kubernetes Banking Sample

What Bank of Anthos Simulates

Bank of Anthos is an HTTP-based sample web application that simulates a bank's payment processing network. Users can create artificial bank accounts and complete transactions. The intended audience is developers evaluating how an enterprise application can be organized across Kubernetes and Google Cloud products, including Google Kubernetes Engine, Anthos Service Mesh, Anthos Config Management, Migrate to Containers, Spring Cloud GCP, Cloud Operations, Cloud SQL, Cloud Build, and Cloud Deploy.

The application is a demonstration system rather than a documented banking product. Its service descriptions identify artificial accounts, a simulated transaction network, and a load generator that imitates users. The repository also includes a live demo link, but the README does not describe that deployment as a production service or document operational guarantees. The sample is most useful for studying service boundaries, container deployment, authentication flows, and the relationship between application services and PostgreSQL databases.

The repository is not archived, and the last push was on 2026-10-13. Recent releases include v0.6.11 on 2026-09-18, v0.6.10 on 2026-07-13, and v0.6.9 on 2026-03-11. Those dates indicate repository activity, but they do not by themselves establish production suitability or security.

Frontend, Account, and Ledger Boundaries

The README describes a multi-service application rather than one monolithic process. The `frontend` service is written in Python and exposes an HTTP server for the website. It contains the login, signup, and home pages. The `user-service`, also written in Python, manages user accounts and authentication and signs JWTs used by other services. The `contacts` service stores the list of other accounts associated with a user, which supports the recipient choices in the payment and deposit forms.

The payment path is split across Java services in `src/ledger`. The `ledgerwriter` service accepts and validates incoming transactions before writing them to the ledger. The `balance-reader` service provides an efficient readable cache of user balances read from `ledger-db`. The `transaction-history` service similarly provides a readable cache of past transactions from that database. This separation gives the sample distinct write and read responsibilities, but the README does not document consistency guarantees, retry behavior, transaction isolation, or recovery procedures.

Two PostgreSQL services support the application. `ledger-db` stores the ledger of all transactions and can be pre-populated with transactions for demo users. `accounts-db` stores user accounts and associated data and can be pre-populated with demo users. A Python and Locust `loadgenerator` continuously sends requests to the frontend, periodically creates accounts, and simulates transactions between them. The architecture therefore demonstrates both request-serving workloads and synthetic traffic generation.

GKE Deployment Path

The documented quickstart targets GKE and assumes a Google Cloud project plus a shell environment containing `gcloud`, `git`, and `kubectl`. The first step enables the Google Kubernetes Engine API and sets the project and region. The README uses `us-central1` for the region and requires the project ID to be substituted by the reader.

The documented deployment then creates an Autopilot cluster named `bank-of-anthos`. After creation, the application is applied with `kubectl`, first including the JWT secret manifest and then the main Kubernetes manifest directory. The reader checks the resulting pods with `kubectl get pods`.

The documented deployment does not show how the application is exposed outside the cluster or how the demo user is reached. The README links to a live demo, but the quickstart does not document the corresponding ingress, port-forward, DNS, or access configuration. It also does not describe whether the default deployment is intended for a shared environment. Those omissions matter for a first deployment because a successful manifest application does not necessarily mean the web interface is reachable.

Installing Bank of Anthos on GKE

The following sequence follows the README quickstart. Replace `<PROJECT_ID>` with the Google Cloud project ID before running the commands. The API enablement command prepares the project for GKE operations.

export PROJECT_ID=<PROJECT_ID>
export REGION=us-central1
gcloud services enable container.googleapis.com \
  --project=${PROJECT_ID}

After the project is configured, clone the repository and create the cluster. The README states that cluster creation may take a few minutes.

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos
cd bank-of-anthos/

gcloud container clusters create-auto bank-of-anthos \
  --project=${PROJECT_ID} --region=${REGION} \
  --labels dev-tutorial=bank-of-anthos

Once the cluster exists, apply the JWT secret and the Kubernetes manifests. The second command applies the manifests from the repository's `kubernetes-manifests` directory.

kubectl apply -f ./extras/jwt/jwt-secret.yaml
kubectl apply -f ./kubernetes-manifests

Finally, inspect pod status. After a few minutes, the README says the reader should see pods in a `Running` state, including the frontend, ledger services, account services, and databases.

kubectl get pods

The README does not provide a local installation path, a Docker Compose workflow, or a standalone Java build command for running the whole application outside Kubernetes. The Makefile contains `cluster`, `deploy`, and `deploy-continuous` targets, with deployment based on `gcloud`, `skaffold`, and a project-specific container repository, but the README quickstart does not explain the full prerequisites for those targets.

Configuration and Upgrade Boundaries

The repository layout includes `kubernetes-manifests`, `src`, `extras`, `iac`, Skaffold files, a Maven wrapper, and a Makefile. This indicates several deployment and development paths, but the README does not document all of their configuration keys or the complete build process. The quickstart focuses on applying manifests, while the Makefile's `deploy` target uses `skaffold run` and `deploy-continuous` uses `skaffold dev`.

The sample is licensed under Apache-2.0. That license identifies the permissions and conditions associated with the repository, but adopting the code still requires reviewing the complete `LICENSE` file and any dependency licenses. The application combines Java, Python, PostgreSQL, Kubernetes manifests, and Google Cloud integrations, so a fork may have more upgrade work than a single-service Java project. Changes to service images, database schemas, manifests, and cloud configuration can affect different parts of the deployment.

The release history provides version labels but no documented migration or rollback procedure in the README. The README does not explain how to move an existing deployment to v0.6.11, how database changes are handled, or how to roll back a failed release. The repository has recent activity, including the last push on 2026-10-13, but an upgrade plan still needs to account for persistence and configuration rather than assuming a container image change is sufficient.

Limitations Compared With a Real Banking Backend

Bank of Anthos is explicitly a sample application that simulates payment processing. It should not be treated as evidence that the repository implements the controls required for real financial transactions. The README does not document audit requirements, fraud detection, authorization policy, idempotency, reconciliation, encryption key management, backup procedures, disaster recovery, or regulatory compliance.

The architecture also creates operational questions. `ledgerwriter` validates and writes incoming transactions, while separate readers cache balances and transaction history from `ledger-db`. The README does not state how readers are synchronized with writes or what happens when a write succeeds but a cached value is stale. That omission limits the project's usefulness for evaluating consistency-sensitive payment designs without additional engineering.

A conventional banking backend might instead be evaluated as a hardened, domain-specific system with explicit identity and access controls, auditable state transitions, tested failure handling, and deployment procedures. That is a different engineering objective from a Kubernetes reference application. Bank of Anthos is appropriate for learning how a web application can be split into services and deployed to GKE; it is not a drop-in alternative to a regulated core banking platform.

Editorial conclusion

Adopt it for learning Kubernetes service decomposition and Google Cloud deployment patterns, but not as a production banking platform. Verify the sample's security, data handling, persistence, and operational requirements before adapting its code.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/bank-of-anthos on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases