App Hub is available in supported locations to help you organize your Google Cloud infrastructure resources as applications, whether these resources are available globally or within specific regions. This capability simplifies management by letting you group resources based on their geographical location and how they interact with other parts of your infrastructure.
When creating an App Hub application, you define its location as either global or regional . This choice is fundamental in determining which services and workloads can be part of the application based on their extent. Also, this choice has important implications for data handling, colocation, cost, and compliance. Global and regional applications are defined as follows:
-
Global applications:Functionally group services and workloads that are globally distributed or spread across multiple Google Cloud regions. For example, you can include resources such as a global Application Load Balancer and its backend services distributed worldwide.
-
Regional applications:Functionally group services and workloads that reside entirely within a single Google Cloud region. For example, you can include a regional Application Load Balancer and its backend services, all located in
us-central1.
To make the best decision for your needs, it's crucial to understand Google Cloud regions and zones, which are designed to provide fault tolerance and high availability. Regions are independent geographic areas, and zones are deployment areas within a region, acting as single failure domains. To learn more about global and regional resources, see Geography and regions and Cloud locations .
Compare global and regional applications
The following table highlights the key differences and considerations to help you choose between global and regional applications:
| Global application | Regional application | |
|---|---|---|
|
Recommended use case
|
Best for applications composed of Google Cloud resources that are inherently global or distributed across multiple regions. | Recommended when all application components reside within the same Google Cloud region, even if they span multiple projects. |
|
Resource extent
|
Can contain both global and regional resources from any region. | Can only contain resources from the same single region as the application. You cannot register global resources in a regional application. |
|
Application metadata
|
Stored across multiple regions and accessible from any Google Cloud
region. Data residency is not supported. |
Stored within the specific region but accessible from any other
Google Cloud region. Data residency is not supported. |
|
Examples
|
Managing a global load-balanced application with backend services in various regions to provide a centralized view of the distributed system. | Managing an application with all services and workloads in us-central1
. |
Select the best location for your application
Consider the architecture and operational requirements of the business function the application represents when choosing between global and regional locations. The following comparison is based on resource extent considerations:
- In general, regional applications offer significant benefits over global applications. If you want to take advantage of lower service latency, alignment with data locality requirements, potential network cost savings, and inherent consistency with region-specific Google Cloud features, opt for regional applications.
- If your application components are necessarily distributed across multiple regions or rely on global Google Cloud services, opt for global applications.
You might have resources located in multiple regions that don't form a single, cohesive global function. In that case, it is often best practice to define separate regional applications for the resources within each region. This approach maximizes the benefits of regionalization for each deployment.
Your Google Cloud resource hierarchy, which defines how you organize folders and projects, is also fundamental. A well-planned hierarchy that aligns with your application boundaries, whether regional or global, simplifies the grouping and management of resources within App Hub. For more information, see Choose your App Hub setup model .
Benefits of regional applications
While global applications offer flexibility for distributed systems, choosing a regional location for your App Hub applications can provide significant advantages:
-
Support data residency and compliance:While App Hub metadata doesn't offer data residency , a regional application helps you make sure that the actual data the underlying resources process and store remains within the geographic boundaries you select. This benefit is often crucial for complying with legal, regulatory, and organizational requirements for data locality.
-
Reduce latency:Colocating application resources within the same region generally minimizes network latency between services , potentially improving application performance and user experience.
-
Meet product feature requirements:Certain Google Cloud services or features mandate that all interacting resources be located in the same region. For example, a Compute Engine instance can only attach a persistent disk that is in the same region. A regional App Hub application aligns inherently with such architectural constraints.
-
Optimize cost:Data transfer between different Google Cloud regions often incurs networking costs , whereas network traffic within the same region is typically priced lower. By creating your application regionally, you can better manage and reduce cross-region network charges.
-
Align with failure domains:Google Cloud regions are designed to be independent failure domains . Deploying your application within a single region and using multiple zones within that region for high availability aligns your application's fault tolerance with Google Cloud's infrastructure resilience model.
