This article is the second part of a multi-part series that discusses hybrid and multi-cloud deployments, architecture patterns, and network topologies. This part explores common hybrid and multi-cloud architecture patterns. The article describes which scenarios these patterns are best suited for, and provides best practices for implementing them by using Google Cloud.
The series consists of these parts:
- Hybrid and multi-cloud patterns and practices
- Hybrid and multi-cloud architecture patterns (this article)
- Hybrid and multi-cloud network topologies
Every enterprise has a unique portfolio of application workloads that place requirements and constraints on the architecture of a hybrid or multi-cloud setup. Although you must design and tailor your architecture to meet these constraints and requirements, you can rely on some common patterns.
The patterns fall into two categories:
Patterns that rely on a distributed deployment of applications. The aim of these patterns is to run an application in the computing environment that suits it best, capitalizing on the different properties and characteristics of computing environments.
Patterns that are based on redundant deployments of applications. In these patterns, you deploy the same applications in multiple computing environments, with the aim of increasing capacity or resiliency.
Distributed deployment patterns
When you migrate from a classic computing environment to a hybrid or multi-cloud setup, consider the constraints that existing applications impose. You also want to capitalize on the unique capabilities that each computing environment offers. These distributed patterns aim to strike a thoughtful balance between both objectives.
Tiered hybrid
Most applications can be categorized as either frontend or backend.
Frontend applications are directly exposed to end users or devices. As a result, these applications are often performance sensitive and might be subject to frequent releases as new features and improvements are developed. Because they usually rely on backend applications to store and manage data, frontend applications are often stateless or manage only small volumes of data.
Backend applications usually focus on managing data. Key challenges for such applications include handling data in volume and securing it appropriately. New releases of backend applications tend to be less frequent than for frontend applications.
The idea of the tiered hybrid pattern is to focus first on deploying existing frontend applications to the public cloud. In this pattern, you reuse existing backend applications that stay in their private computing environment. You migrate frontend applications case by case.
The following diagram shows a typical tiered hybrid pattern.
Over time, the fraction of applications that you deploy to the cloud increases, to the point where you might consider also moving backend applications to the public cloud.
Advantages
Focusing on frontend applications first has several advantages:
Frontend applications depend on backends and occasionally on other frontends, but backends do not depend on frontends. Therefore, isolating and migrating frontend applications tends to be less complex than migrating backend applications, which might have complex dependencies.
Because frontend applications often are stateless or do not manage data by themselves, they tend to be less challenging to migrate.
Deploying existing or newly developed frontend applications to the public cloud offers several key advantages:
Many frontend applications are subject to frequent changes. Running these applications in the public cloud simplifies the setup of a continuous integration/continuous deployment (CI/CD) process that you can use to roll out updates in an efficient and automated manner.
Performance-sensitive frontends and frontends that are subject to frequent changes can benefit substantially from the load balancing, multi-regional deployments, and autoscaling features that a cloud deployment enables.
Whether they are implementing user interfaces or APIs, or handling IoT (Internet of Things) data ingestion, frontend applications can benefit from the capabilities that cloud services such as Firebase, Cloud CDN, or Cloud IoT offer.
If your backends manage data that is subject to regulatory or jurisdictional restrictions, you probably want to keep them in the private computing environment, either permanently or at least until you find a way to work within the restrictions.
You can also apply the tiered hybrid pattern in reverse, although it's less common, by deploying backends in the cloud while keeping frontends in private computing environments. This approach is best applied when you are dealing with a heavyweight and monolithic frontend. In such cases, it might be easier to extract backend functionality iteratively, and to deploy these new backends in the cloud.
Best practices
When you are applying the tiered hybrid pattern, consider the following practices:
Use either a gated egress or meshed topology. Because most user interaction involves systems that connect across multiple computing environments, fast and low-latency connectivity between those systems is important. Designing for high availability, low latency, and appropriate throughput levels is therefore crucial.
To minimize communication latency between environments, pick a Google Cloud region and interconnect location that are geographically close to your private computing environment.
In a tiered hybrid setup, you usually have larger volumes of data coming in to Google Cloud (ingress) than moving from Google Cloud to the private computing environment (egress). Still, be aware that traffic leaving Google Cloud is subject to egress pricing. Using Dedicated Interconnect or Direct Peering can help reduce these charges.
Ensure that the communication between environments is unidirectional. Frontend applications that are running in the public cloud are allowed to communicate with backends that are running in private computing environments, but not the other way around.
Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted by relying on virtual private network (VPN) tunnels, Transport Layer Security (TLS), or both.
We recommend deploying an API gateway as a facade for existing backend services, particularly when the protocols, APIs, and authentication mechanisms are inconsistent across backends. In addition to serving as a unification layer, an API gateway can serve as a choke point. With this gateway, you can implement additional security and auditing measures that apply to all cross-environment communication.
Establish common identity between environments so that systems can authenticate securely across environment boundaries.
For the individual workloads, consider these additional best practices:
Although the focus lies on frontend applications in this pattern, stay aware of the need to modernize backend applications. If the development pace of backends is substantially slower than for frontends, the difference can cause extra complexity in projects.
To enable transform-and-move migrations, use Kubernetes as the common runtime layer between Google Cloud and private computing environments. With Kubernetes, you can modernize a workload and migrate to Google Cloud at different times, which can be crucial when a workload depends heavily on another and cannot be migrated individually.
Avoid requiring bidirectional communication between environments. To achieve that, consider also deploying CI/CD systems in the public cloud.
In a tiered hybrid scenario, use consistent tooling and CI/CD processes across environments to help increase operational efficiency. This practice is not required.
When using Kubernetes to run frontend workloads, use services without selectors to make discoverable any services or API gateways that are running in the private computing environment. By using Kubernetes stub domains, you can integrate with external DNS-based service discovery systems such as Consul.
Partitioned multi-cloud
The partitioned multi-cloud pattern combines multiple public cloud environments, operated by different vendors, in a way that gives you the flexibility to deploy an application in the optimal computing environment. The following diagram shows a typical partitioned multi-cloud pattern.
You can maintain the ability to shift workloads as needed from one public cloud environment to another, in which case, workload portability becomes a key requirement. When you deploy workloads to multiple computing environments and want to maintain the ability to move workloads between environments, you must abstract away the differences between the environments.
Google Cloud provides a rich set of services that you can use to deploy your workloads in different ways. Still, in some situations it makes sense to combine Google Cloud with another cloud provider and partition your workloads across cloud environments. Here are some examples:
To avoid committing to a single vendor, you spread applications across multiple cloud providers.
For regulatory reasons, you serve a certain segment of your user base and data from a country where Google Cloud does not yet have any presence.
You deploy applications across multiple cloud providers in a way that allows you to choose among the best services that the providers offer.
Advantages
Here are some key advantages of the partitioned multi-cloud pattern:
You can avoid vendor lock-in. This pattern helps lower strategic risk and provides you with the flexibility to change plans or partnerships later.
When you keep workloads portable, you can optimize your operations by shifting workloads between computing environments.
Best practices
Weigh the strategic advantages of a partitioned multi-cloud setup against the additional complexity this setup brings. Achieving workload portability and consistent tooling across multiple cloud environments increases development, testing, and operations work.
Use a multi-cloud environment only for mission-critical workloads or if, for legal or regulatory reasons, a single public cloud environment cannot accommodate the workloads.
Minimize dependencies between systems that are running in different public cloud environments, particularly when communication is handled synchronously. These dependencies can slow performance and decrease overall availability.
To abstract away the differences between environments, consider using containers and Kubernetes.
Ensure that CI/CD processes and tooling for deployment and monitoring are consistent across cloud environments.
Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted by relying on VPN tunnels, TLS, or both.
Establish common identity between environments so that systems can authenticate securely across environment boundaries.
When using Kubernetes, consider using ExternalDNS to make services discoverable by DNS name across computing environments.
Although you can use the anycast IP-based Google Cloud load balancers to balance requests across multiple Google Cloud regions, you cannot use them to distribute user requests across multiple clouds. For this distribution, you must use either round robin or Geo DNS. For example, you can use NS1, Oracle®, or Akamai.
Analytics hybrid and multi-cloud
In enterprise systems, most workloads fall into these categories:
Transactional workloads include interactive applications like sales, financial processing, enterprise resource planning, or communication.
Analytics workloads include applications that transform, analyze, refine, or visualize data to aid decision-making processes.
Although analytics systems obtain their data from transactional systems by either querying APIs or accessing databases, in most enterprises, analytics and transactional systems tend to be separated and loosely coupled. The idea of the analytics hybrid and multi-cloud pattern is to capitalize on this pre-existing split by running the two kinds of workloads in two different computing environments. Raw data is first extracted from workloads that are running in the private computing environment and then loaded into Google Cloud, where it is used for analytical processing. Some of the results might then be fed back to transactional systems.
Advantages
Running analytics workloads in the cloud has several key advantages:
Analytics workloads often need to process substantial amounts of data and can be bursty, so they are especially well suited to being deployed in a public cloud environment. By dynamically scaling compute resources, you can quickly process large datasets while avoiding upfront investments or having to overprovision computing equipment.
Google Cloud provides a rich set of services to manage data throughout its entire lifecycle, ranging from initial acquisition through processing and analyzing to final visualization.
Cloud Storage is well suited for building a data lake.
Ingress traffic—moving data from the private computing environment to Google Cloud—is free of charge.
Best practices
To implement the analytics hybrid/multi-cloud pattern, consider the following best practices:
Use the handover topology to enable the ingestion of data. If analytical results need to be fed back to transactional systems, combine both the handover and the gated egress topologies.
Use Pub/Sub queues or Cloud Storage buckets to hand over data to Google Cloud from transactional systems that are running in your private computing environment. These queues or buckets can then serve as sources for data-processing pipelines and workloads.
When you have existing Hadoop or Spark workloads, consider migrating jobs to Dataproc and migrating existing HDFS data to Cloud Storage.
When you are performing an initial data transfer from your private computing environment to Google Cloud, choose the transfer approach that is best suited for your dataset size and available bandwidth.
Use consistent tooling and processes across environments. In an analytics hybrid scenario, this practice can help increase operational efficiency, although it is not a prerequisite.
Edge hybrid
Running workloads in the cloud requires that clients have fast and reliable internet connectivity. Given today's networks, this requirement rarely poses a challenge for cloud adoption. There are, however, scenarios when you cannot rely on continuous connectivity:
Sea-going vessels and other vehicles might be connected only intermittently or have access only to high-latency satellite links.
Factories or power plants might be connected to the internet. These facilities might have reliability requirements that exceed availability guarantees of the link.
Stores or supermarkets might be connected only occasionally or use links that do not provide the necessary reliability or throughput to handle business-critical transactions.
The edge hybrid pattern addresses these challenges by running time- and business-critical workloads locally, at the edge of the network, while using the cloud for all other kinds of workloads. In an edge hybrid setup, the internet link is a noncritical component that is used for management purposes and to synchronize or upload data, often asynchronously, but is not involved in time- or business-critical transactions.
Advantages
Running certain workloads at the edge and others in the cloud offers several advantages:
Running workloads that are business and time critical at the edge helps ensure low latency and self-sufficiency. If internet connectivity fails or is temporarily unavailable, you can still execute all important transactions. At the same time, you can benefit from using the cloud for a significant portion of your overall workload.
You can reuse existing investments in computing and storage equipment.
Over time, you can incrementally reduce the fraction of workloads that are run at the edge, either by reworking certain applications or by equipping some edge locations with more-reliable internet links.
Ingress traffic—moving data from the edge to Google Cloud—is free of charge.
Best practices
Consider the following recommendations when implementing the edge hybrid pattern:
If communication is unidirectional, use the gated ingress topology. For bidirectional communication, consider the gated ingress and egress topology.
Minimize dependencies between systems that are running at the edge and systems that are running in the cloud environment. Each dependency can undermine the reliability and latency advantages of an edge hybrid setup.
To manage and operate multiple edge locations efficiently, have a centralized control plane in the cloud.
Ensure that CI/CD processes along with tooling for deployment and monitoring are consistent across cloud and edge environments.
Consider using containers and Kubernetes to abstract away differences among various edge locations and also among edge locations and the cloud. Because Kubernetes provides a common runtime layer, you can develop, run, and operate workloads consistently across computing environments and move workloads between edge and cloud.
Establish common identity between environments so that systems can authenticate securely across environment boundaries.
Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted by using VPN tunnels, TLS, or both.
Redundant deployment patterns
The following sections explore common patterns that rely on a redundant deployment of applications across multiple computing environments. In these patterns, you deploy the same applications in multiple computing environments with the aim of increasing capacity or resiliency.
Environment hybrid
The idea of the environment hybrid pattern is to keep the production environment of a workload in the existing data center but use the public cloud for other, non-production environments.
When assessing which workloads to migrate, you might notice cases when running a specific application in the public cloud presents challenges:
- Jurisdictional or regulatory constraints might require that you keep data in a specific country.
- Third-party licensing terms might prevent you from operating certain software in a cloud environment.
- An application might require access to hardware devices that are available only locally, as with moving workloads.
In such cases, consider not only the production environment but all environments that are involved in an application's lifecycle, including development, testing, and staging systems. The restrictions that can make a cloud migration challenging often apply to the production environment and its data but not to other environments.
The following diagram shows a typical environment-hybrid pattern.
Running development and testing systems in different environments than production systems might seem risky and run counter to existing best practices or attempts to minimize differences between such environments. While such concerns are justified, they don't apply if you distinguish among the stages of the development and testing processes:
While development, testing, and deployment processes differ for each application, they usually involve variations of the following stages:
- Development: creating a release candidate.
- Functional testing or user acceptance testing: verifying that the release candidate meets functional requirements.
- Performance and reliability testing: verifying that the release candidate meets nonfunctional requirements.
- Staging or deployment testing: verifying that the deployment procedure works.
- Production.
Performing more than one of these stages in a single environment is rarely practical, so each stage usually requires one or more dedicated environments.
To ensure that test results are meaningful and will apply to the production deployment, the set of environments that you use throughout an application's lifecycle must satisfy the following rules, to the extent possible:
All environments are functionally equivalent. That is, the architecture, APIs, and versions of operating systems and libraries are equivalent, and systems behave the same across environments. This equivalence avoids situations where applications work in one environment but fail in another, or where defects are not reproducible.
Environments that are used for performance and reliability testing, staging, and production are nonfunctionally equivalent. That is, their performance, scale, and configuration, and the way they are operated and maintained, are either the same or differ only in insignificant ways. Otherwise, performance and staging tests become meaningless.
Crucially, it is fine if the environments that are used for development and functional testing differ nonfunctionally from the other environments. This situation fits well with the environment hybrid pattern:
Achieve functional equivalence across all environments by relying on Kubernetes as a common runtime layer, ensuring workload portability and abstracting away differences between computing environments.
Run environments for production, staging, and performance and reliability testing in the private computing environment, ensuring functional and nonfunctional equivalence.
Run development and functional testing environments in the public cloud. These environments are functionally equivalent to the remaining environments but might differ in nonfunctional aspects such as performance.
Advantages
Running development and functional testing workloads in the public cloud has several advantages:
You can automatically spin up and tear down environments as the need arises. For example, you can provision an entire environment for each commit or pull request, allow tests to run, and then tear it down again.
Development and testing environments are often used intermittently. You can reduce costs by stopping virtual machine (VM) instances during times of inactivity or by provisioning environments only on demand.
Running these environments in the public cloud helps build familiarity with and confidence in the cloud and related tools, which might help with migrating other workloads.
Best practices
To implement the environment pattern successfully, consider the following recommendations:
Use the mirrored topology, preventing systems from different environments from communicating with one another. Because systems don't need to communicate across environments, you do not need to establish a common identity.
To make workloads portable and to abstract away differences between environments, use containers and Kubernetes, but be aware of the limits to workload portability.
Ensure that CI/CD processes are consistent across computing environments, and that the exact same set of binaries, packages, or containers is deployed to the various environments.
For deploying, configuring, and operating workloads, establish a common tool chain that works across computing environments. Using Kubernetes gives you this consistency, with the exception of some minor differences in how you connect or authenticate to clusters that are running in different computing environments.
When using Kubernetes, use a CI system such as Jenkins to implement a deployment pipeline that deploys to clusters and works across environments. You can also run Jenkins itself on Google Kubernetes Engine (GKE).
Use the same tools for logging and monitoring across Google Cloud and existing cloud environments. Consider using open source monitoring systems such as Prometheus. If different teams manage test and production workloads, using separate tooling might be acceptable, although using the same tools can help reduce training effort and complexity.
When you choose database, storage, and messaging services, use products that have a managed equivalent on Google Cloud. Relying on managed services helps decrease the administrative effort of maintaining development and testing environments.
The following table shows which Google Cloud products are compatible with common OSS products.
| OSS product | Compatible with Google Cloud product |
|---|---|
| Apache HBase | Cloud Bigtable |
| Apache Beam | Dataflow |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Redis | Memorystore |
| Network File System (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
Business continuity hybrid and multi-cloud
Ideally, mission-critical systems are set up in a way that makes them resilient during disasters. By replicating systems and data over multiple geographical regions and avoiding single points of failure, you can minimize the risks of a natural disaster that affects local infrastructure. However, this approach does not address the risk of outages that are caused by human error or software defects. It is therefore crucial to also have a disaster recovery (DR) plan that ensures that you can recover your systems within acceptable time limits and with minimal data loss if other kinds of disasters occur.
A key part of DR planning is to back up data to a different geographical location frequently to minimize the recovery point objective (RPO). In addition, maintaining cold, warm, or hot standby systems in a second location can help minimize the recovery time objective (RTO).
When you run mission-critical systems in a central data center, one approach for DR is to maintain standby systems in a second data center that is situated in a different region. A more cost-effective approach, however, is to use a public cloud–based computing environment for failover purposes, which is the idea behind the business continuity hybrid pattern.
A less common (and rarely required) variant of this pattern is the business continuity multi-cloud pattern, in which the production environment uses one cloud provider and the DR environment uses a different cloud provider. By deploying copies of workloads across multiple cloud providers, you can increase availability beyond what a multi-region deployment offers.
Advantages
Using the public cloud for business continuity offers a number of advantages:
Because Google Cloud has over a dozen regions to choose from, you can use it to back up or replicate data to a different site within the same continent or even to a site on a different continent.
Stopped VM instances incur storage costs only and are substantially cheaper than VM instances that are running, so you can minimize the cost of maintaining cold standby systems.
The pay-per-use model of Google Cloud ensures that you pay only for storage and compute capacity that you actually use, and you can grow or shrink your DR environment as needed.
Best practices
When you are using the business continuity pattern, consider the following best practices:
Create a disaster recovery plan that documents your infrastructure along with failover and recovery procedures.
Based on your RPO and RTO, decide whether backing up data to Google Cloud is sufficient, or whether you need to maintain cold, warm, or hot standby systems. Refer to the disaster recovery planning guide for common scenarios and advice for implementing them on Google Cloud.
When you are performing only data backups, use the handover topology. Otherwise, consider the mirrored topology.
Minimize dependencies between systems that are running in different environments, particularly when communication is handled synchronously. These dependencies can slow performance and decrease overall availability.
If you replicate data bidirectionally across environments, you might be exposed to the split brain problem. In this problem, if communication between the two environments breaks, systems on both sides might conclude that the other environment has become unavailable. The systems might conclude that they have exclusive access to data, ultimately leading to conflicting modifications. One way to prevent this split is to add a third computing environment. This approach allows a system that is relying on data replication to check for a quorum before concluding that modifying data is safe. Alternatively, you can allow conflicting data modifications to be reconciled after connectivity has been restored.
Ensure that CI/CD systems and artifact repositories do not become a single point of failure. When one environment is unavailable, you must still be able to deploy new releases or apply configuration changes.
Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted by relying on VPN tunnels, TLS, or both.
When you are using standby systems, ensure that workloads are portable so that systems remain consistent across environments. Consider using containers and Kubernetes.
Integrate the deployment of standby systems into your CI/CD process. This integration helps ensure that application versions and configurations are consistent across environments.
When using hot standby systems, use load balancers to create an automatic failover, but keep in mind that load balancers can fail too. As a precaution, configure your DNS so that you can reroute users to standby systems in case of a disaster. Use a reasonably short TTL to ensure that DNS changes are propagated quickly, and make use of the 100% uptime SLA that Cloud DNS provides.
For DR, consider partner solutions such as Actifio, or Commvault.
Cloud bursting
Internet applications, especially those that target users, can experience extreme fluctuations in usage. While most enterprise applications do not face this challenge, many enterprises must deal with a different kind of bursty workload: batch or CI/CD jobs.
While you can accommodate bursty workloads in a classic, data center–based computing environment by overprovisioning resources, this approach is not cost effective. With batch jobs, you can optimize utilization by stretching their execution over longer time periods, although delaying jobs is not practical if they are time sensitive.
The idea of the cloud bursting pattern is to use a private computing environment for the baseline load and burst to the cloud temporarily when you need extra capacity.
A key requirement for cloud bursting scenarios is workload portability. When you allow workloads to be deployed to multiple environments, you must abstract away the differences between the environments.
The cloud bursting pattern applies to interactive and batch workloads. When you are dealing with interactive workloads, however, you must determine how to distribute requests across environments:
You can route incoming user requests to a load balancer that runs in the existing data center, and then have the load balancer distribute requests across the local and cloud resources. This approach requires the load balancer or another system that is running in the existing data center to also keep track of the resources that are allocated in the cloud, and to initiate automatic upscaling or downscaling of resources.
On the one hand, by using this approach you can decommission all cloud resources during times of low activity. On the other hand, implementing mechanisms to keep track of resources might exceed the capabilities of off-the-shelf load balancer solutions and therefore increase overall complexity.
Alternatively, you can route requests to Google Cloud first and then distribute them across environments. Because the Google Cloud load balancers support balancing and autoscaling only across Google Cloud resources, you need to combine a Google Cloud load balancer with additional, custom load-balancing mechanisms to facilitate the distribution of requests. Again, this approach creates extra complexity.
Load balancing by using round-robin DNS is not practical if you intend to shut down all resources in Google Cloud during times of low demand. Because DNS updates tend to propagate slowly, using DNS for load balancing bears the risks of users being routed to Google Cloud when no resources are available to process their requests.
Given these challenges, cloud bursting generally lends itself better to batch workloads than to interactive workloads.
Advantages
Key advantages of this architecture pattern include:
Cloud bursting allows you to reuse existing investments in data centers and private computing environments. This reuse can either be permanent or in effect until existing equipment becomes due for replacement, at which point you might consider a full cloud migration.
You might be able to increase utilization and cost effectiveness of your private computing environments because you no longer have to maintain excess capacity to satisfy peak demands.
Cloud bursting allows batch jobs to be run in a timely fashion without the need for overprovisioning compute resources.
Best practices
When implementing cloud bursting, consider the following best practices:
Use the meshed topology to ensure that workloads running in the cloud can access resources in the same fashion as workloads running in other computing environments. If workloads permit, allow access only from the cloud to the other computing environment, not the other way round.
To minimize latency for communication between environments, pick a Google Cloud region and interconnect location that is geographically close to your private computing environment.
When using cloud bursting for batch workloads only, reduce the security attack surface by keeping all Google Cloud resources private, disallowing any direct access from the internet to these resources.
For jobs that do not run for longer than 24 hours and are not highly time critical, consider the use of preemptible VM instances, which are substantially cheaper than regular VM instances. A prerequisite, however, is that if the VM that a job is running on is preempted, the system must be able to restart the job automatically.
Use containers to achieve workload portability. For resource-intensive batch workloads, you can directly deploy these containers on Compute Engine VMs and use a managed instance group to scale the number of VMs. In case of interactive workloads or diverse, less resource-intensive workloads, you can also use Google Kubernetes Engine (GKE) in combination with cluster autoscaling to deploy these containers. Note, however, that GKE requires at least one node per zone to be running at all times.
Monitor any traffic sent from Google Cloud to a different computing environment. This traffic is subject to egress charges.
Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted by relying on VPN tunnels, TLS, or both.
Use the bursting cloud pattern to dynamically scale a CI system. When using Jenkins, you can use the Google Compute Engine plugin to manage and autoscale Jenkins instances on Compute Engine.
Establish common identity between environments so that systems can securely authenticate across environment boundaries.
What's next
- Find out more about the network topologies suitable for realizing common architecture patterns.
- Learn how to approach hybrid and how to choose suitable workloads.
- Take a look at the documentation and tutorials for GKE.
- Explore reference architectures, diagrams, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.