The ARCHITECTURE OF GOOGLE CLOUD PLATFORM Framework provides recommendations and describes best practices to help architects, developers, administrators, and other cloud practitioners. Thus, they design and operate a cloud topology that’s secure, efficient, resilient, high-performing, and cost-effective.

Moreover, a cross-functional team of experts at Google validates the design recommendations and best practices that make up the Architecture Framework. Hence, the team curates the Architecture Framework to reflect the expanding capabilities of Google Cloud, industry best practices, community knowledge, and feedback from you. Additionally, for a summary of the significant changes, see What’s new.

The Google Cloud Architecture Framework is organized into six categories (also known as pillars), as shown in the following diagram:

The design guidance in the ARCHITECTURE OF GOOGLE CLOUD PLATFORM applies to applications built for the cloud and for workloads migrated from on-premises to Google Cloud, hybrid cloud deployments, and multi-cloud environments.

System Design

First of all, system design is the foundational category of the Google Cloud Architecture Framework. Therefore, this category provides design recommendations and describes best practices and principles to help you define the architecture, components, modules, interfaces, and data on a cloud platform to satisfy your system requirements. You also learn about Google Cloud products and features that support system design

Note

Before you change your production environment, we recommend that you experiment with new features or design in a sandbox environment.

https://cloud.google.com/architecture/framework/system-design

Operational Excellence

For example, This category in the Google Cloud Architecture Framework shows you how to operate services efficiently on Google Cloud. It discusses how to run, manage, and monitor systems that deliver business value.

Furthermore, it also discusses Google Cloud products and features that support operational excellence. Using the principles of operational excellence helps you build a foundation for reliability. It does so by setting up foundational elements like observability, automation, and scalability.

In addition, this Architecture Framework describes best practices, provides implementation recommendations, and explains some available products and services that help you achieve operational excellence. The framework aims to help you design your Google Cloud deployment so that it best matches your business needs.

Security, Privacy, and Compliance

First of all, this category in the Google Cloud Architecture Framework shows you how to architect and operate secure services on Google Cloud. You also learn about Google Cloud products and features that support security and compliance.

Secondly, the Architecture Framework describes best practices, provides implementation recommendations, and explains some of the available products and services. The framework helps you design your Google Cloud deployment so that it matches your business needs.

Third, moving your workloads into Google Cloud requires an evaluation of your business requirements, risks, compliance obligations, and security controls. This document helps you consider key best practices related to designing a secure solution in Google Cloud.

Finally, Google core principles include defense in depth, at scale, and by default. In Google Cloud, data and systems are protected through multiple layered defenses using policies and controls that are configured across IAM, encryption, networking, detection, logging, and monitoring,

Reliability

This category in the Google Cloud Architecture Framework shows you how to architect and operate reliable services on a cloud platform. You also learn about some of the Google Cloud products and features that support reliability.

The Architecture Framework describes best practices, provides implementation recommendations, and explains some of the available products and services. Hence, the framework aims to help you design your Google Cloud deployment so that it best matches your business needs.

Therefore, to run a reliable service, your architecture must include the following:

• Measurable reliability goals, with deviations that you promptly correct.
• Design patterns for scalability, high availability, disaster recovery, and automated change management.
• Components that self-heal where possible, and code that includes instrumentation for observability.
• Operational procedures that run the service with minimal manual work and cognitive load on operators, and that let you rapidly detect and mitigate failures.

Reliability is the responsibility of everyone in engineering, such as the development, product management, operations, and site reliability engineering (SRE) teams. Everyone must be accountable and understand their application’s reliability targets, and risk and error budgets. Thus, teams should be able to prioritize work appropriately and escalate priority conflicts between reliability and product feature development.

Example

Hybrid and multi-cloud network topologies

In addition, this part explores common network topologies that you can use for hybrid and multi-cloud setups. Furthermore, it describes which scenarios and architectural patterns these topologies are best suited for, and provides best practices for implementing them by using Google Cloud.

Hence, the series consists of these parts:

• Hybrid and multi-cloud patterns and practices
• Hybrid and multi-cloud architecture patterns
• Hybrid and multi-cloud network topologies

Thus, connecting private computing environments to Google Cloud in a secure and reliable manner is key to any successful hybrid or multi-cloud deployment. Basically, the network topology that you choose for a hybrid and multi-cloud setup needs to meet the unique requirements of your enterprise workloads and suit the architecture patterns that you intend to apply. Although each topology might need tailoring, there are common topologies that can be used as a blueprint.

Meshed

The idea of the meshed topology is to establish a flat network that spans multiple computing environments in which all systems can communicate with one another. This topology applies primarily to tiered, partitioned, or bursting setups, and requires that you connect computing environments in a way that meets the following requirements:

• Workloads can communicate with one another across environment boundaries over UDP or TCP by using private RFC 1918 IP addresses.
• You can use firewall rules to restrict traffic flows in a fine-grained fashion, both between and within computing environments.

Reference architecture

The following diagram shows a reference architecture that satisfies these requirements.

Best Practices

If you intend to enforce stricter isolation between the cloud and private computing environments, consider using the gated topology instead.

When using Kubernetes within the private computing environment, use Open Service Broker to provision and access Google platform services and resources in a unified way.

Also consider the general best practices for hybrid and multi-cloud networking topologies.

Gated Egress

The idea of the gated egress topology is to expose selected APIs from the private computing environment to workloads that are deployed in Google Cloud without exposing them to the public internet. You can facilitate this limited exposure through an API gateway that serves as a facade for existing workloads. You deploy the gateway in a perimeter network (DMZ) while deploying workloads in a dedicated, more highly secured network within the private computing environment.

The gated egress topology applies primarily to tiered setups and requires that you connect computing environments in a way that meets the following requirements:

• Workloads that you deploy in Google Cloud can communicate with the API gateway by using private IP addresses. Other systems in the private computing environment cannot be reached from within Google Cloud.
• Communication from the private computing environment to any workloads deployed in Google Cloud is not allowed.

Reference architecture