Tutorial Series: Application Hub in Google Cloud | by Romin Irani | Google Cloud – Community | May, 2025

Welcome to the series on App Hub, a service that enables you to build, operate, and manage applications on Google Cloud. Through this series, I hope to dissect how this service could be the cornerstone of your Google Cloud applications, bringing a structured view to the underlying infrastructure resources and by doing that, helping developers, operators, financial folks and other roles across the organization to easily view the information that matters quickly.

One of the goals of Platform Engineering is to reduce the cognitive load on developers by abstracting away the complexities of underlying infrastructure. What exactly are we talking about here? Let’s try and understand it vis-a-vis a single Google Cloud Project and then you will be able to appreciate it more as the number of projects increase across an organization.

We will consider a single Google Cloud Project as a start. We know that a project in Google Cloud is like an umbrella entity under which various resources exist. Ofcourse, there is the added complexity of Organization → Folders → Projects that we are aware about, but let’s stay in this blog post at the Google Cloud Project level only.

Now, let us assume the following list of resources in this project:

• 5 Cloud Run applications ( app1, app2, app3, app4, app5)
• Each of the Cloud Run applications utilizes:
  – a couple of Google Cloud Storage buckets
  – one Pub/Sub resources
  – one Cloud SQL instance
  – possibly other things like Cloud Logging

The real world is a bit messy and these projects have been developed, modified over a period of time by different teams. While due care has been taken to name the resources in a certain fashion, use tagging as needed, etc — the reality is that we possibly have a high level diagram that looks something like this:

The above is one way to look at the resources that you have in the project. I have oversimplified the diagram and most likely in the real world, you would try your best to make sense of this by highlighting for e.g. app 1 using bucket 1 and bucket 2, and topic 3 of Pub/Sub and Cloud SQL 4 instance.

You might actually end up with something like this:

Surely I could have used better diagramming tools, did a bit of labelling and more. But you get the essence of where I am leading. This is a bit of an organizational mess. This can be severely compounded if you extrapolate with more projects, additional Google Cloud resources within projects, lack of norms when it comes to naming resources, incorrect or insufficient usage of tags to label resources, etc.

This is also not to appreciate several organizations and teams that have over the years been diligent and have taken the pain to truly embrace platform engineering and make it easier for teams, different roles of users to navigate through this and make it easier to manage applications right across design, development, operations to optimization stages.

Consider the following real world scenario. You have deployed App 2 to Cloud Run. It is running fine but one day, users start complaining about the latency of your deployed web application. Let’s assume that App 2 is a Mobile Payments application that users use to pay their bills. You may have created the right monitoring dashboards, proactive alerts, synthetic monitors to get notified before users tell you but the fact remains that if users or most of your own folks report an issue, they might end up saying that the Mobile Payments App is running slow. Now, what do you typically start doing? In most cases, you need to first have the mental map or information in place that Mobile Payments App is the following set of resources:

• App 2 in Cloud Run
• Cloud SQL 2 instance
• Google Cloud Bucket Names (bucket 1 , bucket 2)

and so on.

You need to have that information and the only way to do that is to either have it documented or the right kind of labels/tags that help you zoom into the respected cloud resources to help you debug what could be going on. Once over there, you need one or more of a few things like:

• You will need to further filter your Cloud Monitoring Dashboards to get those initial signals that could indicate something is wrong.
• Once there, the next port of call would be Cloud Logging logs filtered as per these specific Application resources.

You get the picture. Its not an easy task and once you multiply this by number of applications, services and the interconnectedness between them, it is a tough situation.

The question to ask here is what is Google Cloud doing in this regard to make it easier from a Platform Engineering perspective. Is there a new abstraction that makes it easier for different roles in the organization (developers, operations, architects, etc) to avoid the cognitive overload that we just saw, can isolate their application resources, can get the views / data specific to their applications for a simple question like “My Payment App is running slow”?

At Cloud Next ’25, Google Cloud announced App Hub, a service that enables you to build, operate, and manage applications on Google Cloud. There are quite a few terms being thrown here: build, operate and manage applications and each of these areas can be several articles in themselves.

My goal here would be to show you a glimpse of App Hub in probably what I understand is the simplest way to begin to organize your Cloud resources into a new abstraction or container if you would allow me to call that and that abstraction is the Application.

From the existing documentation, we have the following definition:

App Hub provides an application-centric way to organize these resources to help you understand resource interactions and support business functions.

We saw for example that we had 5 Cloud Run applications and each of these applications used some infrastructure resources (Cloud Run service, Cloud SQL instance, Cloud Storage bucket, etc). App Hub helps organize these infrastructure resources by creating App Hub applications that include these resources as App Hub services and workloads.

And as a result and I quote from the documentation:
Registering services and workloads to an application can help you answer the following questions:

• How many applications exist across all my projects?
• How are the services and workloads in my applications dependent on each other?
• Who owns these applications, services, and workloads?
• How many applications are critical?

Its not just about answering only the above questions but you will also note as we go along in this series, how it helps to even monitor, view alerts, view logs in an application centric view. Think back to the original problem that was highlighted by the users, The Mobile Payments App is running slow.

In an App Hub world, you should be able to see Mobile Payments app as one of the applications in the overall list of applications. You should be able to zoom down into that application and see the cloud resources under it. For each cloud resources, you should be able to get individual monitoring data, logs and more. Makes sense isn’t it?

For a complete list of various use cases that a service like App Hub addresses, check out the documentation, but I list them at a high level here:

• Organize and categorize your applications
• Understand resources in your application Monitor resources in your application

App Hub eventually even integrates into services like AI powered assistance via Chat and other services, and Cloud Hub, which will allow a central place via which you can look at your overall application health, incidents, recommendations for optimization, cost management and more.

Think of Application Hub a central inventory. It catalogs the logical Applications and their constituent Services. Crucially, it stores higher-level Attributes (like business owner, criticality, documentation links) directly associated with the application/service definition within the Hub. It links to or discovers the running services/workloads, providing a structured view over the underlying tagged infrastructure.

Eventually this structured view over the underlying tagged infrastructure can be used across services that provide the data easily to different user roles in the organization. In summary, Platform Engineering facilitates deployment, resource tags provide low-level metadata on infrastructure, and Application Hub provides a higher-level catalog with business/operational context, serving different needs for various teams.

I encourage you to take a deeper look at the overview page if you’d like.

In the next part of the series, I will cover how we can construct an application from an existing set of cloud resources and get an application centric view of things. Stay tuned.