This section of the Google Cloud deployment archetypes guide describes the hybrid deployment archetype, provides examples of use cases, and discusses design considerations.
In an architecture that's based on the hybrid deployment archetype, some parts of the application are deployed in Google Cloud, and other parts run on-premises.
Use cases
The following sections provide examples of use cases for which the hybrid deployment archetype is an appropriate choice.
Disaster recovery (DR) site for an on-premises application
For mission-critical applications that you run on-premises, you can back up the data to Google Cloud and maintain a replica in the cloud, as shown in the following diagram. The backup frequency and whether the replica needs to be active or passive depends on your recovery time objective (RTO) and recovery point objective (RPO). When the on-premises application is down due to planned or unplanned events, you can activate the replica in Google Cloud to restore the application to production.
On-premises development for cloud applications
For an application that runs in Google Cloud, you can keep the development environments on-premises, and use a CI/CD pipeline to push updates to the cloud, as shown in the following diagram. This architecture lets you retain control over your development activities while enjoying the benefits that Google Cloud offers for scalability, cost optimization, and reliability.
Enhancing on-premises applications with cloud capabilities
Google Cloud offers advanced capabilities in many areas, including storage, artificial intelligence (AI) and machine learning (ML), big data, and analytics. The hybrid deployment archetype lets you use these advanced Google Cloud capabilities even for applications that you run on-premises. The following are examples of these capabilities:
- Low-cost, unlimited archive storage in the cloud for an on-premises application.
- AI and ML applications in the cloud for data generated by an on-premises application.
- Cloud-based data warehouse and analytics processes using BigQuery for data ingested from on-premises data sources.
- Cloud bursting, to handle overflow traffic when the load on the on-premises application reaches peak capacity.
The following diagram shows a hybrid topology where data from an on-premises application is uploaded to Google Cloud. Data analysts analyze the uploaded data by using advanced AI, ML, big data, and analytics capabilities in Google Cloud.
Tiered hybrid topology
In this topology, which is sometimes called a split-stack deployment, the application's frontend is in Google Cloud, and the backend is on-premises. The frontend might include capabilities like load balancing, CDN, DDoS protection, and access policies. The frontend sends traffic to the on-premises backend for processing, as shown in the following diagram:
This architecture might be suitable when an application is used globally but the backend needs to be within a single, controlled environment. A variation of this use case is to run the frontend on-premises and deploy the backend in Google Cloud.
More information
For more information about the rationale and use cases for the hybrid deployment archetype, see Build hybrid and multicloud architectures using Google Cloud.
Design considerations
When you build an architecture that's based on the hybrid deployment archetype, consider the following design factors.
On-premises to cloud network connection
For efficient network communication between your on-premises environment and the resources in Google Cloud, you need a network connection that's reliable and secure. For more information about hybrid connectivity options offered by Google Cloud, see Choosing a Network Connectivity product.
Setup effort and operational complexity
Setting up and operating a hybrid topology requires more effort than an architecture that uses only Google Cloud. To operate this topology, you need to manage resources consistently across the on-premises and Google Cloud environments. To manage containerized hybrid applications, you can use GKE Enterprise, which is a unified orchestration platform to manage Kubernetes clusters in multiple locations.
Cost of redundant resources
A hybrid deployment is potentially more expensive than a cloud-only deployment, because data might need to be stored redundantly on-premises and in the cloud. Also, some of the redundant resources might be underutilized. When you build an architecture that's based on the hybrid deployment archetype, consider the potentially higher overall cost of resources.
Example architectures
For examples of architectures that use the hybrid deployment archetype, see Build hybrid and multicloud architectures using Google Cloud.