Google Cloud Dynamic Python Web App

Overview

Google's own Jump Start Solution for a dynamic Python web app: a Django API on Cloud Run with a migration job, Cloud SQL for PostgreSQL, Secret Manager, a Cloud Storage media bucket, Pub/Sub, service accounts and Firebase Hosting for the front end. StackToIT read the Terraform as published by Google Cloud and wrote a STACKIT migration package: 11 units assessed plus 5 decided at plan time, 11 drafted as 10 STACKIT resource blocks that pass OpenTofu validation, the open decisions named with an owner.

What stood out

1. Every unit gets a verdict

   All 11 units are assessed: 6 RECONFIGURE (service accounts, secrets, the media bucket), 2 REPLATFORM (Cloud SQL to STACKIT PostgreSQL Flex, Pub/Sub to STACKIT RabbitMQ), 2 CONTAINERIZE (the Cloud Run service and job to STACKIT Kubernetes Engine) and 1 MANUAL_REVIEW (the Firebase project). 5 more units (three Cloud Build triggers, the Firebase Hosting site and an init service account) exist only if a variable holds at plan time; they are assessed too and marked as such.

2. Serverless becomes containers on Kubernetes

   STACKIT has no Cloud Run, so the API service and the migration job become workloads on a STACKIT Kubernetes Engine cluster. The draft writes the cluster and Kubernetes manifests and asks for the machine type and node counts instead of guessing them.

3. A draft that passes OpenTofu validation

   11 of the 16 units considered are drafted as 10 STACKIT resource blocks with 13 variables; 4 are proposed and switched off until someone decides; the Firebase project is left to the architect. tofu init and tofu validate (OpenTofu 1.13.1) accepted the draft. That is static validation, not a plan against STACKIT.

4. The first required action has an owner

   6 decisions are open. The first is to allow STACKIT APIs that are not generally available (Pub/Sub v1beta for RabbitMQ, Secrets Manager): Owner: Platform Architect. 10 of the 12 automated steps are free of decisions and wait only for values such as project_id; none can run as written, none is approved.

5. The source provider is not pinned

   The repository commits no .terraform.lock.hcl and constrains google to ">= 6, < 8", which excludes the 8.4.0 release the knowledge base was checked against. StackToIT caps every unit at MEDIUM confidence, marks none automation-eligible and names the remedy: commit a lock file.

6. No cost comparison is stated

   The price cache holds no Google Cloud record and no price tool was installed next to the binary. 2 of 8 STACKIT lines are priced (164.67 EUR partial, list prices); the report refuses to call a one-sided subtotal a saving and prints the commands that fill the missing prices.

Source infrastructure

terraform-dynamic-python-webapp is a Google Cloud Jump Start Solution: a Django REST API ("server") on Cloud Run, a Cloud Run job that runs the database migrations, Cloud SQL for PostgreSQL, two Secret Manager secrets (Django settings and admin password), a Cloud Storage bucket for media, a Pub/Sub topic, service accounts for the server, client and automation, Firebase Hosting for the JavaScript client, and Cloud Build triggers used for the first deployment. The estate assessed is its infra/ root module and the registry module it calls.

The estate was assessed exactly as published upstream: nothing in it was edited. Its one required variable without a default, project_id, was given in a variable file holding the single line project_id = "example-project" (an invented name). It ships no .terraform.lock.hcl, so the OpenTofu validation of the source did not run and every unit is capped at MEDIUM confidence; its google constraint ">= 6, < 8" also excludes 8.4.0, the release StackToIT's knowledge base was checked against, so the source provider is UNVERIFIED.

Source visibility as read by StackToIT: Complete. Domains of the 11 units: identity 5, compute 2, platform 1, messaging 1, data 1, storage 1.

Assessment summary

Classification of the 11 units present in the source, as the knowledge base 0.394.0 decided them. The strip shows the share of each class; the legend keeps the classes with zero units so that what did not happen is visible too.

• 0 DIRECT same service, same settings
• 6 RECONFIGURE same kind of service, settings change
• 2 REPLATFORM a different managed service
• 2 CONTAINERIZE packaged into a container first
• 0 REDESIGN no counterpart; the architecture changes
• 1 MANUAL_REVIEW a person decides
• 0 BLOCKED cannot move as it stands

Applications

2 applications proposed by StackToIT from the service structure, none confirmed by a customer: 0 ready · 0 blocked · 0 redesign · 2 not ready.

Cost

No price source for 5 lines (the price cache holds no Google Cloud record and stacktoit-prices was not installed); 6 of 8 STACKIT lines have no price; 13 source resources are outside the model and can carry a charge.

Architecture

Three views StackToIT draws from the same graph: the source as read, the proposed STACKIT target, and the delta between them. The Mermaid sources are published beside the renderings.

Also in the package: data flows, dependencies (Mermaid only), identity (Mermaid only), network security.

Migration readiness

StackToIT states readiness as three measures with their denominators and lists what closes each open item. On this estate the package is Partially executable migration package; the full register is in the report.

Three measures, not one

The plan, step by step

1 record nobody has answered rests on a draft default that no step waits for (the STACKIT region the draft builds in); a person confirms it or changes it.

Open decisions and inputs

The full register is the report's Decisions page; the answer files a customer would fill in are published unanswered under review/. The executive brief restates every figure above with its owner and closing condition.

Generated infrastructure

The STACKIT Terraform draft as StackToIT wrote it: 11 of the 16 units the draft considered (11 present in the source, 5 decided only when OpenTofu plans) have a generated resource; 0 need none and 1 are left to the architect. 13 variables. OpenTofu static validation PASSED. It is a draft for an architect, validated against the provider schema, never planned against a live project. Each file opens in a read-only viewer; the raw file is linked from there.

• README.md21.7 KB
• data.tf2.8 KB
• handover/bucket-media/data-copy.md17.6 KB
• handover/cluster-access/kubeconfig.md5.2 KB
• handover/database-postgres/data-move.md45.0 KB
• identity.tf10.1 KB
• kubernetes/migrate/manifests.yaml5.8 KB
• kubernetes/server/manifests.yaml10.8 KB
• kubernetes.tf3.5 KB
• messaging.tf1.0 KB
• proposals/proposal_activategcb/main.tf4.0 KB
• proposals/proposal_activategcb/variables.tf431 B
• proposals/proposal_activategcb/versions.tf231 B
• proposals/proposal_automation/main.tf3.0 KB
• proposals/proposal_automation/variables.tf429 B
• proposals/proposal_automation/versions.tf231 B
• proposals/proposal_client/main.tf4.6 KB
• proposals/proposal_client/variables.tf1.8 KB
• proposals/proposal_client/versions.tf231 B
• proposals/proposal_django_admin_password/main.tf12.2 KB
• proposals/proposal_django_admin_password/variables.tf4.0 KB
• proposals/proposal_django_admin_password/versions.tf231 B
• proposals/proposal_django_settings/main.tf12.2 KB
• proposals/proposal_django_settings/variables.tf4.0 KB
• proposals/proposal_django_settings/versions.tf231 B
• proposals/proposal_init/main.tf3.9 KB
• proposals/proposal_init/variables.tf431 B
• proposals/proposal_init/versions.tf231 B
• proposals/proposal_placeholder/main.tf4.0 KB
• proposals/proposal_placeholder/variables.tf431 B
• proposals/proposal_placeholder/versions.tf231 B
• proposals/proposal_server/main.tf3.0 KB
• proposals/proposal_server/variables.tf429 B
• proposals/proposal_server/versions.tf231 B
• proposals.tf20.3 KB
• rabbitmq/apply-topology.sh3.2 KB
• rabbitmq/topology.json219 B
• security.tf5.9 KB
• storage.tf1.8 KB
• terraform.tf700 B
• variables.tf4.2 KB

Plans and documents

• executive/brief.mdexecutive brief
• executive/decisions.mddecision register
• execution/README.mdexecution package
• execution/manual/actions.mdmanual actions
• migration/roadmap.mdroadmap
• migration/data-movement.mddata movement
• console.txtconsole output
• manifest.jsonmanifest

The execution package under execution/ holds the Terraform apply notes, the STACKIT API scripts and the manual actions; migration/ holds the waves, work packages and data-movement plan as CSV, Markdown and JSON.

Full assessment

The Migration Intelligence Workspace is the HTML report StackToIT writes beside its files. Its content is published here unchanged, under one added navigation bar; every link inside it resolves within the package.

View Full Assessment

Pages of the report

• applications
• architecture
• cost
• decisions
• engineering
• evidence
• migration
• operations
• security assurance
• sovereignty
• target fit
• work board

Provenance

What has been established, and what has not

Publication

The output folder is published exactly as StackToIT wrote it. No file was removed, edited or redacted; stacktoit verify passes on the published copy. The source code is not republished here; the links point to the exact upstream revision.