Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Dependency mapping is the process of identifying how different applications, services, and hardware components rely on each other to function correctly. During the assessment phase, architects must build a comprehensive inventory to understand these complex connections. Mapping these relationships is essential for deciding which parts of a system can move to the cloud without accidentally breaking other services that stay behind.
Once dependencies are understood, workloads are organized into migration waves, which are logical groups of applications moved to the cloud in specific stages. These waves are often further divided into smaller move groups or sprints to make the transition more manageable. Organizing workloads by their interdependencies helps minimize service disruptions and ensures that the most complex systems are moved only when the environment is ready.
Choosing the right first-movers is a critical strategy for successful migration sequencing. These are typically low-risk applications with the fewest dependencies that allow technical teams to build their knowledge of Google Cloud. Ideal candidates for the first migration wave include stateless microservices that do not require moving large amounts of local data, non-mission critical workloads such as internal tools or staging environments, and loosely coupled systems that can easily communicate with other parts of the infrastructure over a network.
Network planning and database synchronization also play major roles in determining the migration order. Architects must account for network latency and ensure that data stays consistent between the on-premises site and the new cloud region. Establishing strong connectivity through tools like Cloud Interconnect or Cloud DNS ensures that migrated workloads can still talk to the resources that have not moved yet.
Before the final move, teams should use a Proof of Concept to validate the feasibility and technical requirements of the migration plan. This small-scale test helps identify edge cases and potential hurdles before they affect the entire business. Testing for data completeness and system performance during this stage ensures that the final cutover happens with the lowest possible risk to the organization.
The assessment phase is the first step in creating a successful migration plan. During this time, teams build a comprehensive inventory of all applications and hardware to understand the current environment. They also perform dependency mapping to see how different services communicate and rely on one another. Gaining deep knowledge of these connections helps architects avoid unexpected failures during the move.
Organizations must choose the right migration strategy for each workload based on their specific business goals. Rehosting is a "lift and shift" move of the application exactly as it exists. Replatforming involves making small changes to optimize the workload for the cloud. Refactoring requires changing the code to take full advantage of cloud-native features. Selecting the correct methodology for each batch of work balances the need for speed with the desire for long-term efficiency.
Network planning is a vital part of designing the cloud architecture and ensuring secure connectivity. Architects must set up Virtual Private Clouds and plan for IP address management to prevent overlapping addresses between on-premises and cloud sites. This phase also includes dependency planning, where teams ensure that all connected services are moved in the correct order. A solid network foundation allows for a smooth transition and reliable communication between all moved resources.
A Proof of Concept is a small-scale test used for the validation of migration feasibility. It allows teams to implement workload testing protocols to check performance and scalability in a low-risk environment. These tests help identify potential risks and allow architects to estimate how much downtime might be needed. Rigorous validation testing ensures that the application will function correctly and maintain its integrity after the final move.
The final migration plan organizes the move into batches or waves to keep the project manageable. Each wave contains a move group of related applications that must be transitioned together to maintain service. Every step of the execution phase must have a rollback strategy in case an unanticipated issue occurs. Post-migration validation is the final check to confirm that all data is complete and the new system is healthy.
The first step in moving to the cloud is the Assess Phase, where you build a full inventory of all current workloads and hardware. It is vital to perform dependency mapping to see how different services talk to each other before moving them. This process identifies which applications are loosely coupled and easier to migrate without breaking other systems. Understanding these connections helps you decide the order in which to move your data.
To link your existing data center to Google Cloud, you must choose a Hybrid Connectivity method that fits your needs. Cloud VPN provides a secure connection over the public internet and is often used for lower traffic volumes. Cloud Interconnect offers a direct physical connection to Google Cloud for higher reliability and speed. Cross-Cloud Interconnect allows for private links between different cloud providers like AWS or Azure. Selecting the correct bandwidth ensures that large-scale data transfers do not slow down your business operations.
Network planning requires understanding that while Virtual Private Clouds are global, individual subnets are tied to specific regions. You cannot use the same subnet IP address in two places at once, so you must plan for new IP address ranges to avoid network overlaps. Using Cloud DNS allows you to route traffic to new locations smoothly by using DNS peering or forwarding. This ensures that users can still find your services even after they have moved to a new cloud region.
A successful Migration Plan organizes workloads into migration waves or batches based on their business value and technical difficulty. Prioritizing non-critical workloads first allows your team to build experience before moving mission-critical systems. This strategy reduces the risk of major outages and helps you refine your deployment process over time. Each wave should include a clear rollback strategy in case something goes wrong during the transition.
Before the final move, you should create a Proof of Concept to validate the feasibility of the migration in a test environment. Workload testing includes both functional testing to check if the application works and load testing to ensure it can handle real-world traffic. These tests help you estimate potential downtime and confirm that the new network architecture meets your performance goals. Testing also allows you to find and fix security issues before they affect your production data.
Prepare and test your skills
Prepare and test your skills
Dependency mapping is the process of identifying how different applications, services, and hardware components rely on each other to function correctly, which is essential for deciding which parts of a system can move to the cloud without breaking other services.
Ideal candidates for the first migration wave include stateless microservices, non-mission critical workloads such as internal tools or staging environments, and loosely coupled systems that can easily communicate over a network.
A Proof of Concept is a small-scale test used to validate the feasibility and technical requirements of the migration plan, helping to identify edge cases and potential hurdles before the final move.
Rehosting is a 'lift and shift' move of the application exactly as it exists, replatforming involves making small changes to optimize for the cloud, and refactoring requires changing the code to take full advantage of cloud-native features.
Migrate the downstream analytics and reporting pipelines in Wave 1, point them to write back to the on-premises database, and take offline cold backups during full cutover.
Migrate the database to Google Cloud in Wave 1 using scheduled maintenance exports, while leaving the application tier on-premises connected across public internet endpoints.
Migrate the application tier to Compute Engine in Wave 1 while keeping the database on-premises, using scheduled CSV/JSON flat file batch exports to backfill transactions.
Group the application tier and database into the same migration wave, establish continuous Change Data Capture (CDC) replication to Google Cloud, and cut over both tiers together once replication lag reaches near zero.
An enterprise is planning the migration of a mission-critical three-tier enterprise workload from an on-premises data center to Google Cloud. Architectural dependency mapping reveals the following characteristics:
Preliminary testing shows that splitting the application tier in Google Cloud from an on-premises database introduces unacceptable cross-premises network latency.
Which migration sequencing and data synchronization strategy should the cloud architect recommend?