App Hub overview (original) (raw)

As you develop your cloud infrastructure, you might organize your Google Cloud resources across multiple projects. You might also have many resources within one or multiple projects that provide an integrated business function that you want to group logically. The resource hierarchy in Google Cloud can make it challenging to manage and organize your infrastructure for these grouping purposes. App Hub provides an application-centric way to group and manage services and workloads, helping you align your infrastructure with your business functions.

App Hub acts as the foundational data model and central registry for your applications on Google Cloud. It creates a single source of truth that clarifies resource ownership, dependencies, and business context. This, in turn, supports other Google Cloud products with the application-centric context they need. For more information about this application-centric model and its features, see Application-centric Google Cloud.

This document provides a conceptual overview of App Hub to help you understand its capabilities and benefits before you set up or administer it.

Why use App Hub?

By shifting the focus from individual infrastructure resources to the applications they form, App Hub helps you streamline governance and operations at scale.

App Hub helps you implement the following application-centric capabilities:

Organize and catalog your applications: Group scattered Google Cloud resources from one or more projects into logical App Hub applications. You can then find properties and categorize these applications with attributes like owners, business criticality, and environment to improve discoverability and accountability. For more information, seeProperties and attributes.
Create a unified view for your teams: By defining an application in App Hub, you provide essential context to other Google Cloud products. For example, you might enable the following features:
- A central view of operations and insights inCloud Hub, which displays alerts, incidents, and performance data in an application context.
- AI-powered assistance fromGemini Cloud Assist, which uses App Hub's data model to help you design, operate, and troubleshoot your applications.
- Application monitoring withGoogle Cloud Observabilityto help you troubleshoot errors and improve performance by displaying telemetry data for your applications and their components.
Clarify ownership and dependencies: Understand how your applications are composed and how their components depend on each other. This feature helps developers and operators visualize application architecture, identify owners, and resolve issues.

To learn more about how App Hub fits into the broader application lifecycle, see Application-centric Google Cloud.

App Hub concepts and data model

App Hub is built on a data model based on the following key concepts: applications, services, and workloads. These terms are common in the industry, but App Hub uses them in a specific way.

The following table compares the App Hub definition with common industry usage:

Concept	App Hub definition	Common industry usage
Application	A logical grouping of services and workloads that together deliver a business function.	Can refer to a single deployable unit, a codebase, or a broad system.
Service	A network or API interface that exposes functionality to clients and can route requests to workloads, such as a load balancer.	Often refers to a microservice, a deployable component, or binary code with its own business logic and data.
Workload	The compute resources where the binary deployments of your application are installed. The application code from these resources performs a discrete part of your business logic. For example, a workload can be a GKE deployment or a Compute Engine managed instance group (MIG) running the code of an AI agent.	A more general term for any process or component that consumes computing resources.

For more information about these and other Application-centric Google Cloud central concepts, seeKey concepts. For a list of supported resources in App Hub that you can register as services or workloads in your applications, seeApp Hub supported resources.

You can define App Hub applications based on your geographic distribution requirements. Your location choice impacts which services and workloads you can register in applications and can be important for data residency requirements. You can designate the following locations:

Global applications: group services and workloads from multiple Google Cloud regions.
Regional applications: group services and workloads that all reside within a single region.

For a detailed comparison to help you choose the right location, seeGlobal and regional applications.

Services and workloads show a registration status in your applications. Additionally, applications, services, and workloads can contain metadata in the form ofproperties and attributes.

You can view details of your deployed applications and their services and workloads, including location, registration status, and metadata. For more information, seeView details of services and workloadsand View application details.

Registration status of services and workloads

The organizational structure of your Google Cloud resources affects how App Hub can manage services and workloads and lets you register them in applications. Services and workloads that you canregister to an application have one of the following registration status:

Discovered: Services and workloads that you can register to an application because they are part of theapplication management boundary and that aren't registered to any other application or can be registered to multiple applications. The discovered status also includes services and workloads that you delete or unregister from an application but that you can register again.
Registered: Services and workloads registered to an application and managed by App Hub. You can only register discovered services and workloads. After you register the service or workload, the registration status updates from discovered to registered.
Detached: Services or workloads that have been registered to an application, but that App Hub can't manage or monitor because their underlying Google Cloud resources are no longer part of the application management boundary that you have defined. The registration status of services and workloads registered to an application can change to _detached_for the following reasons:
- The underlying resource is deleted. For example, if you delete a forwarding rule represented by a service, the service's registration status changes to detached.
- A project or folder containing underlying resources for registered services or workloads is moved out of the application management boundary.
  Detached services and workloads remain in the application until youunregister them.
  If you move a project out of the application management boundary, its detached services and workloads can become discoverable for applications in a different boundary. You canregisterdiscoverable services and workloads again, adhering to theresource hierarchyestablished by the application management boundary.

To select an application management boundary that fits your resource hierarchy in Google Cloud and let App Hub discover and register the services and workloads that your business needs, seeChoose your application setup model. To view the registration status of services and workloads, seeView details of services and workloads.

Properties and attributes

To enrich the data model, App Hub lets you expose properties and attributes to support application discoverability, accountability, and governance. Defining these values as application metadata helps you filter, manage, and apply policies to your application components at scale.

To view the properties and attributes of the services and workloads in your applications, seeView details of services and workloads.

The following are the definitions and features of properties and attributes:

Properties are immutable fields that describe the underlying infrastructure of a registered service or workload, such as the project ID, location, or type. These are discovered automatically and cannot be edited in App Hub. Key supported properties include:
- (Preview)Registration type: for services, an output-only property that indicates if a service can be registered to one or multiple applications. The following are the possible values for this property:
  * EXCLUSIVE: you can only register the service to a single application.
  * SHARED: you can register the service to multiple applications. This value indicates that the service is ashared service.
- (Preview)Functional type: an output-only property that identifies the known function of a service or workload. For example, when an AI agent is deployed through a managed platform likeVertex AI Agent Engine, App Hub automatically classifies the resource with the AGENTfunctional type value to indicate that the workload runs an AI agent.
- (Preview)Extended metadata: an schema-driven property that provides rich, structured information about the service or workload. It refers to a key-value field that adds detailed, type-specific data. For example, workloads with a functional type value of AGENT can includeapphub.googleapis.com/AgentProperties metadata, which contains information about an agent that is compatible with theAgent2Agent (A2A) Agent Card. For a list of supported metadata types and their schemas, seeExtended metadata schemas.
- (Preview)Identity: an output-only property that contains the service account or managed workload identity name for a service or workload.
Attributes are mutable, user-defined metadata that you can apply to applications, services, and workloads to organize and govern them. You can add attributes to applications, services, and workloads when youcreate an application and register resources to it. You can alsoupdate service and workload attributesand update application attributes. Key attributes include:
- Owners: Contact information for developer, operator, and business teams. The supported owner types are:
  * developer_owners: Development team that owns development and coding.
  * operator_owners: Operator team that ensures runtime and operations integrity.
  * business_owners: Business team that ensures quality and user expectations are met.
- Criticality: The importance of the component to your business. The supported values are:
  * MISSION_CRITICAL
  * HIGH
  * MEDIUM
  * LOW
- Environment: The lifecycle stage of the component. The supported values are:
  * PRODUCTION
  * STAGING
  * DEVELOPMENT
  * TEST

The App Hub resource model

To enable application-centric features, App Hub uses a resource model centered on the concepts of themanagement project and theapplication management boundary.

Recommended: Folder-level boundary: If your components are organized within a Google Cloud folder structure, you can use a folder as your boundary. This approach aligns your application management boundary with your organization's structure by business unit, environment, or team, and automatically includes all projects within that folder.
(Preview)Single-project boundary: For small applications where all Google Cloud resources reside in one project, you can designate that single project as your boundary. This is the quickest way to get started with application management. You can define single-project boundaries by configuring the project as a standalone management project.
(Legacy) Multiple-project boundary with a host project: For existing users, App Hub supports a legacy model where you can designate a host project for application management by enabling the App Hub API on a Google Cloud project. Then, you manually connect other Google Cloud projects, known as service projects, to it for multi-project resource discovery.

This application management layer that App Hub introduces on top of your resource hierarchy in Google Cloudlets App Hub discover supported resourceswithin the boundary. You can choose a setup model for applications and set an application management boundary that best fits your resource hierarchy and governance needs.

For information about data handling in this resource organization and other application-centric features, seeApplication-centric Google Cloud. For details about getting started and defining an application management boundary, seeChoose your application setup model.

What's next

To see which Google Cloud resources you can register in App Hub, see Supported resources.
To get started with defining an application management boundary, seeChoose your application setup model.
To understand the permissions required to use App Hub, seeRoles and permissions.