What is Google Service Management?

Google Service Management is an infrastructure service of Google Cloud Platform that manages other APIs and services, including Google's own Cloud Platform services and their APIs, and services created using Google Cloud Endpoints.

If you're a service user, or service consumer, you can use Service Management to discover services and enable and disable them for your Google projects. As a consumer, you can use Service Management via the Google Cloud Console (the simplest approach), from the command line with Google Cloud SDK (gcloud), or programmatically using the Service Management API. You can find out more about enabling and disabling services in Enabling and Disabling Services.

Service Management also provides functionality to service producers, including publishing their services on Google Cloud Platform so that service consumers can find and use them, managing service lifecycle, and integrating with logging and monitoring systems. Currently this functionality is provided for Google Cloud Platform users producing services via Google Cloud Endpoints, which handles many of the details of service configuration and management for you. If you're an Endpoints user you almost certainly won't need to call Service Management's producer API directly, though you'll interact with the gcloud command line interface for some deployment and management tasks.

Managed services

REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}
REST schema is defined here.

A managed service refers to a network service managed by Service Management. Each managed service has a unique name, such as example.googleapis.com, which must be a valid fully-qualified DNS name, as per RFC 1035.

A managed service typically provides some REST APIs and/or other functions to their service consumers, such as mobile apps or cloud services.

Service producers can use methods, such as services.create, services.delete, services.undelete, to manipulate their managed services.

Service producers

A service producer is the Google developer project responsible for publishing and maintaining a managed service. Each managed service is owned by exactly one service producer.

Service consumers

A service consumer is a Google developer project that has enabled and can invoke APIs on a managed service. A managed service can have many service consumers.

Service configurations

REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}/configs/{config_id}
REST schema is defined here.

Each managed service is described by a service configuration which covers a wide range of features, including its name, title, RPC API definitions, REST API definitions, documentation, authentication, and more.

To change the configuration of a managed service, the service producer needs to publish an updated service configuration to Service Management. Service Management keeps a history of published service configurations, making it possible to easily retrace how a service's configuration evolved over time. Service configurations can be published using the services.configs.create or services.configs.submit methods.

Alternatively, services.configs.submit allows publishing an OpenAPI specification, formerly known as the Swagger Specification, which is automatically converted to a corresponding service configuration.

Service rollouts

REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}/rollouts/{rollout-id}
REST schema is defined here.

A Rollout defines how Google Service Management should deploy service configurations to backend systems and how the configurations take effect at runtime. It lets service producers specify multiple service configuration versions to be deployed together, and a strategy that indicates how they should be used.

Updating a managed service's configuration can be dangerous, as a configuration error can lead to a service outage. To mitigate risks, Service Management supports gradual rollout of service configuration changes. This feature gives service producers time to identity potential issues and rollback service configuration changes in case of errors, thus minimizing the customer impact of bad configurations. For example, you could specify that 5% of traffic uses configuration 1, while the remaining 95% uses configuration 2.

Service Management keeps a history of rollouts so that service producers can undo to previous configuration versions. You can rollback a configuration by initiating a new Rollout that clones a previously submitted rollout record.

Was this page helpful? Let us know how we did: