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

• Google Cloud – Dress4Win case study (legacy – no longer on exam)
• Google Cloud – Professional Cloud Architect Certification
• Google Cloud – PCA Exam Guide (current case studies: EHR Healthcare, Altostrat Media, Cymbal Retail, KnightMotives Automotive)
• Google Cloud – Deployment Manager Deprecation Notice
• Google Cloud – Memorystore for Valkey
• Google Cloud – Managed Service for Apache Spark (Dataproc)