This document discusses architecture patterns for how to find and collectinformation about assets in Google Cloud, in other cloud platforms, andon-premises by using ServiceNow cloud discovery. The document is intended forarchitecture teams or cloud operations teams that are familiar with IToperations management (ITOM); Information technology infrastructure library(ITIL); Google Cloud services such as Compute Engine,Google Kubernetes Engine (GKE), and Cloud Asset Inventory; and ServiceNow Cloud Discovery.

Overview

Many large enterprises use a hybrid IT infrastructure deployment that combinesGoogle Cloud, other cloud platforms, and on-premises infrastructure. Sucha hybrid deployment is typically the initial iteration in a cloud migrationstrategy. IT departments in these enterprises are required to discover and keeptrack of all the assets in their technical ecosystem, which can potentiallynumber in the millions. The IT departments must construct a configurationmanagement system that ties these assets together with the technical servicesthat the assets provide. This system must also monitor the assets and servicesin a way that supports IT operations management (ITOM) and IT service management(ITSM) best practices.

For Google Cloud customers, a common architecture uses ServiceNowcloud resource discovery to find and collect information about assets in Google Cloud, in othercloud platforms, and on-premises. ServiceNow offers a wide range of tools forautomating resource-management IT workflows across multiple cloud providers.Tools such asCloud Operations Workspace let IT departments create multi-cloud resource dashboards and manage complexconfigurations through a unified interface (sometimes called asingle pane ofglass). This document presents a set of architecture patterns for thisscenario, an overview of its high-level components, and a discussion of generaldesign considerations.

ServiceNow components for this architecture

The ServiceNow platform components in these architecture patterns include thefollowing:

• A ServiceNow instance that contains aconfiguration management database (CMDB) of configuration items (CIs). Each CI represents components in youroperational environment that are involved in the delivery of digitalservices. A CI has multiple attributes that contain specific metadata aboutthe component and itsrelationships to other CIs.
• One or moreServiceNow Management, Instrumentation, and Discovery (MID) Servers,running in your Google Cloud project. MID Servers collect themetadata for CIs and store it in the CMDB.

These architecture patterns define some common practices for importing GoogleCloud Asset Inventory data into ServiceNow'sGoogle Cloud Platform asset inventory discovery.

Architecture patterns for Google Cloud integration

This document discusses the following architecture patterns for integratingGoogle Cloud into ServiceNow:

• Google Cloud discovery pattern

• Google Cloud agentless IP discovery pattern

• Google Cloud discovery with Agent Client Collector pattern

These example architecture patterns are designed for a hybrid deployment thatincludes some infrastructure in Google Cloud and some in the ServiceNowcloud. They demonstrate how ServiceNow operates in Google Cloud betweenGoogle-managed infrastructure and customer-managed infrastructure. ServiceNowMID Servers query all Google-managed infrastructure by calling GoogleCloud APIs.For more information about which APIs are called, seeGoogle Cloud Platform APIs used by ITOM applications.

In each of the following patterns, the architecture components work together intheGoogle Cloud Platform asset inventory discovery process to collect the cloud asset inventory information required by the ServiceNowDiscovery application and related tools.

Google Cloud discovery pattern

The basic ServiceNow cloud discovery architecture pattern uses ServiceNow MIDServers to call Google Cloud Asset Inventory and other GoogleCloud APIs to gather data about resources such as the following:

• VM instances
• Tags (keys/values)
• Storage volumes and storage mapping
• Data center resources, including hardware types
• Cloud networks, subnets, and gateways
• Images
• Cloud load balancers and availability zones
• Cloud databases and database clusters
• Containers (GKE)
• Service mapping based on resource labels

In this pattern, the MID Servers don't need credentials, because they don't loginto the VMs to collect data. This limits the ability of the discovery processto gather additional information. But it imposes less operational cost, becauseit removes the need to manage and rotate MID Server credentials.

The following diagram illustrates this architecture pattern.

The Google Cloud portion of this pattern consists of the following:

• One Google Cloud project (Service Project A in the diagram), whichconsists of two Google Cloud load balancers, one or more VMinstances, a GKE instance, and one or more ServiceNowMID Servers. Each MID Server runs in its own VM.
• A second Google Cloud project (Service Project B in the diagram),which consists of MID Servers running in their own VMs.
• A third Google Cloud project (Host Project C in the diagram), whichconsists of the partner interconnect.
• Additional managed services, such as Cloud APIs,BigQuery, and Cloud Storage.
• Network routes that are set up from the MID Servers to the GoogleCloud APIs.

The ServiceNow portion consists of the ServiceNow instance, which captures themetadata from the MID Servers and stores it in the CMDB.

Google Cloud agentless IP-based discovery pattern

This architecture pattern addsIP-based discovery to the basic cloud discovery pattern by using a batch job and aGoogle Cloudservice account to log into VMs and gather additional details. This pattern requires more of anoperational burden to manage the MID Server than with the basic pattern, becauseit requires you to manage and rotate the MID Server credentials. However, itexpands the discovery process beyond the data provided by Cloud Asset Inventory toinclude additional data, such as the following:

• OS credential management and security
• Enhanced discovery, such asfile-based discovery and discovery of licenses
• OS details
• Running processes
• TCP connections
• Installed software

In this architecture pattern, one or more ServiceNow MID Servers are located inGoogle Cloud, while the ServiceNow instance is hosted in the ServiceNowcloud platform. The MID Servers are connected to the ServiceNow instance throughtheMID Server External Communication Channel (ECC) Queue (not shown). This architecture is shown in the following diagram.

The Google Cloud portion of this pattern consists of the following:

• Service Project A, which consists of two Google Cloud loadbalancers, one or more VMs, a GKE instance, and one ormore ServiceNow MID Servers. Each MID Server runs in its own VM.
• Service Project B, which consists of MID Servers that run in their own VMs.
• Host Project C, which consists of the partner interconnect.
• Additional managed services, such as Cloud APIs,BigQuery, and Cloud Storage.
• ServiceNow Kubernetes Discovery deployed on the GKEinfrastructure.
• Network routes that are set up from the MID Servers to the GoogleCloud APIs.
• Service accounts that enable MID Servers to log into anyGoogle Cloud VMs that require serverless IP address discovery.
• Network routes that are set up from the MID Servers to anyGoogle Cloud VMs that require serverless IP address discovery.

The ServiceNow portion consists of the ServiceNow instance, which captures themetadata from the MID Servers and stores it in the CMDB.

Google Cloud discovery with Agent Client Collector pattern

This architecture pattern includes the following:

• The initial cloud discovery.
• One or more MID Servers.

• An additional ServiceNow agent, theAgent Client Collector, which youinstall on your VMs. These agents connect directly to the MID Servers andrelay the following additional information to ServiceNow:

  • Near real-time push-based discovery
  • Software metering
  • Live CI view
  • Workflow automation to servers

The following diagram illustrates this architecture pattern.

The Google Cloud portion of this pattern consists of the following:

• Service Project A, which consists of two Google Cloud loadbalancers, one or more VM instances, a GKE instance,and one or more ServiceNow MID Servers. Each MID Server runs in its own VM.
• Service Project B, which consists of MID Servers running in their own VMs.
• Host Project C, which consists of the partner interconnect.
• ServiceNow Kubernetes Discovery deployed on the GKEinfrastructure.
• Additional managed services, such as Cloud APIs,BigQuery, and Cloud Storage.
• Network routes that are set up from the MID Servers to the GoogleCloud APIs.
• Network routes that are set up from the MID Servers toGoogle Cloud VMs that have ServiceNow Discovery Agents installed.

The ServiceNow portion consists of the following:

• The ServiceNow instance, which captures the metadata from the MIDServers and stores it in the CMDB.
• ServiceNow discovery agents that are installed on customer-managedGoogle Cloud VMs.

Cloud asset discovery workflow

The following sections discuss the workflow for Google Cloud assetdiscovery. This workflow applies to all three of the architecture patternsdescribed in this document.

Install and configure ServiceNow components

1. Enable the Cloud Asset Inventory APIs.
2. Install Agent Client Collector on your VMs. For more information, seeAgent Client Collector installation.
3. Allocate resources for computers that host the MID Servers.
4. Configure firewall rules to allow connections on port 443 between your VM instance and the computersthat host the MID Servers.
5. Configure MID Server network connectivity.
6. Install the MID Servers.
7. Configure the MID Servers tocall the relevant Google Cloud APIs.Make sure that the MID Servers have a valid network route to call GoogleCloud APIs.

Workflow

1. Cloud Asset Inventory compiles a database of allsupported asset types in the Google Cloud environment. ServiceNow uses Cloud Asset Inventoryas the source to retrieve additional information to update the CMDB.
2. The ServiceNow MID Servers query the Cloud Asset Inventory database forinformation about all of the assets in the Google Cloud environment.
3. The MID Servers store the cloud asset information in aCloud Storage bucket.
4. Not all required information can be obtained from the Cloud Asset Inventorydatabase. In the agentless pattern, the VM information doesn't include thecurrent OS patch version. For this level of detail, the MID Servers performadeep discovery by doing the following:
   1. The MID Servers create a batch job based on the IP addresses ofthe VMs that require a deep discovery.
   2. In the batch job, the MID Servers log into each VM and query theOS for patch versioning and other information.
5. If Agent Client Collectors are installed, the data that they capture istransmitted to the MID Servers directly, rather than stored in theCloud Asset Inventory database. For more information, seeNetworking Preparation andMID Server Configuration.
6. After collecting the asset discovery data, the MID Servers store it intothe CMDB as follows:
   1. The MID Servers create CIs in the CMDB to represent theoperational capability provided by each asset.
   2. The MID Servers automatically discover labels fromGoogle Cloud and store them in the CMDB. These labels are mappedto the CIs automatically and are useful for creatingservice maps.

The workflow process should be repeated periodically as needed. Depending onthe scale and configuration of your deployment, you might choose event-based orschedule-based discovery. For more information, see "Managing the CI lifecycle"inCMDB Design Guidance.

Design considerations

The following sections provide design guidance for implementing any of thearchitecture patterns that are described in this document.

Location of the ServiceNow instance

For most use cases, we recommend deploying the MID Servers inGoogle Cloud. That way the instances are close to the cloud assets onwhich they perform deep discovery.

The architecture patterns in this document assume that your CMDB storesdiscovery data for all your cloud resources and for all on-premises resources,not just your Google Cloud assets. The CMDB can be located in theServiceNow cloud, in Google Cloud, or on-premises. The ultimate decisionabout where to locate the CMDB in your environment depends on your specificrequirements.

Deciding to use MID Server agents

Another design consideration is whether to use MID Server agents and serviceaccounts. If your discovery process needs to collect information beyond themetadata that Cloud Asset Inventory provides, you need to use a MID Serverinfrastructure with service accounts, or alternatively, a MID Server withAgent Client Collector.Either approach can affect your operational support cost, which you mustconsider in your design. The approach that you should use depends on what datayou need to capture and how you will use the data. The operational cost ofcapturing the data might outweigh the value that the data provides.

Multi-region support for MID Servers

If your company requires multi-region support of the MID Server infrastructure,you should plan to deploy each MID Server in at least two availability zones andreplicate it into anotherregion.

Cost implications

When you choose where to deploy the ServiceNow components forGoogle Cloud asset discovery, you need to consider egress cost and compute cost.

Egress cost

Egress charges are incurred whenever data moves out of Google Cloud. For this reason, youshould analyze the egress cost for your use case to determine the best optionfor locating your ServiceNow components. Typically, MID Servers that performdeep discovery incur lower egress costs if they are running inGoogle Cloud than if they run on another cloud or on-premises.

Compute cost

ServiceNow components that run in Google Cloud incur compute costs thatyou should analyze to determine the best value for your company.

For example, you should consider the number of MID Servers that you deploy inGoogle Cloud Compute Engine instances. Deploying more MID Serversmakes the asset discovery process go faster. But doing so increases computecost, because each MID Server is deployed in its own VM instance. For moreinformation about whether to deploy one or multiple MID Servers, seeInstall multiple MID Servers on a single system.

Operational supportability considerations

Your deployment likely includes network security controls such as firewalls,intrusion protection systems, intrusion detection systems, and packet mirroringinfrastructure. If there are extensive network security controls in placebetween Google Cloud and the environment where the MID Servers aredeployed, these controls can create operational supportability issues. To avoidthese issues, we recommend that you host the MID Servers in Google Cloudor as close as possible to the Google Cloud infrastructure that a deepdiscovery will query against.

Securing MID Servers

We recommend the following security practices for your MID Server instances:

• Make sure that the MID Servers areisolated to help ensure that only trusted administrators can connect to them.
• Make sure that theMID Servers are protected from deletion.
• Make sure that IAM roles are applied to limit the capability for changesto only those changes that are approved through ITIL processes or through aCI/CD pipeline.

Securing service accounts

We recommend the following security practices for managing service accounts:

• Make sure that the MID Servers use a service account that has only theIAM roles and permissions that are absolutely necessary for assetdiscovery. For more information, seeBest practices for working with service accounts.
• ServiceNow authentication requires copying the content of a service account key into the ServiceNowuser interface. Service account keys are a security risk if not managed correctly. You are responsible for thesecurity of the private key and for other operations described by Best practices for managing service account keys.If you are prevented from creating a service account key, service account key creation mightbe disabled for your organization. For more information, see Managing secure-by-default organization resources.

  If you acquired the service account key from an external source, you must validate it before use. For more information, see Security requirements for externally sourced credentials.

Folder and project structure

Folders and projects are nodes in the Google Cloud resource hierarchy. Tosupport asset discovery, your folder and project structure should reflect thestructure of your application and of the environments where the application isdeployed. Structuring your resources in this way also makes it possible forServiceNow to map your assets to the technical services that they provide.

Be mindful of any changes you make to the folder and project structure tosupport ServiceNow discovery. The primary role of the folder and projectstructure is to support billing and IAM access. Therefore, any changes you maketo support ServiceNow should support and align to your organization'sGoogle Cloud billing structure. For best practices for structuring yourGoogle Cloud organization, folder, and project hierarchy, seeResource hierarchy andCreating and managing organizations.

The following diagram represents an example Google Cloud resourcehierarchy in its complete form. In this example, thefolder structure defines the application, and each project defines an environment.

Labeling

Labels are key-value pairs that you can assign to your cloud resources. (ServiceNow,AWS, and Azure refer to labels astags.)

ServiceNow uses the labels that you assign to your Google Cloud assets toidentify your assets and optionally map them to services.Choosing a good labeling scheme helps ServiceNow monitor your infrastructure foraccurate reporting and ITOM/ITSM compliance.

We recommend that you use labels for any resources that require uniqueidentification that is more specific than what your folder and project structureallows for. For example, you might want to use labels in the following cases:

• If there are strict compliance requirements for your application, youcan label all of the application resources so that your organization caneasily identify all the infrastructure that's in scope.
• In a multi-cloud environment, you can use labels to identify the cloudprovider and region for all resources.
• If you need more fine-grained visibility than what's provided by defaultbyGoogle Cloud Billing reports orCloud Billing export to BigQuery,the data can befiltered by labels.

Google automatically assigns labels to Google-managed assets that run in yourVPC. Google-assigned labels are prefixed withgoog-. Your MID Serversshouldn't attempt to perform a deep inspection on these assets. For moreinformation about labels for Google-managed resources, seeTag Based Mapping andLabel resources automatically based on Cloud Asset Inventory real-time notifications.

The following table lists labels that Google Cloud services assign toresources that those services manage.

To support resource management effectively, your organization's deploymentprocess must create project and folder structures and assign asset labelsconsistently across your entire organization. Inconsistencies in infrastructureand labeling can make it difficult to maintain a correct CMDB without manualprocesses that are likely to be unsupportable and that present scalingchallenges in the long term.

The following list suggests best practices for making your deployment processconsistent and repeatable:

• Use infrastructure as code (IaC) or automated provisioning systems suchasTerraform,ServiceNow ITOM,orCloud provisioning and governance withGoogle Cloud Deployment Manager.
• Have a good governance process in place for your labels. For an overviewof labeling governance, seeTag Governance in the ServiceNow documentation.

What's next

• Learn about theintegration connector for ServiceNow.
• For additional best practices for structuring your resources forCloud Billing, seeGuide to Cloud Billing Resource Organization & Access Management andCloud Insights setup guide for Google Cloud.
• For best practices for structuring your organization's IAM permissions,seeBest practices for planning accounts and organizations andCloud Provisioning and Governance.
• For best practices for structuring your VPC firewall policies acrossyour organization, seeHierarchical firewall policies.
• Learn how to use labels to support ServiceNowtag-based discovery.
• Learn aboutServiceNow Agent Client Collector,a push mechanism that runs in your Google Cloud project andsends output data to the ServiceNow instance through the MID Server,storing events and metrics in the relevant database.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.