Build hybrid and multicloud architectures using Google Cloud

Last reviewed 2023-12-14 UTC

This architecture guide is composed of three parts that provide practical guidance on planning and architecting your hybrid and multicloud environments using Google Cloud. The guide begins by examining the opportunities and considerations associated with these architectures from a business and technology point of view. Also, it analyzes and discusses many proven hybrid and multicloud architecture patterns.

The series consists of three documents that discuss various aspects of using hybrid and multcloud architecture patterns:

You can read each of these architecture articles independently, but for the most benefit, we recommend reading them in sequence before making an architectural decision.

The rapid pace of change in market demands has increased the requirements and expectations that are placed on enterprise IT. Many enterprise-level companies find it challenging to meet these demands and expectations using only traditional infrastructure and processes. IT departments are also under pressure to improve their cost effectiveness, making it difficult to justify additional capital investments in data centers and equipment.

A hybrid cloud strategy that uses public cloud computing capabilities provides a pragmatic solution. By using the public cloud, you can extend the capacity and capabilities of your computing platforms without up-front capital investment costs.

By adding one or more public cloud based solutions, like Google Cloud, to your existing infrastructure, you not only preserve your existing investments, but you also avoid committing yourself to a single cloud vendor. Also, by using a hybrid strategy, you can modernize applications and processes incrementally as resources permit.

To help you plan for your architectural decision and hybrid or multicloud strategy planning, there are several potential challenges and design considerations that you should consider. This multi-part architecture guide highlights both the potential benefits of various architectures and the potential challenges.

Overview of hybrid cloud and multicloud

Because workloads, infrastructure, and processes are unique to each enterprise, each hybrid cloud strategy must be adapted to your specific needs. The result is that the terms hybrid cloud and multicloud are sometimes used inconsistently.

Within the context of this Google Cloud architecture guide, the term hybrid cloud describes an architecture in which workloads are deployed across multiple computing environments, one based in the public cloud, and at least one being private—for example, an on-premises data center or a colocation facility.

The term multicloud describes an architecture that combines at least two public CSPs. As illustrated in the following diagram, sometimes this architecture includes a private computing environment (that might include the use of a private cloud component). That arrangement is called a hybrid and multicloud architecture.

Diagram of the three architectures discussed in this series: hybrid, multicloud, and mix of hybrid and multicloud architectures.

Contributors

Author: Marwan Alshawi | Partner Customer Engineer

Other contributors:

Drivers, considerations, strategy, and approaches

This document defines and discusses business objectives, drivers, and requirements, and how these factors can influence your design decisions when constructing hybrid and multicloud architectures.

Objectives

An organization can adopt a hybrid or multicloud architecture either as a permanent solution to meet specific business objectives, or as a temporary state to facilitate certain requirements, such as a migration to the cloud.

Therefore, it's essential to understand:

  • Which business goals are driving the decision to adopt a hybrid or multicloud architecture?
  • What business and technical objectives is a hybrid or multicloud architecture going to help achieve?
  • What business drivers influenced these objectives?
  • What are the specific business requirements?

In the context of hybrid and multicloud architectures, one business goal for an enterprise customer might be to expand online sales operations or markets from a single region to become one of the global leaders in their market segment. One of the business objectives might be to start accepting purchase orders from users across the globe (or from specific regions) within six months.

Answering the preceding questions is a good way to define your business requirements, and to establish specific expectations about how to achieve one or more of your business objectives. These requirements focus on what's needed, not how to achieve it technically. For example, developing a mobile application for users in multiple regions to facilitate faster online ordering aligns with a specific business objective for the enterprise customer mentioned earlier.

To support the previously mentioned business requirements and objectives, one potential primary technical objective is to expand the IT infrastructure and applications architecture of a company from an on-premises-only model to a hybrid architecture, using the global capabilities and services of public clouds. This objective should be specific and measurable, clearly defining the expansion scope in terms of target regions and timelines.

In general, a hybrid or multicloud architecture is rarely a goal in itself, but rather a means of meeting technical objectives driven by certain business requirements. Therefore, choosing the right hybrid or multicloud architecture requires first clarifying these requirements.

It's important to differentiate between the business objectives and technical objectives of your IT project. Your business objectives should focus on the goal and mission of your organization. Your technical objectives should focus on building a technological foundation that enables your organization to meet their business requirements and objectives.

Business drivers influence the achievement of the business objective and goals. Therefore, clearly identifying the business drivers can help shape the business objectives or goals to be more relevant to market needs and trends.

The following flowchart illustrates business drivers, goals, objectives, and requirements, and the technical objectives and requirements, and how all these factors relate to each other:

Flow chart showing things to consider when developing technical requirements, including business drivers, goals, objectives, and requirements, as well as technical objectives.

Business and technical drivers

Consider how your business drivers influence your technical objectives. Some common, influencing, business drivers when choosing a hybrid architecture include the following:

  • Heeding laws and regulations about data sovereignty.
  • Reducing capital expenditure (CAPEX) or general IT spending with the support of cloud financial management and cost optimization disciplines like FinOps.
    • Cloud adoption can be driven by scenarios that help reduce CAPEX, like building a Disaster Recovery solution in a hybrid or multicloud architecture.
  • Improving the user experience.
  • Increasing flexibility and agility to respond to changing market demands.
  • Improving transparency about costs and resource consumption.

Consider your list of business drivers for adopting a hybrid or multicloud architecture together. Don't consider them in isolation. Your final decision should depend on the balance of your business priorities.

After your organization realizes the benefits of the cloud, it might decide to fully migrate if there are no constraints—like costs or specific compliance requirements that require highly secure data to be hosted on-premises—that prevent it from doing so.

Although adopting a single cloud provider can offer several benefits, such as reduced complexity, built-in integrations among services, and cost optimization options like committed use discounts, there are still some scenarios where a multicloud architecture can be beneficial for a business. The following are the common business drivers for adopting a multicloud architecture, along with the associated considerations for each driver:

  • Heeding laws and regulations about data sovereignty: The most common scenario is when an organization is expanding its business to a new region or country and has to comply with new data-hosting regulations.
    • If the existing used cloud service provider (CSP) has no local cloud region in that country, then for compliance purposes the common solution is to use another CSP that has a local cloud region in that country.
  • Reducing costs: Cost reduction is often the most common business driver for adopting a technology or architecture. However, it's important to consider more than just the cost of services and potential pricing discounts when deciding whether to adopt a multicloud architecture. Account for the cost of building and operating a solution across multiple clouds, and any architecture constraints that might arise from existing systems.

Sometimes, the potential challenges associated with a multicloud strategy might outweigh the benefits. A multicloud strategy might introduce additional costs later on.

Common challenges associated with developing a multicloud strategy include the following:

  • Increasing management complexity.
  • Maintaining consistent security.
  • Integrating software environments.
  • Achieving consistent cross-cloud performance and reliability.
  • Building a technical team with multicloud skills might be expensive and might require expanding the team, unless it's managed by a third party company.
  • Managing the product pricing and management tools from each CSP.
  • Using the unique capabilities from each CSP: A multicloud architecture enables organizations to use additional new technologies to improve their own business capability offerings without being limited to the choices offered by a single cloud provider.
    • To avoid any unforeseen risk or complexity, assess your potential challenges through a feasibility and effectiveness assessment, including the common challenges mentioned previously.
  • Avoiding vendor lock-in: Sometimes, enterprises want to avoid being locked into a single cloud provider. A multicloud approach lets them choose the best solution for their business needs. However, the feasibility of this decision depends on several factors, such as the following:
    • Technical dependencies
    • Interoperability considerations between applications
    • Costs of rebuilding or refactoring applications
    • Technical skill sets
    • Consistent security and manageability
  • Enhancing the reliability and availability level of business critical applications: In some scenarios, a multicloud architecture can provide resilience to outages. For example, if one region of a CSP goes down, traffic can be routed to another CSP in the same region. This scenario assumes that both cloud providers support the required capabilities or services in that region.

When data residency regulations in a specific country or region mandate the storage of sensitive data—like personally identifiable information (PII)—within that location, a multicloud approach can provide a compliant solution. By using two CSPs in one region to provide resilience to outages, you can facilitate compliance with regulatory restrictions while also addressing availability requirements.

The following are some resilience considerations to assess before adopting a multicloud architecture:

  • Data movement: How often might data move within your multicloud environment?
    • Might data movement incur significant data transfer charges?
  • Security and manageability: Are there any potential security or manageability complexities?
  • Capability parity: Do both CSPs in the selected region offer the required capabilities and services?
  • Technical skill set: Does the technical team have the skills required to manage a multicloud architecture?

Consider all these factors when assessing the feasibility of using a multicloud architecture to improve resilience.

When assessing the feasibility of a multicloud architecture, it's important to consider the long-term benefits. For example, deploying applications on multiple clouds for disaster recovery or increased reliability might increase costs in the short term, but could prevent outages or failures. Such failures can cause long-term financial and reputational damage. Therefore, it's important to weigh short-term costs against the long-term potential value of adopting multicloud. Also, the long-term potential value can vary based on the organization size, technology scale, criticality of the technology solution, and the industry.

Organizations that plan to successfully create a hybrid or multicloud environment, should consider building a Cloud Center of Excellence (COE). A COE team can become the conduit for transforming the way that internal teams within your organization serve the business during your transition to the cloud. A COE is one of the ways that your organization can adopy the cloud faster, drive standardization, and maintain stronger alignment between your business strategy and your cloud investments.

If the objective of the hybrid or multicloud architecture is to create a temporary state, common business drivers include:

  • The need to reduce CAPEX or general IT spending for short-term projects.
  • The ability to provision such infrastructure quickly to support a business use case. For example:
    • This architecture might be used for limited-time projects. It could be used to support a project that requires a high scale distributed infrastructure within a limited duration, while still using data that is on-premises.
  • The need for multi-year digital transformation projects that require a large enterprise to establish and that use a hybrid architecture for some time to help them align their infrastructure and applications modernization with their business priorities.
  • The need to create a temporary hybrid, multicloud, or mixed architecture after a corporate merger. Doing so enables the new organization to define a strategy for the final state of its new cloud architecture. It's common for two merging companies to use different cloud providers, or for one company to use an on-premises private data center and the other to use the cloud. In either case, the first step in merger and acquisition is almost always to integrate the IT systems.

Technical drivers

The preceding section discussed business drivers. To get approved, major architectural decisions almost always need the support of those drivers. However, technical drivers, which can be based on either a technical gain or a constraint, can also influence business drivers. In some scenarios, it's necessary to translate technical drivers into business drivers and explain how they might positively or negatively affect the business.

The following non-exhaustive list contains some common technical drivers for adopting a hybrid or multicloud architecture:

  • Building out technological capabilities, such as advanced analytics services and AI, that might be difficult to implement in existing environments.
  • Improving the quality and performance of service.
  • Automating and accelerating application rollouts to achieve a faster time to market and shorter cycle times.
  • Using high-level APIs and services to speed up development.
  • Accelerating the provisioning of compute and storage resources.
  • Using serverless services to build elastic services and capabilities faster and at scale.
  • Using global infrastructure capabilities to build global or multi-regional architectures to satisfy certain technical requirements.

The most common technical driver for both temporary hybrid and temporary multicloud architectures is to facilitate a migration from on-premises to the cloud or to an extra cloud. In general, cloud migrations almost always naturally lead to hybrid cloud setup. Enterprises often have to systematically transition applications and data based on their priorities. Similarly, a short-term setup might be intended to facilitate a proof of concept using advanced technologies available in the cloud for a certain period.

Technical design decisions

The identified technical objective and its drivers are key to making a business-driven architecture decision and to selecting one of the architecture patterns discussed in this guide. For example, to support a specific business goal, a company might set a business objective to build a research and development practice for three to six months. The main business requirement to support this objective might be to build the required technology environment for research and design with the lowest possible CAPEX.

The technical objective in this case is to have a temporary hybrid cloud setup. The driver for this technical objective is to take advantage of the on-demand pricing model of the cloud to meet the previously mentioned business requirement. Another driver is influenced by the specific technology requirements that require a cloud-based solution with high compute capacity and quick setup.

Use Google Cloud for hybrid and multicloud architectures

Using open source solutions can make it easier to adopt a hybrid and multicloud approach, and to minimize vendor lock-in. However, you should consider the following potential complexities when planning an architecture:

  • Interoperability
  • Manageability
  • Cost
  • Security

Building on a cloud platform that contributes to and supports open source might help to simplify your path to adopting hybrid and multicloud architectures. Open cloud empowers you with an approach that provides maximum choice and abstracts complexity. In addition, Google Cloud offers the flexibility to migrate, build, and optimize applications across hybrid and multicloud environments while minimizing vendor lock-in, using best-in-breed solutions, and meeting regulatory requirements.

Google is also one of the largest contributors to the open source ecosystem and works with the open source community to develop well-known open source technologies like Kubernetes. When rolled out as a managed service, Kubernetes can help reduce complexities around hybrid and multicloud manageability and security.

Plan a hybrid and multicloud strategy

The Drivers, considerations, strategy, and approaches page defined and analyzed the different aspects and considerations for planning a hybrid and multicloud strategy from a business point of view. This document focuses on how to apply those aspects when planning a hybrid and multicloud strategy.

Clarify and agree on the vision and objectives

Ultimately, the main purpose of a hybrid or multicloud strategy is to achieve the identified business requirements and the associated technical objectives for each business use case aligned with specific business objectives. To achieve this goal, create a well-structured plan that includes the following considerations:

Know that defining a plan that considers all workloads and requirements is difficult at best, especially in a complex IT environment. In addition, planning takes time and might lead to competing stakeholder visions.

To avoid such situations, initially formulate a vision statement that addresses the following questions (at minimum):

  • What's the targeted business use case to meet specific business objectives?
  • Why is the current approach and computing environment insufficient to meet the business objectives?
  • What are the primary technological aspects to optimize for by using the public cloud?
  • Why and how is the new approach going to optimize and meet your business objectives?
  • How long do you plan to use your hybrid or multicloud setup?

Agreeing on the key business and technical objectives and drivers, then obtaining relevant stakeholder sign-off can provide a foundation for the next steps in the planning process. To effectively align your proposed solution with the overarching architectural vision of your organization, align with your team and the stakeholders responsible for leading and sponsoring this initiative.

Identify and clarify other considerations

While planning a hybrid or multicloud architecture, it's important to identify and agree about the architectural and operational constraints of your project.

On the operations side, the following non-exhaustive list provides some requirements that might create some constraints to consider when planning your architecture:

  • Managing and configuring multiple clouds separately versus building a holistic model to manage and secure the different cloud environments.
  • Ensuring consistent authentication, authorization, auditing, and policies across environments.
  • Using consistent tooling and processes across environments to provide a holistic view into security, costs, and opportunities for optimization.
  • Using consistent compliance and security standards to apply unified governance.

On the architecture-planning side, the biggest constraints often stem from existing systems and can include the following:

  • Dependencies between applications
  • Performance and latency requirements for communication between systems
  • Reliance on hardware or operating systems that might not be available in the public cloud
  • Licensing restrictions
  • Dependence on the availability of required capabilities in the selected regions of a multicloud architecture

For more information about the other considerations related to workload portability, data movement, and security aspects, see Other considerations.

Design a hybrid and multicloud architecture strategy

After you have clarified the specifics of the business and technical objectives with the associated business requirements (and ideally clarified and agreed on a vision statement), you can build your strategy to create a hybrid or multicloud architecture.

The following flowchart summarizes the logical steps to build such a strategy.

When strategizing, consider your business objectives, get buy in, build a high-level plan and then use that to inform your strategy.

To help you determine your hybrid or multicloud architecture technical objectives and needs, the steps in the preceding flowchart start with the business requirements and objectives. How you implement your strategy can vary depending on the objectives, drivers, and the technological migration path of each business use case.

It's important to remember that a migration is a journey. The following diagram illustrates the stages of this journey as described in Migrate to Google Cloud.

Migration path with four phases.

This section provides guidance about the stages in the preceding diagram in the context of a hybrid or multicloud migration that must be aligned with the guidance and best practices discussed in the migration path section of the Migrate to Google Cloud guide. These stages might apply to each workload individually, not to all workloads at once. At any point in time, several workloads might be in different phases:

  1. Assess: Conduct an initial workload assessment. Consider the goals outlined in your vision and strategy planning documents. Decide on a migration plan by first identifying a candidate list of workloads that could benefit from being deployed or migrated to the public cloud.

    1. To start, choose a workload that isn't business-critical or too difficult to migrate (with minimal or no dependencies on any workload in other environments), yet typical enough to serve as a blueprint for upcoming deployments or migrations.
    2. Ideally, the identified workload or application should be part of a targeted business use case or function that has a measurable effect on the business when it's completed.
    3. It's also important to conduct a migration risks assessment as part of this phase to evaluate and mitigate any potential migration risks. These risks can affect the selection of the workload to migrate or to operate in a hybrid or multicloud setup.

    4. With multicloud related migration, it's important to assess your candidate workload to determine its suitability for migration to a multicloud environment. This assessment involves evaluating various aspects of the applications and infrastructure including the following:

      • The compatibility of each application with the cloud services
      • Pricing models
      • Security features offered by the selected cloud providers
      • Applications interoperability requirements

      To help you identify potential challenges, risks, and opportunities that might arise during or after the migration, assess them. Running an assessment also helps you identify data privacy, compliance, and consistency requirements and solutions across multiple cloud environments.

      There are several types of tools, like Google Cloud Migration Center, that can be used to help you with the assessment of the existing workload. For more information, see Migration to Google Cloud: Choose an assessment tool.

      From a workload modernization perspective, the fit assessment tool helps to assess a VM workload to determine if the workload is fit for modernization to a container or for migration to Compute Engine.

  2. Plan: At this stage, start with the identified applications and required cloud workloads and perform the following tasks:

    1. Develop a prioritized migration strategy that defines application migration waves and paths.

    2. Identify the applicable high-level hybrid or multicloud application architecture pattern.

    3. Select a networking architecture pattern that supports the selected application architecture pattern.

      Ideally, the cloud networking pattern should be incorporated with the organization landing zone design. The landing zone design serves as a key foundational element of overall hybrid and multicloud architectures. The design requires seamless integration with these patterns. Don't design the landing zone in isolation. Consider these networking patterns as a subset of the landing zone design.

      A landing zone might consist of different applications, each with a different networking architecture pattern. Also, at this phase, it's important to decide on the design of the Google Cloud organization, projects, and resource hierarchy to prepare your cloud environment landing zone for the hybrid or multicloud integration and deployment.

      As part of this phase you should consider the following:

      • Define the migration and modernization approach. There is more information about migration approaches later in this guide. It's also covered in more detail in the migration types section of Migrate to Google Cloud.
      • Using the assessment and discovery phase findings, and aligned with the selected candidate workload for migration, develop an application migration waves plan. The plan should incorporate the estimated resource sizing requirements in the cloud that you determined during the assessment phase.
      • Define the communication model required between the distributed applications and among application components for the intended hybrid or multicloud architecture.
      • Decide on a suitable deployment archetype to deploy your workload such as zonal, regional, multi-regional, or global for the chosen architecture pattern. The archetype you select forms the basis for constructing the application-specific deployment architectures tailored to your business and technical needs.
      • Decide on measurable success criteria for the migration with clear milestones per migration stage or wave. Selecting criteria is essential even if the technical objective is to have the hybrid architecture as a short term setup.
      • Define application SLAs and KPIs when your applications operate in a hybrid setup, especially for those applications that might have distributed components across multiple environments.
      • For more information, see the migration planning document to plan a successful migration and to minimize the associated risks.

  3. Deploy: At this stage, you should be ready to start executing your migration strategy. Given the potential number of requirements, it's best to take an iterative approach.

    Prioritize your workloads based on the migration and application waves that you developed during the planning phase. With hybrid and multicloud architectures, you should start the deployment by establishing the necessary connectivity between Google Cloud and the other computing environments. To facilitate the required communication model for your hybrid or multicloud architecture, base the deployment on your selected design and network connectivity type, along with the applicable networking pattern. This should also be a part of your overall landing zone design decision.

    In addition, you must test and validate the application or service based on the defined application success criteria. Ideally, these criteria should include both functional and load testing (non-functional) requirements before moving to production.

  4. Optimize: After you complete testing, and the application or service meets the functional and performance capacity expectations, you can move it to production. Cloud monitoring and visibility tools, such as Cloud Monitoring, can provide insights into the performance, availability, and health of your applications and infrastructure and help you optimize where needed. For more information, see Migrate to Google Cloud: Optimize your environment. To learn more about how to design such tools for hybrid or multicloud architecture, see Hybrid and multicloud monitoring and logging patterns.

Assess candidate workloads

The choice of computing environments for different workloads significantly affects the success of a hybrid and multicloud strategy. Workload placement decisions should align with specific business objectives. Therefore, these decisions should be guided by targeted business use cases that enable measurable business effects. However, starting with the most business-critical workload/application isn't always necessary nor recommended. For more information, see Choosing the apps to migrate first in the Migrate to Google Cloud guide.

As discussed in the Business and technical drivers section, there are different types of drivers and considerations for hybrid and multicloud architectures.

The following summarized list of factors can help you evaluate your migration use case in the context of a hybrid or multicloud architecture with opportunities to have a measurable business effect:

  • Potential for market differentiation or innovation that is enabled by using cloud services to enable certain business functions or capabilities, such as artificial intellige capabilities that use existing on-premises data to train machine learning models.
  • Potential savings in total cost of ownership for an application.
  • Potential improvements in availability, resiliency, security, or performance—for example adding a disaster recovery (DR) site in the cloud.
  • Potential speedup of the development and release processes—for example, building your development and testing environments in the cloud.

The following factors can help you evaluate migration risks:

  • The potential effect of outages that are caused by a migration.
  • Your team experience with public cloud (or with a new or second cloud provider) deployments might be limited at first.
  • The need to comply with any existing legal or regulatory restrictions.

The following factors can help you evaluate the technical difficulties of a migration:

  • The size, complexity, and age of the application.
  • The number of dependencies with other applications and services across different computing environments.
  • Any restrictions imposed by third-party licenses.
  • Any dependencies on specific versions of operating systems, databases, or other environment configurations.

After you have assessed your initial workloads, you can start prioritizing them and defining your migration waves and approaches. Then, you can identify applicable architecture patterns and supporting networking patterns. This step might require multiple iterations, because your assessment could change over time. It's therefore worth re-evaluating workloads after you make your first cloud deployments.

Architectural approaches to adopt a hybrid or multicloud architecture

Design a hybrid and multicloud architecture strategy discusses several possible, and recommended, steps to design a strategy for adopting a hybrid or multicloud architecture. It focuses on the targeted state and the overall architecture. This document provides guidance on common proven approaches and considerations to migrate your workload to the cloud.

Cloud first

A common way to begin using the public cloud is the cloud-first approach. In this approach, you deploy your new workloads to the public cloud while your existing workloads stay where they are. In that case, consider a classic deployment to a private computing environment only if a public cloud deployment is impossible for technical or organizational reasons.

The cloud-first strategy has advantages and disadvantages. On the positive side, it's forward looking. You can deploy new workloads in a modernized fashion while avoiding (or at least minimizing) the hassles of migrating existing workloads.

While a cloud-first approach can provide certain advantages, it could potentially result in missed opportunities for improving or using existing workloads. New workloads might represent a fraction of the overall IT landscape, and their effect on IT expenses and performance can be limited. Allocating time and resources to migrating an existing workload could potentially lead to more substantial benefits or cost savings compared to attempting to accommodate a new workload in the cloud environment.

Following a strict cloud-first approach also risks increasing the overall complexity of your IT environment. This approach might create redundancies, lower performance due to potential excessive cross-environment communication, or result in a computing environment that isn't well suited for the individual workload. Also, compliance with industry regulations and data privacy laws can restrict enterprises from migrating certain applications that hold sensitive data.

Considering these risks, you might be better off using a cloud-first approach only for selected workloads. That way you can concentrate on the workloads that can benefit the most from a cloud deployment or migration. This approach also considers the modernization of existing workloads.

A common example of a cloud-first hybrid architecture is when legacy applications and services holding critical data must be integrated with new data or applications. To complete the integration, you can use a hybrid architecture that modernizes legacy services by using API interfaces, which unlocks them for consumption by new cloud services and applications. With a cloud API management platform like Apigee, you can implement such use cases with minimal application changes and add security, analytics, and scalability to the legacy services.

Migration and modernization

Hybrid multicloud and IT modernization are distinct concepts that are linked in a virtuous circle. Using the public cloud can facilitate and simplify the modernization of IT workloads. Modernizing your IT workloads can help you get more from the cloud.

The primary goals of modernizing workloads are as follows:

  • Achieving greater agility so that you can adapt to changing requirements.
  • Reducing costs of infrastructure and operations.
  • Increasing reliability and resiliency to minimize risk for the business.

However, it might not be feasible to modernize every application in the migration process at the same time. As described in Migration to Google Cloud, you can implement one of the following migration types, or even combine multiple types as needed:

  • Rehost (lift and shift)
  • Replatform (lift and optimize)
  • Refactor (move and improve)
  • Rearchitect (continue to modernize)
  • Rebuild (remove and replace, sometimes called rip and replace)
  • Repurchase

When making strategic decisions about your hybrid and multicloud architectures, it's important to consider the feasibility of your strategy from a cost and time perspective. You might want to consider a phased migration approach, starting with lifting and shifting or replatforming and then refactoring or rearchitecting as the next step. Typically, lifting and shifting helps to optimize applications from an infrastructure perspective. After applications are running in the cloud, it's easier to use and integrate cloud services to further optimize them using cloud-first architecture and capabilities. Also, these applications can still communicate with other environments over a hybrid network connection.

For example, you can refactor or rearchitect a large, monolithic VM-based application and turn it into several independent microservices, based on a cloud-based microservice architecture. In this example, the microservices architecture uses Google Cloud managed container services like Google Kubernetes Engine (GKE) or Cloud Run. However, if the architecture or infrastructure of an application isn't supported in the target cloud environment as it is, you might consider starting with replatforming, refactoring, or rearchitecting your migration strategy to overcome those constraints where feasible.

When using any of these migration approaches, consider modernizing your applications (where applicable and feasible). Modernization can require adopting and implementing Site Reliability Engineering (SRE) or DevOps principles, such that you might also need to extend application modernization to your private environment in a hybrid setup. Even though implementing SRE principles involves engineering at its core, it's more of a transformation process than a technical challenge. As such, it will likely require procedural and cultural changes. To learn more about how the first step to implementing SRE in an organization is to get leadership buy-in, see With SRE, failing to plan is planning to fail.

Mix and match migration approaches

Each migration approach discussed here has certain strengths and weaknesses. A key advantage of following a hybrid and multicloud strategy is that it isn't necessary to settle on a single approach. Instead, you can decide which approach works best for each workload or application stack, as shown in the following diagram.

Flowchart showing different approaches to migrating workloads from your cloud environment.

This conceptual diagram illustrates the various migration and modernization paths or approaches that can be simultaneously applied to different workloads, driven by the unique business, technical requirements, and objectives of each workload or application.

In addition, it's not necessary that the same application stack components follow the same migration approach or strategy. For example:

  • The backend on-premises database of an application can be replatformed from self-hosted MySQL to a managed database using Cloud SQL in Google Cloud.
  • The application frontend virtual machines can be refactored to run on containers using GKE Autopilot, where Google manages the cluster configuration, including nodes, scaling, security, and other preconfigured settings.
  • The on-premises hardware load balancing solution and web application firewall WAF capabilities can be replaced with Cloud Load Balancing and Google Cloud Armor.

Choose rehost (lift and shift), if any of the following is true of the workloads:

  • They have a relatively small number of dependencies on their environment.
  • They aren't considered worth refactoring, or refactoring before migration isn't feasible.
  • They are based on third-party software.

Consider refactor (move and improve) for these types of workloads:

  • They have dependencies that must be untangled.
  • They rely on operating systems, hardware, or database systems that can't be accommodated in the cloud.
  • They aren't making efficient use of compute or storage resources.
  • They can't be deployed in an automated fashion without some effort.

Finally, rebuild (remove and replace) might be best for these types of workloads:

  • They no longer satisfy current requirements.
  • They can be incorporated with other applications that provide similar capabilities without compromising business requirements.
  • They are based on third-party technology that has reached its end of life.
  • They require third-party license fees that are no longer economical.

The Rapid Migration Program shows how Google Cloud helps customers to use best practices, lower risk, control costs, and simplify their path to cloud success.

Other considerations

This document highlights the core design considerations that play a pivotal role in shaping your overall hybrid and multicloud architecture. Holistically analyze and assess these considerations across your entire solution architecture, encompassing all workloads, not just specific ones.

Refactor

In a refactor migration, you modify your workloads to take advantage of cloud capabilities, not just to make them work in the new environment. You can improve each workload for performance, features, cost, and user experience. As highlighted in Refactor: move and improve, some refactor scenarios let you modify workloads before migrating them to the cloud. This refactoring approach offers the following benefits, especially if your goal is to build a hybrid architecture as a long term targeted architecture:

  • You can improve the deployment process.
  • You can help speed up the release cadence and shorten feedback cycles by nvesting in continuous integration/continuous deployment (CI/CD) infrastructure and tooling.
  • You can use refactoring as a foundation to build and manage hybrid architecture with application portability.

To work well, this approach typically requires certain investments in on-premises infrastructure and tooling. For example, setting up a local Container Registry and provisioning Kubernetes clusters to containerize applications. Google Kubernetes Engine (GKE) Enterprise edition can be useful in this approach for hybrid environments. More information about GKE Enterprise is covered in the following section. You can also refer to the GKE Enterprise hybrid environment reference architecture for more details.

Workload portability

With hybrid and multicloud architectures, you might want to be able to shift workloads between the computing environments that host your data. To help enable the seamless movement of workloads between environments, consider the following factors:

  • You can move an application from one computing environment to another without significantly modifying the application and its operational model:
    • Application deployment and management are consistent across computing environments.
    • Visibility, configuration, and security are consistent across computing environments.
  • The ability to make a workload portable shouldn't conflict with the workload being cloud-first.

Infrastructure automation

Infrastructure automation is essential for portability in hybrid and multicloud architectures. One common approach to automating infrastructure creation is through infrastructure as code (IaC). IaC involves managing your infrastructure in files instead of manually configuring resources—like a VM, a security group, or a load balancer—in a user interface. Terraform is a popular IaC tool to define infrastructure resources in a file. Terraform also lets you automate the creation of those resources in heterogeneous environments.

For more information about Terraform core functions that can help you automate provisioning and managing Google Cloud resources, see Terraform blueprints and modules for Google Cloud.

You can use configuration management tools such as Ansible, Puppet, or Chef to establish a common deployment and configuration process. Alternatively, you can use an image-baking tool like Packer to create VM images for different platforms. By using a single, shared configuration file, you can use Packer and Cloud Build to create a VM image for use on Compute Engine. Finally, you can use solutions such as Prometheus and Grafana to help ensure consistent monitoring across environments.

Based on these tools, you can assemble a common tool chain as illustrated in the following logical diagram. This common tool chain abstracts away the differences between computing environments. It also lets you unify provisioning, deployment, management, and monitoring.

A tool chain enables application portability.

Although a common tool chain can help you achieve portability, it's subject to several of the following shortcomings:

  • Using VMs as a common foundation can make it difficult to implement true cloud-first applications. Also, using VMs only can prevent you from using cloud-managed services. You might miss opportunities to reduce administrative overhead.
  • Building and maintaining a common tool chain incurs overhead and operational costs.
  • As the tool chain expands, it can develop unique complexities tailored to the specific needs of your company. This increased complexity can contribute to rising training costs.

Before deciding to develop tooling and automation, explore the managed services your cloud provider offers. When your provider offers managed services that support the same use case, you can abstract away some of its complexity. Doing so lets you focus on the workload and the application architecture rather than the underlying infrastructure.

For example, you can use the Kubernetes Resource Model to automate the creation of Kubernetes clusters using a declarative configuration approach. You can use Deployment Manager convert to convert your Deployment Manager configurations and templates to other declarative configuration formats that Google Cloud supports (like Terraform and the Kubernetes Resource Model) so they're portable when you publish.

You can also consider automating the creation of projects and the creation of resources within those projects. This automation can help you adopt an infrastructure-as-code approach for project provisioning.

Containers and Kubernetes

Using cloud-managed capabilities helps to reduce the complexity of building and maintaining a custom tool chain to achieve workload automation and portability. However, only using VMs as a common foundation makes it difficult to implement truly cloud-first applications. One solution is to use containers and Kubernetes instead.

Containers help your software to run reliably when you move it from one environment to another. Because containers decouple applications from the underlying host infrastructure, they facilitate the deployment across computing environments, such as hybrid and multicloud.

Kubernetes handles the orchestration, deployment, scaling, and management of your containerized applications. It's open source and governed by the Cloud Native Computing Foundation. Using Kubernetes provides the services that form the foundation of a cloud-first application. Because you can install and run Kubernetes on many computing environments, you can also use it to establish a common runtime layer across computing environments:

  • Kubernetes provides the same services and APIs in a cloud or private computing environment. Moreover, the level of abstraction is much higher than when working with VMs, which generally translates into less required groundwork and improved developer productivity.
  • Unlike a custom tool chain, Kubernetes is widely adopted for both development and application management, so you can tap into existing expertise, documentation, and third-party support.
  • Kubernetes supports all container implementations that:

When a workload is running on Google Cloud, you can avoid the effort of installing and operating Kubernetes by using a managed Kubernetes platform such as Google Kubernetes Engine (GKE). Doing so can help operations staff shift their focus from building and maintaining infrastructure to building and maintaining applications.

You can also use Autopilot, a GKE mode of operation that manages your cluster configuration, including your nodes, scaling, security, and other preconfigured settings. When using GKE Autopilot, consider your scaling requirements and its scaling limits.

Technically, you can install and run Kubernetes on many computing environments to establish a common runtime layer. Practically, however, building and operating such an architecture can create complexity. The architecture gets even more complex when you require container-level security control (service mesh).

To simplify managing multi-cluster deployments, you can use GKE Enterprise to run modern applications anywhere at scale. GKE includes powerful managed open source components to secure workloads, enforce compliance policies, and provide deep network observability and troubleshooting.

As illustrated in the following diagram, using GKE Enterprise means you can operate multi-cluster applications as fleets.

Stack diagram showing the fleet-management opportunities offered by GKE Enterprise.

GKE Enterprise helps with the following design options to support hybrid and multicloud architectures:

  • Design and build cloud-like experiences on-premises or unified solutions for transitioning applications to GKE Enterprise hybrid environment. For more information, see the GKE Enterprise hybrid environment reference architecture.

  • Design and build a solution to solve multicloud complexity with a consistent governance, operations, and security posture with GKE Multi-Cloud. For more information, see the GKE Multi-Cloud documentation.

GKE Enterprise also provides logical groupings of similar environments with consistent security, configuration, and service management. For example, GKE Enterprise powers zero trust distributed architecture. In a zero trust distributed architecture, services that are deployed on-premises or in another cloud environment can communicate across environments through end-to-end mTLS secure service-to-service communications.

Workload portability considerations

Kubernetes and GKE Enterprise provide a layer of abstraction for workloads that can hide the many intricacies and differences between computing environments. The following list describes some of those abstractions:

  • An application might be portable to a different environment with minimal changes, but that doesn't mean that the application performs equally well in both environments.
    • Differences in underlying compute, infrastructure security capabilities, or networking infrastructure, along with proximity to dependent services, might lead to substantially different performance.
  • Moving a workload between computing environments might also require you to move data.
    • Different environments can have different data storage and management services and facilities.
  • The behavior and performance of load balancers provisioned with Kubernetes or GKE Enterprise might differ between environments.

Data movement

Because it can be complex to move, share, and access data at scale between computing environments, enterprise-level companies might hesitate to build a hybrid or multicloud architecture. This hesitation might increase if they are already storing most of their data on-premises or in one cloud.

However, the various data movement options offered by Google Cloud, provide enterprises with a comprehensive set of solutions to help move, integrate, and transform their data. These options help enterprises to store, share, and access data across different environments in a way that meets their specific use cases. That ability ultimately makes it easier for business and technology decision-makers to adopt hybrid and multicloud architectures.

Data movement is an important consideration for hybrid and multicloud strategy and architecture planning. Enterprises need to identify their different business use cases and the data that powers them. They should think about storage type, capacity, accessibility, and movement options.

If an enterprise has a data classification for regulated industries, that classification can help to identify storage locations and cross-region data movement restrictions for certain data classes. For more information, see Sensitive Data Protection. Sensitive Data Protection is a fully managed service designed to help you discover, classify, and protect your data assets.

To explore the process, from planning a data transfer to using best practices in implementing a plan, see Migration to Google Cloud: Transferring your large datasets.

Security

As organizations adopt hybrid and multicloud architectures, their attack surface can increase depending on the way their systems and data are distributed across different environments. Combined with the constantly evolving threat landscape, increased attack surfaces can lead to an increased risk of unauthorized access, data loss, and other security incidents. Carefully consider security when planning and implementing hybrid or multicloud strategies.

For more information, see Attack Surface Management for Google Cloud.

When architecting for a hybrid architecture, it's not always technically feasible or viable to extend on-premises security approaches to the cloud. However, many of the networking security capabilities of hardware appliances are cloud-first features and they operate in a distributed manner. For more information about the cloud-first network security capabilities of Google Cloud, see Cloud network security.

Hybrid and multicloud architectures can introduce additional security challenges, such as consistency and observability. Every public cloud provider has its own approach to security, including different models, best practices, infrastructure and application security capabilities, compliance obligations, and even the names of security services. These inconsistencies can increase security risk. Also, the shared responsibility model of each cloud provider can differ. It's essential to identify and understand the exact demarcation of responsibilities in a multicloud architecture.

Observability is key to gaining insights and metrics from the different environments. In a multicloud architecture, each cloud typically provides tools to monitor for security posture and misconfigurations. However, using these tools results in siloed visibility, which prevents building advanced threat intelligence across the entire environment. As a result, the security team must switch between tools and dashboards to keep the cloud secure. Without an overarching end-to-end security visibility for the hybrid and multicloud environments, it's difficult to prioritize and mitigate vulnerabilities.

To obtain the full visibility and posture of all your environments, prioritize your vulnerabilities, and mitigate the vulnerabilities you identify. We recommend a centralized visibility model. A centralized visibility model avoids the need for manual correlation between different tools and dashboards from different platforms. For more information, see Hybrid and multicloud monitoring and logging patterns.

As part of your planning to mitigate security risks and deploy workloads on Google Cloud, and to help you plan and design your cloud solution for meeting your security and compliance objectives, explore the Google Cloud security best practices center and the enterprise foundations blueprint.

Compliance objectives can vary, as they are influenced by both industry-specific regulations and the varying regulatory requirements of different regions and countries. For more information, see the Google Cloud compliance resource center. The following are some of the primary recommended approaches for architecting secure hybrid and multicloud architecture:

  • Develop a unified tailored cloud security strategy and architecture. Hybrid and multicloud security strategies should be tailored to the specific needs and objectives of your organization.

    It's essential to understand the targeted architecture and environment before implementing security controls, because each environment can use different features, configurations, and services.

  • Consider a unified security architecture across hybrid and multicloud environments.

  • Standardize cloud design and deployments, especially security design and capabilities. Doing so can improve efficiency and enable unified governance and tooling.

  • Use multiple security controls.

    Typically, no single security control can adequately address all security protection requirements. Therefore, organizations should use a combination of security controls in a layered defense approach, also known as defense-in-depth.

  • Monitor and continuously improve security postures: Your organization should monitor its different environments for security threats and vulnerabilities. It should also try to continuously improve its security posture.

  • Consider using cloud security posture management (CSPM) to identify and remediate security misconfigurations and cybersecurity threats. CSPM also provides vulnerability assessments across hybrid and multicloud environments.

Security Command Center is a built-in security and risk management solution for Google Cloud that helps to identify misconfigurations and vulnerabilities and more. Security Health Analytics is a managed vulnerability assessment scanning tool. It's a feature of Security Command Center that identifies security risks and vulnerabilities in your Google Cloud environment and provides recommendations for remediating them.

Mandiant Attack Surface Management for Google Cloud lets your organization better see their multicloud or hybrid cloud environment assets. It automatically discovers assets from multiple cloud providers, DNS, and the extended external attack surface to give your enterprise a deeper understanding of its ecosystem. Use this information to prioritize remediation on the vulnerabilities and exposures that present the most risk.

  • Cloud security information and event management (SIEM) solution: Helps to collect and analyze security logs from hybrid and multicloud environments to detect and respond to threats. Chronicle SIEM from Google Cloud helps to provide security Information and event management by collecting, analyzing, detecting, and investigating all of your security data in one place.

Build hybrid and multicloud architectures using Google Cloud: What's next