PCA Case Study

Google Cloud – TerramEarth Case Study

~ Last updated on : ~ jayendrapatil ~ 2 Comments

TerramEarth manufactures heavy equipment for the mining and agricultural industries. They currently have over 500 dealers and service centers in 100 countries. Their mission is to build products that make their customers more productive.

Key points here are 500 dealers and service centers are spread across the world and they want to make their customers more productive.

Solution Concept

There are 2 million TerramEarth vehicles in operation currently, and we see 20% yearly growth. Vehicles collect telemetry data from many sensors during operation. A small subset of critical data is transmitted from the vehicles in real time to facilitate fleet management. The rest of the sensor data is collected, compressed, and uploaded daily when the vehicles return to home base. Each vehicle usually generates 200 to 500 megabytes of data per day

Key points here are TerramEarth has 2 million vehicles. Only critical data is transferred in real-time while the rest of the data is uploaded in bulk daily.

Executive Statement

Our competitive advantage has always been our focus on the customer, with our ability to provide excellent customer service and minimize vehicle downtimes. After moving multiple systems into Google Cloud, we are seeking new ways to provide best-in-class online fleet management services to our customers and improve operations of our dealerships. Our 5-year strategic plan is to create a partner ecosystem of new products by enabling access to our data, increasing autonomous operation capabilities of our vehicles, and creating a path to move the remaining legacy systems to the cloud.

Key point here is the company wants to improve further in operations, customer experience, and partner ecosystem by allowing them to reuse the data.

Existing Technical Environment

TerramEarth’s vehicle data aggregation and analysis infrastructure resides in Google Cloud and serves clients from all around the world. A growing amount of sensor data is captured from their two main manufacturing plants and sent to private data centers that contain their legacy inventory and logistics management systems. The private data centers have multiple network interconnects configured to Google Cloud.
The web frontend for dealers and customers is running in Google Cloud and allows access to stock management and analytics.

Key point here is the company is hosting its infrastructure in Google Cloud and private data centers. GCP has web frontend and vehicle data aggregation & analysis. Data is sent to private data centers.

Business Requirements

Predict and detect vehicle malfunction and rapidly ship parts to dealerships for just-in-time repair where possible.

  • ⚠️ Note: Cloud IoT Core was shut down on August 16, 2023. For IoT device connectivity, Google Cloud now recommends a Pub/Sub-based architecture with a standalone MQTT broker (e.g., EMQX, HiveMQ, or ClearBlade IoT Core) for device management and ingestion. The downstream pipeline (Pub/Sub → Dataflow → BigQuery) remains the same.
  • A Pub/Sub-based device messaging architecture with a third-party MQTT broker can provide secure device connectivity, management, and data ingestion from globally dispersed vehicles.
  • Existing legacy inventory and logistics management systems running in the private data centers can be migrated to Google Cloud.
  • Existing data can be migrated one time using Transfer Appliance.

Decrease cloud operational costs and adapt to seasonality.

    • Google Cloud provides configuring elasticity and scalability for resources based on the demand.

Increase speed and reliability of development workflow.

    • Google Cloud CI/CD tools like Cloud Build and Cloud Deploy can be used to increase the speed and reliability of the deployments. Cloud Deploy is a fully managed continuous delivery service for GKE and Cloud Run.

Allow remote developers to be productive without compromising code or data security.

  • Cloud Run functions (formerly Cloud Functions) supports function-to-function authentication for secure internal communication.

Create a flexible and scalable platform for developers to create custom API services for dealers and partners.

  • Google Cloud provides multiple fully managed serverless and scalable application hosting solutions like Cloud Run and Cloud Run functions (formerly Cloud Functions). Cloud Run now supports GPU workloads, worker pools, and deploying via Compose files.
  • Managed Instance group with Compute Engines and GKE cluster with scaling can also be used to provide scalable, highly available compute services.

Technical Requirements

Create a new abstraction layer for HTTP API access to their legacy systems to enable a gradual move into the cloud without disrupting operations.

    • Google Cloud API Gateway & Cloud Endpoints can be used to provide an abstraction layer to expose the data externally over a variety of backends. Cloud Endpoints now supports OpenAPI 3.0 specifications.

Modernize all CI/CD pipelines to allow developers to deploy container-based workloads in highly scalable environments.

Google Cloud CI/CD - Continuous Integration Continuous Deployment

    • Google Cloud provides DevOps tools like Cloud Build and Cloud Deploy (fully managed continuous delivery) to provide CI/CD features. Spinnaker remains supported as an open-source option for multi-cloud deployments.
    • ⚠️ Update: Cloud Source Repositories reached end-of-sale on June 17, 2024 and is no longer available to new customers. Secure Source Manager is the recommended replacement — a regionally deployed, single-tenant managed source code repository on Google Cloud.
    • Cloud Build is a fully-managed, serverless service that executes builds on Google Cloud’s infrastructure.
    • ⚠️ Update: Container Registry was shut down on March 18, 2025. Artifact Registry is the required replacement, supporting both container images and non-container artifacts (Maven, npm, Python, etc.).
    • Artifact Registry is the single artifact management service for container images, language packages, and OS packages on Google Cloud.
    • Cloud Deploy is a fully managed continuous delivery service that automates delivery to GKE and Cloud Run with promotion sequences, deploy policies, canary deployments, and automated rollbacks.

Allow developers to run experiments without compromising security and governance requirements

    • Google Cloud Deploy supports canary deployments and automated rollbacks. Cloud Run provides traffic splitting for A/B testing and gradual rollouts.

Create a self-service portal for internal and partner developers to create new projects, request resources for data analytics jobs, and centrally manage access to the API endpoints.

Use cloud-native solutions for keys and secrets management and optimize for identity-based access

    • Google Cloud supports Cloud Key Management Service (Cloud KMS) and Secret Manager for managing secrets and key management. Cloud KMS now supports quantum-safe key encapsulation mechanisms, and Secret Manager supports integrated secret synchronization with GKE clusters.

Improve and standardize tools necessary for application and network monitoring and troubleshooting.

    • Google Cloud provides Cloud Operations Suite (Google Cloud Observability) which includes Cloud Monitoring and Logging to cover both on-premises and Cloud resources.
    • Cloud Monitoring collects measurements of key aspects of the service and of the Google Cloud resources used. It now integrates with App Hub for Application Monitoring dashboards with trace span visibility.
    • Cloud Monitoring Uptime check is a request sent to a publicly accessible IP address on a resource to see whether it responds.
    • Cloud Logging is a service for storing, viewing, and interacting with logs.
    • Error Reporting aggregates and displays errors produced in the running cloud services.
    • Cloud Profiler helps with continuous CPU, heap, and other parameters profiling to improve performance and reduce costs.
    • Cloud Trace is a distributed tracing system that collects latency data from the applications and displays it in the Google Cloud Console.
    • ⚠️ Update: Cloud Debugger was shut down on May 31, 2023. For production debugging capabilities, use Snapshot Debugger (open-source) or Cloud Logging and Cloud Trace for troubleshooting.

Reference Cellular Upload Architecture

Batch Upload Replacement Architecture

Key Updates for Certification Exam (2024-2026)

The TerramEarth case study remains part of the Professional Cloud Architect certification exam. When answering exam questions related to this case study, keep the following service changes in mind:

  • IoT Device Connectivity: Cloud IoT Core is no longer available. Use Pub/Sub with a standalone MQTT broker for device telemetry ingestion.
  • CI/CD Pipeline: Cloud Deploy is the preferred managed CD solution. Container Registry has been replaced by Artifact Registry. Cloud Source Repositories is replaced by Secure Source Manager.
  • Serverless: Cloud Functions is now Cloud Run functions, unified under the Cloud Run platform.
  • Observability: Cloud Debugger is no longer available. Use Cloud Trace, Cloud Logging, and Snapshot Debugger instead.
  • Security: Cloud KMS now supports quantum-safe encryption. Secret Manager supports GKE secret synchronization.

Reference

Google Cloud – Mountkirk Games Case Study

~ Last updated on : ~ jayendrapatil ~ 2 Comments

Google Cloud – Mountkirk Games Case Study

Mountkirk Games makes online, session-based, multiplayer games for mobile platforms. They have recently started expanding to other platforms after successfully migrating their on-premises environments to Google Cloud. Their most recent endeavor is to create a retro-style first-person shooter (FPS) game that allows hundreds of simultaneous players to join a geo-specific digital arena from multiple platforms and locations. A real-time digital banner will display a global leaderboard of all the top players across every active arena.

Solution Concept

Mountkirk Games is building a new multiplayer game that they expect to be very popular. They plan to deploy the game’s backend on Google Kubernetes Engine so they can scale rapidly and use Google’s global load balancer to route players to the closest regional game arenas. In order to keep the global leader board in sync, they plan to use a multi-region Spanner cluster.

So the key here is the company wants to deploy the new game to Google Kubernetes Engine exposed globally using a Global Load Balancer and configured to scale rapidly and bring it closer to the users. Backend DB would be managed using a multi-region Cloud Spanner cluster.

Executive Statement

Our last game was the first time we used Google Cloud, and it was a tremendous success. We were able to analyze player behavior and game telemetry in ways that we never could before. This success allowed us to bet on a full migration to the cloud and to start building all-new games using cloud-native design principles. Our new game is our most ambitious to date and will open up doors for us to support more gaming platforms beyond mobile. Latency is our top priority, although cost management is the next most important challenge. As with our first cloud-based game, we have grown to expect the cloud to enable advanced analytics capabilities so we can rapidly iterate on our deployments of bug fixes and new functionality.

So the key points here are the company has moved to Google Cloud with great success and wants to build new games in the cloud. Key priorities are high performance, low latency, cost, advanced analytics, quick deployment, and time-to-market cycles.

Business Requirements

Support multiple gaming platforms.

Support multiple regions.

Support rapid iteration of game features.

  • Can be handled using Terraform with Infrastructure Manager (IaC) to automate infrastructure provisioning
  • Cloud Build + Cloud Deploy can be used for rapid continuous integration and deployment to GKE

Minimize latency

  • can be reduced using a Global HTTP load balancer, which would route the user to the closest region
  • using multi-regional resources like Cloud Spanner would also help reduce latency
  • using Agones with GKE for dedicated game server hosting would optimize player-to-server latency

Optimize for dynamic scaling

  • can be done using GKE Cluster Autoscaler and Horizontal Pod Autoscaling to dynamically scale the nodes and applications as per the demand
  • GKE Autopilot can simplify cluster management with automatic node provisioning and scaling
  • Cloud Spanner can be scaled dynamically with autoscaling (available since 2023)
  • Agones Fleet Autoscaler can dynamically scale game server fleets based on player demand

Use managed services and pooled resources.

  • Using GKE (Standard or Autopilot mode), with Global Load Balancer for computing and Cloud Spanner would help cover the application stack using managed services
  • Agones on GKE Autopilot eliminates the need to manage Kubernetes node pools for game servers

Minimize costs.

  • Using minimal resources and enabling auto-scaling as per the demand would help minimize costs
  • GKE Autopilot with Agones helps minimize costs by automatically right-sizing resources
  • Cloud Spanner Standard edition provides cost-effective option for development and testing environments

Existing Technical Environment

The existing environment was recently migrated to Google Cloud, and five games came across using lift-and-shift virtual machine migrations, with a few minor exceptions. Each new game exists in an isolated Google Cloud project nested below a folder that maintains most of the permissions and network policies. Legacy games with low traffic have been consolidated into a single project. There are also separate environments for development and testing.

Key points here are the resource hierarchy exists with a project for each new game under a folder to control access using Service Control Permissions. Also, some of the small games would be hosted in a single project. There are also different environments for development, testing, and production.

Technical Requirements

Dynamically scale based on game activity.

  • can be done using GKE Cluster Autoscaler and Horizontal Pod Autoscaling to dynamically scale the nodes and applications as per the demand
  • Agones Fleet Autoscaler can scale game server instances up and down based on active players and buffer capacity

Publish scoring data on a near-real-time global leaderboard.

  • can be handled using Pub/Sub for capturing data and Dataflow for processing the data on the fly i.e real time
  • Cloud Spanner multi-region configuration provides strongly consistent reads for global leaderboard data

Store game activity logs in structured files for future analysis.

  • can be handled using Cloud Storage to store logs for future analysis
  • analysis can be handled using BigQuery either loading the data or using federated data source
  • data can also be stored directly using BigQuery as it would provide a low-cost data storage (as compared to Bigtable) for analytics
  • another advantage of BigQuery over Bigtable in this case its multi-regional, meeting the global footprint and latency requirements

Use GPU processing to render graphics server-side for multi-platform support.

  • GKE supports GPU node pools (NVIDIA T4, L4, A100, H100) for server-side rendering workloads
  • Support eventual migration of legacy games to this new platform.

Key Services & Architecture Patterns (Updated 2025)

Agones – Dedicated Game Server Hosting

Agones is an open-source platform (developed by Google and Ubisoft) built on Kubernetes that simplifies hosting, scaling, and managing dedicated game servers. It is the recommended approach for running multiplayer game servers on GKE.

  • Fleet Management: Manages pools (Fleets) of ready game server instances
  • Fleet Autoscaler: Automatically scales game server fleets based on demand
  • Allocator: Assigns players to available game servers with low latency
  • Multi-cluster: Supports game server allocation across multiple GKE clusters in different regions
  • GKE Autopilot Support: Runs on GKE Autopilot for hands-off node management

For Mountkirk Games, Agones would be ideal for managing the FPS game server instances across multiple regions, handling player allocation to the nearest arena, and scaling based on game activity.

Cloud Spanner Editions (2024)

Cloud Spanner introduced tier-based editions in 2024 providing greater flexibility:

  • Standard: Cost-effective for development, testing, and less demanding workloads
  • Enterprise: Regional and multi-regional configurations with 99.99%+ availability
  • Enterprise Plus: Designed for the most demanding workloads requiring 99.999% availability with multi-region configurations and geo-partitioning

For the global leaderboard requirement, Enterprise Plus edition with multi-region configuration is recommended to provide strongly consistent, low-latency reads globally.

Additional Spanner capabilities added in 2024-2025:

  • Spanner Graph (2024): Native graph support with GQL for relationship queries (e.g., player social graphs, matchmaking)
  • Vector Search: Built-in vector capabilities for similarity search
  • Autoscaling: Automatic compute scaling based on workload demand
  • Won 2025 ACM SIGMOD Systems Award for groundbreaking distributed database contributions

GKE Updates (2024-2026)

  • GKE Autopilot: Fully managed mode with per-pod billing — recommended for game servers with Agones
  • Fleets & Multi-cluster Management: Now included free with GKE Standard for managing game servers across regions
  • Custom Compute Classes: Define specific compute requirements for game server pods
  • Scale: Support for up to 130,000 nodes per cluster
  • GKE Inference Gateway: For AI/ML workloads (player behavior prediction, anti-cheat)

Cloud Deploy for GKE

Cloud Deploy is a fully managed continuous delivery service for GKE and Cloud Run. It provides:

  • Delivery pipelines with promotion across environments (dev → staging → production)
  • Canary and blue/green deployment strategies
  • Rollback capabilities
  • Integration with Cloud Build for CI/CD

This replaces the need for self-managed tools like Spinnaker for continuous deployment to GKE.

⚠️ Deployment Manager Deprecated (EOL: March 31, 2026)

Google Cloud Deployment Manager reached end of support on March 31, 2026. For infrastructure as code, use:

Use the DM Convert tool to migrate existing Deployment Manager configurations to Terraform.

Reference Architecture

Mobile Gaming Analysis Telemetry Solution

Refer to Best Practices for Mobile Game Online Architectures on Google Cloud

Mobile Gaming Analysis Telemetry Solution

Practice Questions

Question 1: Mountkirk Games needs to deploy their FPS game backend to serve players globally with minimal latency. They want to use managed services and scale dynamically. Which combination of services should they use?

  1. Compute Engine MIGs with Global Load Balancer and Cloud SQL
  2. GKE with Agones, Global Load Balancer, and Cloud Spanner (Enterprise Plus, multi-region)
  3. Cloud Run with Cloud Spanner and Cloud CDN
  4. App Engine Flex with Firestore and Cloud Load Balancing
Show Answer

Answer: B. – GKE with Agones provides dedicated game server hosting with fleet autoscaling, the Global Load Balancer routes players to the nearest region, and Cloud Spanner Enterprise Plus with multi-region configuration provides 99.999% availability for the global leaderboard with strongly consistent reads.

Question 2: Mountkirk Games wants to implement rapid iteration of game features with automated deployments to their GKE clusters across multiple environments. Which approach aligns best with Google Cloud managed services?

  1. Deployment Manager with custom templates for each environment
  2. Jenkins on Compute Engine with custom deployment scripts
  3. Cloud Build for CI with Cloud Deploy pipelines for progressive delivery to GKE
  4. Spinnaker on GKE for multi-environment deployments
Show Answer

Answer: C. – Cloud Build provides continuous integration (building and testing), while Cloud Deploy provides fully managed continuous delivery with promotion pipelines across environments (dev → staging → production), canary deployments, and rollback capabilities. Note: Deployment Manager (Option A) reached end of support in March 2026.

Question 3: Mountkirk Games needs to publish scoring data on a near-real-time global leaderboard. Which architecture best meets this requirement?

  1. Write scores directly to Cloud Spanner from game servers
  2. Use Pub/Sub to ingest scoring events, Dataflow for real-time processing and aggregation, and write to Cloud Spanner multi-region for the leaderboard
  3. Store scores in Memorystore (Redis) with periodic batch writes to BigQuery
  4. Use Cloud Functions triggered by Firestore to update a global leaderboard document
Show Answer

Answer: B. – Pub/Sub provides reliable message ingestion at scale, Dataflow processes and aggregates scores in real-time (handling late-arriving data with windowing), and Cloud Spanner multi-region provides strongly consistent global reads for the leaderboard display.

Question 4: Mountkirk Games wants their game servers to dynamically scale based on player activity while minimizing operational overhead. Which approach is recommended?

  1. GKE Standard with manual node pool management and custom autoscaling scripts
  2. GKE Autopilot with Agones and Fleet Autoscaler
  3. Compute Engine Managed Instance Groups with custom game server images
  4. Cloud Run with WebSocket support for real-time game sessions
Show Answer

Answer: B. – GKE Autopilot eliminates node management overhead with per-pod billing, while Agones provides purpose-built game server lifecycle management. The Fleet Autoscaler automatically scales game server instances based on player demand and configurable buffer policies.

Question 5: Mountkirk Games needs to store game activity logs for future analysis. They need a cost-effective solution that supports structured queries. Which approach is most appropriate?

  1. Cloud Bigtable for real-time ingestion and ad-hoc analytics
  2. Cloud Storage (Standard) with BigQuery federated queries for analysis
  3. Ingest through Pub/Sub, process with Dataflow, store in BigQuery for analytics
  4. Firestore in Datastore mode with periodic exports to Cloud Storage
Show Answer

Answer: C. – Pub/Sub handles high-volume log ingestion, Dataflow transforms and enriches the data in streaming or batch mode, and BigQuery provides cost-effective, serverless, multi-regional analytics storage with powerful SQL querying capabilities for future analysis.

Mountkirk Games References

Google Cloud – Dress4win Case Study

~ Last updated on : ~ jayendrapatil

⚠️ Case Study No Longer on Current PCA Exam

The Dress4Win case study has been retired from the Google Cloud Professional Cloud Architect (PCA) exam.

The current PCA exam (v6.1, updated October 2025) uses four case studies: EHR Healthcare, Altostrat Media, Cymbal Retail, and KnightMotives Automotive. All now incorporate AI integration as core business requirements.

This content is maintained for historical reference and as a learning exercise for GCP migration architecture concepts. The architectural patterns discussed remain relevant for real-world cloud migrations.

Dress4Win is a web-based company that helps their users organize and manage their personal wardrobe using a web app and mobile application. The company also cultivates an active social network that connects their users with designers and retailers. They monetize their services through advertising, e-commerce, referrals, and a freemium app model. The application has grown from a few servers in the founder’s garage to several hundred servers and appliances in a colocated data center. However, the capacity of their infrastructure is now insufficient for the application’s rapid growth. Because of this growth and the company’s desire to innovate faster, Dress4Win is committing to a full migration to a public cloud.

The key here is the company wants to migrate completely to public cloud for the current infrastructures inability to scale

Solution Concept

For the first phase of their migration to the cloud, Dress4Win is moving their development and test environments. They are also building a disaster recovery site, because their current infrastructure is at a single location. They are not sure which components of their architecture they can migrate as is and which components they need to change before migrating them.

Key here is Dress4Win wants to move the development and test environments first. And also, they want to build a DR site for their current production site which would continue to be hosted on-premises

Executive Statement

Our investors are concerned about our ability to scale and contain costs with our current infrastructure. They are also concerned that a competitor could use a public cloud platform to offset their up-front investment and free them to focus on developing better features. Our traffic patterns are highest in the mornings and weekend evenings; during other times, 80% of our capacity is sitting idle.

Our capital expenditure is now exceeding our quarterly projections. Migrating to the cloud will likely cause an initial increase in spending, but we expect to fully transition before our next hardware refresh cycle. Our total cost of ownership (TCO) analysis over the next 5 years for a public cloud strategy achieves a cost reduction between 30% and 50% over our current model.

The key here is that the company wants to improve on the application scalability, efficiency (hardware sitting idle most of the time), capex cost reduction, and improve TCO over a period of time

Existing Technical Environment

The Dress4Win application is served out of a single data center location. All servers run Ubuntu LTS v16.04.

Databases:

  • MySQL. 1 server for user data, inventory, static data,
    • MySQL 5.8
    • 8 core CPUs
    • 128 GB of RAM
    • 2x 5 TB HDD (RAID 1)
  • Redis 3 server cluster for metadata, social graph, caching. Each server is:
    • Redis 3.2
    • 4 core CPUs
    • 32GB of RAM
  • MySQL server can be migrated directly to Cloud SQL, which is GCP managed relational database and supports MySQL. For PostgreSQL-compatible workloads requiring higher performance, AlloyDB (GA since 2022) is also an option offering up to 4x throughput vs. standard PostgreSQL.
  • For Redis cluster, Memorystore for Redis or Memorystore for Valkey (GA since 2025, recommended for new deployments) can be used. Valkey is a Redis-compatible open-source fork offering 99.99% SLA, cross-region replication, and supports versions 7.2, 8.0, and 9.0. Memorystore for Redis Cluster remains available for existing Redis workloads.
  • There would be no changes required to support the same.

Compute:

  • 40 Web Application servers providing micro-services based APIs and static content.
    • Tomcat – Java
    • Nginx
    • 4 core CPUs
    • 32 GB of RAM
  • 20 Apache Hadoop/Spark servers:
    • Data analysis
    • Real-time trending calculations
    • 8 core CPUs
    • 128 GB of RAM
    • 4x 5 TB HDD (RAID 1)
  • 3 RabbitMQ servers for messaging, social notifications, and events:
    • 8 core CPUs
    • 32GB of RAM
  • Miscellaneous servers:
    • Jenkins, monitoring, bastion hosts, security scanners
    • 8 core CPUs
    • 32GB of RAM
  • Web Application servers with Java and Nginx can be supported using Compute Engine, Cloud Run (for containerized microservices with automatic scaling), or Google Kubernetes Engine (GKE) (formerly Container Engine) with autoscaling configured. GKE Autopilot mode simplifies cluster management further.
  • Although the core and RAM combination would need a custom machine type, the same be configured or tuned to use an existing machine type
  • Apache Hadoop/Spark servers can be easily migrated to Dataproc (now part of the Managed Service for Apache Spark brand), which provides managed Hadoop and Spark clusters with autoscaling that can reduce VM costs by up to 40%.
  • RabbitMQ messaging service is currently not directly supported by Google Cloud and can be supported either with
    • Cloud Pub/Sub messaging – however this would need changes to the code and would not be a seamless migration. Pub/Sub now also supports streaming ingestion from external sources and export subscriptions to BigQuery/Cloud Storage.
    • Use Compute Engine to host the RabbitMQ servers
  • Jenkins, Bastion hosts, Security scanners can be hosted using Google Compute Engine (GCE). For CI/CD, Cloud Build is also available as a managed alternative to self-hosted Jenkins.
  • Monitoring can be provided using Google Cloud Operations Suite (formerly Stackdriver), which includes Cloud Monitoring, Cloud Logging, Cloud Trace, and Cloud Profiler.

Storage appliances:

  • iSCSI for VM hosts
  • Fiber channel SAN – MySQL databases
    • 1 PB total storage; 400 TB available
  • NAS – image storage, logs, backups
    • 100 TB total storage; 35 TB available
  • iSCSI for VM hosts can be supported using Cloud Persistent Disks (or Hyperdisk for higher performance requirements) as it needs a block level storage
  • SAN for MySQL databases can be supported using Cloud Persistent Disks as it needs a block level storage. However, a single disk cannot scale to 1PB and multiple disks need to be combined to create the storage
  • NAS for image storage, logs and backups can be supported using Cloud Storage which provides unlimited storage capacity. For file-system access (NFS), Filestore provides a managed NFS file server.

Business Requirements

  • Build a reliable and reproducible environment with scaled parity of production.
    • can be handled by provisioning services or using GCP managed services with the same scale as on-premises resources and with Terraform or Infrastructure Manager for creating repeatable deployments
  • Improve security by defining and adhering to a set of security and Identity and Access Management (IAM) best practices for cloud.
    • can be handled using IAM by implemented best practices like least privileges, separating dev/test/production projects to control access
  • Improve business agility and speed of innovation through rapid provisioning of new resources.
    • can be handled using Terraform or Infrastructure Manager for repeatable and automated provisioning of resources
    • deployments of applications and new releases can be handled efficiently using rolling updates, A/B testing, and Cloud Deploy for managed continuous delivery
  • Analyze and optimize architecture for performance in the cloud.
    • can be handled using autoscaling Compute Engine instances based on the demand
    • can be handled using Google Cloud Operations Suite (Cloud Monitoring, Cloud Logging) for monitoring and fine tuning the specs, plus Active Assist recommendations for rightsizing

Technical Requirements

  • Easily create non-production environments in the cloud.
    • most of the services can be created using GCP managed services and the environment creation can be standardized and automated using templates and configurations
  • Implement an automation framework for provisioning resources in cloud.
    • can be handled using Terraform (recommended) or Infrastructure Manager, which provide Infrastructure as Code (IaC) for provisioning resources in cloud. Note: Cloud Deployment Manager reached end of support on March 31, 2026 and should not be used for new projects.
  • Implement a continuous deployment process for deploying applications to the on-premises datacenter or cloud.
    • continuous deployments can be handled using tools like Jenkins available on both the environments, or Cloud Build with Cloud Deploy for GCP-native CI/CD pipelines
  • Support failover of the production environment to cloud during an emergency.
    • can be handled by replicating all the data to the cloud environment and ability to provision the servers quickly.
    • can be handled by using Cloud DNS to repoint from on-premises environment to cloud environment
  • Encrypt data on the wire and at rest.
    • All the GCP services, by default, provide encryption on wire and at rest. Encryption can be performed using Google-managed keys, Customer-Managed Encryption Keys (CMEK) via Cloud KMS, or Customer-Supplied Encryption Keys (CSEK)
  • Support multiple private connections between the production data center and cloud environment.
    • can be handled using Cloud VPN (multiple VPN tunnels with HA VPN for 99.99% SLA) or Dedicated Interconnect/Partner Interconnect connection between the production data center and the cloud environment. For multi-cloud connectivity, Cross-Cloud Interconnect is also available.

Updated GCP Service Mapping (2025-2026)

The following table summarizes the recommended GCP services for the Dress4Win migration, reflecting current service names and availability:

  • Relational Database: Cloud SQL (MySQL/PostgreSQL) or AlloyDB (for PostgreSQL-compatible high-performance workloads)
  • In-Memory Cache: Memorystore for Valkey (recommended for new deployments, 99.99% SLA) or Memorystore for Redis Cluster
  • Web Application Hosting: GKE (Google Kubernetes Engine), Cloud Run, or Compute Engine
  • Big Data/Analytics: Dataproc (Managed Service for Apache Spark) with autoscaling, or BigQuery for analytics
  • Messaging: Cloud Pub/Sub (managed) or self-hosted RabbitMQ on Compute Engine
  • Monitoring: Google Cloud Operations Suite (Cloud Monitoring, Cloud Logging, Cloud Trace)
  • IaC/Provisioning: Terraform or Infrastructure Manager (NOT Cloud Deployment Manager — deprecated)
  • CI/CD: Cloud Build + Cloud Deploy, or Jenkins on Compute Engine
  • Block Storage: Persistent Disk or Hyperdisk
  • Object/File Storage: Cloud Storage (objects), Filestore (NFS)
  • Networking: HA Cloud VPN, Dedicated/Partner Interconnect, Cross-Cloud Interconnect
  • Encryption: Google-managed keys, CMEK (Cloud KMS), or CSEK

References