App Modernisation Approaches: Refactor, Rehost, Rebuild

Application modernisation refers to the process of adapting existing applications for cloud deployment to leverage cloud benefits like scalability, reliability, and cost efficiency. Google Cloud categorises modernisation into three main approaches: rehost, refactor, and rebuild. These are part of the "6 Rs" of migration (Rehost, Replatform, Refactor, Rearchitect, Retire, Retain), but the GCDL exam focuses on the three active transformation strategies. The choice depends on factors like time-to-market, cost, desired cloud benefits, and organisational readiness.

Rehost involves moving an application from on-premises or another cloud to Google Cloud with minimal changes. The application runs on Compute Engine virtual machines (VMs) or on-premises-equivalent infrastructure. No code changes are made; the application is packaged and migrated as-is. This is the fastest migration path and requires the least effort. It is suitable for:

How it works internally: - The source VM or physical server is imaged using tools like Migrate for Compute Engine (formerly Velostrata) or third-party tools. - The image is transferred to Google Cloud and used to create a Compute Engine instance with equivalent resources (vCPU, memory, disk). - Networking is configured to match on-premises settings (IP addresses, firewall rules, DNS). - The application is tested for functionality; performance tuning may involve adjusting machine types or adding load balancers. - Once validated, traffic is cut over to the cloud instance.

Key components and defaults: - Compute Engine machine types: n1-standard-4 (4 vCPU, 15 GB RAM) is a common starting point. - Persistent disk sizes: defaults to 10 GB for boot disk, but can be resized. - Networking: VPC networks with subnets, firewall rules, and Cloud NAT for outbound internet. - Migrate for Compute Engine supports both agent-based and agentless migration. - Cutover time: typically hours to days depending on data volume.

Verification commands:

# List migrated instances
gcloud compute instances list
# Check instance details
gcloud compute instances describe [INSTANCE_NAME]
# Verify disk size
gcloud compute disks list

Interaction with related technologies: - Cloud Load Balancing can be added to distribute traffic. - Cloud CDN can accelerate content delivery. - Cloud Monitoring and Logging provide observability. - Google Cloud's sole-tenant nodes can be used for licensing compliance.

Refactor involves making moderate changes to an application to take advantage of cloud-managed services without altering the core architecture. Common changes include moving from a self-managed database to a managed service like Cloud SQL or Cloud Spanner, or using Cloud Storage instead of local file systems. Code changes are limited to configuration and driver updates. This approach offers better scalability, reduced operational overhead, and cost savings through managed services.

How it works internally: - Identify components that can be replaced by managed services (e.g., database, message queue, caching). - Modify application configuration to point to the new service endpoints. - Update libraries or drivers if needed (e.g., JDBC driver for Cloud SQL). - Migrate data to the managed service using tools like Database Migration Service or storage transfer. - Test functionality; performance may improve due to managed service optimisations.

Key components and defaults: - Cloud SQL: supports MySQL, PostgreSQL, SQL Server; default tier db-n1-standard-2 (2 vCPU, 7.5 GB RAM). - Cloud Spanner: global, strongly consistent; node count minimum 1. - Cloud Memorystore for Redis: default tier basic, capacity 1 GB. - Cloud Pub/Sub: default topic retention 7 days. - Database Migration Service: supports homogeneous migrations (e.g., MySQL to Cloud SQL MySQL).

Verification commands:

# Check Cloud SQL instances
gcloud sql instances list
# Connect to Cloud SQL via proxy
gcloud sql connect [INSTANCE] --user=root
# Verify Cloud Storage bucket
gsutil ls gs://[BUCKET_NAME]

Interaction with related technologies: - Cloud SQL can be configured with read replicas for scaling. - Cloud Spanner integrates with App Engine and Compute Engine. - Cloud Memorystore can be used as a session store for web applications. - VPC peering is required for private access to managed services.

Rebuild involves redesigning the application architecture to fully leverage cloud-native features like microservices, serverless, containers, and managed services. This often requires rewriting significant portions of code. The result is a highly scalable, resilient, and cost-efficient application. Use cases include:

How it works internally: - Decompose the monolithic application into smaller, independent services (microservices). - Each service is developed, deployed, and scaled independently. - Services communicate via APIs (REST, gRPC) or message queues (Cloud Pub/Sub). - Use containers (Google Kubernetes Engine) or serverless (Cloud Run, Cloud Functions) for deployment. - Data is often moved to managed databases or object storage per service. - Implement CI/CD pipelines using Cloud Build and Cloud Deploy.

Key components and defaults: - Google Kubernetes Engine (GKE): default cluster version latest stable, node pool with e2-medium machines. - Cloud Run: default max instances 100, container concurrency 80. - Cloud Functions: default timeout 60 seconds, memory 256 MB. - Cloud Endpoints for API management. - Cloud Build: default machine type e2-medium, 10-minute timeout.

Verification commands:

# Deploy to Cloud Run
gcloud run deploy [SERVICE] --image gcr.io/[PROJECT]/[IMAGE] --platform managed
# List GKE clusters
gcloud container clusters list
# Invoke Cloud Function
gcloud functions call [FUNCTION_NAME] --data '{"message":"Hello"}'

Interaction with related technologies: - Cloud Load Balancing for ingress traffic to microservices. - Cloud Service Mesh (Anthos) for observability and security. - Cloud CDN for static assets. - Cloud Tasks for asynchronous processing. - Secret Manager for configuration secrets.

| Aspect | Rehost | Refactor | Rebuild | |--------|--------|----------|---------| | Effort | Low | Medium | High | | Time to cloud | Days to weeks | Weeks to months | Months to years | | Code changes | None | Minimal | Significant | | Cloud benefits | Basic (infrastructure) | Moderate (managed services) | Full (scalability, resilience) | | Cost savings | Low (mainly data center exit) | Medium (eliminate self-management) | High (pay-per-use, auto-scaling) | | Risk | Low | Medium | High | | Best for | Legacy apps, quick wins | DB upgrades, middleware | New development, major upgrades |

Choosing the right modernisation strategy is a key decision in cloud adoption. The GCDL exam expects you to match business requirements to the appropriate approach. Remember: rehost for speed, refactor for balance, rebuild for transformation. Use Google Cloud's managed services to maximise benefits at each level.

Enterprise Scenario 1: Data Center Exit for a Retail Company A large retailer needs to close its data center within six months due to lease expiry. They have hundreds of legacy Windows-based applications that are critical but poorly documented. The IT team chooses rehost using Migrate for Compute Engine. They create VM images of each server, transfer them to Google Cloud, and configure equivalent networking. The migration takes 3 months, with cutover occurring over a weekend. Post-migration, they add Cloud Load Balancing and Cloud Monitoring. The main challenge is licensing: some Microsoft SQL Server licenses require dedicated hosts (sole-tenant nodes). Performance is similar to on-premises, but they gain data center exit. Cost savings are minimal initially but they plan to refactor later.

Enterprise Scenario 2: Modernizing a Monolithic CRM A mid-size software company runs a monolithic CRM application on-premises using a self-managed PostgreSQL database. The application is struggling with scaling during peak hours. They choose refactor: move the database to Cloud SQL for PostgreSQL with read replicas, and migrate the application to Compute Engine with autoscaling managed instance groups. Code changes are limited to updating the database connection string and using Cloud SQL Auth proxy. The migration takes 2 months. Cloud SQL handles failover automatically, reducing downtime. They see 30% cost reduction by eliminating DBA overhead and using committed use discounts.

Enterprise Scenario 3: Building a Global E-Commerce Platform A startup wants to launch a globally scalable e-commerce platform. Their existing prototype is a monolithic Node.js app with MongoDB. They choose rebuild: decompose into microservices (user service, product service, order service) using Node.js and deploy on Cloud Run. Data is moved to Firestore and Cloud SQL. They use Cloud Pub/Sub for async communication and Cloud CDN for static assets. The rebuild takes 6 months. The new platform autoscales from zero to thousands of requests per second. Cost is pay-per-use, and they avoid idle capacity. The main challenge is managing distributed transactions and eventual consistency. They use Cloud Tasks for order processing and Cloud Spanner for inventory to ensure strong consistency.

What Goes Wrong When Misconfigured - Rehost: forgetting to update firewall rules leads to connectivity issues. Not resizing disks causes storage bottlenecks. - Refactor: using wrong Cloud SQL tier causes performance degradation or high costs. Not enabling private IP exposes database to internet. - Rebuild: over-engineering microservices leads to complexity. Not setting proper IAM roles causes permission errors. Missing circuit breakers causes cascading failures.