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.