7.5.2: Google- API-Centric Architecture and gRPC

Google, as a company that builds at planetary scale, has also been a pioneer in distributed systems and web services (though they often didn’t use the same buzzwords externally). Google’s early approach to distributed computing involved a system called Stubby – this was Google’s internal RPC framework (somewhat analogous to a proprietary gRPC predecessor). For over a decade, Google used Stubby as a “single general-purpose RPC infrastructure” to connect the myriad microservices running in their data centers. All of Google’s core services (Search, Gmail, YouTube, etc.) are powered by many internal microservices that communicate via RPC calls. The focus was on high performance and uniformity: Stubby allowed them to apply fleet-wide improvements in security and efficiency easily, since everything used a common RPC layer.

By mid-2010s, Google decided to rework Stubby using open standards like HTTP/2, and they open-sourced this as gRPC. gRPC became an open-source project in 2015 and reached 1.0 in 2016. Google Cloud Platform (GCP) services often expose both REST and gRPC endpoints now. For example, the Cloud Pub/Sub service has a REST API and a gRPC API. Google’s own client libraries for cloud services often use gRPC under the hood for better performance, but they provide a RESTful HTTP+JSON interface for convenience and interoperability. This dual approach is interesting – it shows that REST and gRPC can coexist: REST for broad compatibility, gRPC for internal or high-performance needs.

Beyond gRPC, Google has a culture of exposing capabilities via APIs. Google Maps API, for instance, was one of the early popular public web services (initially XML, later JSON REST API) that allowed any third-party to embed maps or get geocoding data. Google’s APIs span from YouTube (to upload videos or get analytics) to Google Drive, Google Docs, etc. They have used a variety of technologies: SOAP was used in some older APIs (e.g., AdWords API was originally SOAP-based), but most newer ones are REST/JSON. They also contributed to the OpenAPI specification for describing APIs.

Google’s API design guidelines (which they’ve published for Google Cloud) emphasize consistency and a degree of generative design. They often design RESTful APIs in a way that an API method corresponds to a gRPC method, etc. Their internal systems might be gRPC, and then an external REST API is auto-generated from that (with mappings of HTTP verbs to gRPC calls). This is a pattern many companies follow now – design the service as gRPC (with strong typing), then expose RESTful JSON by automatically translating (using tools like grpc-gateway).

A real-world example: Google’s Kubernetes project (open-sourced) exposes a RESTful HTTP API for all cluster operations (pods, services, deployments). Internally, Kubernetes components communicate in part via gRPC. But any user or tool can talk to the Kubernetes API using standard REST calls (often with JSON responses). This combination shows how web services principles are applied: an easily consumable REST API for users, backed by efficient internal communication.

Another example, Google’s Firebase Cloud Messaging (FCM) – it offers an HTTP+JSON API to send push notifications, as well as legacy XMPP. Internally, it’s likely fanning out messages through an optimized infrastructure.

In terms of enabling cloud-based communication, Google’s contribution of gRPC has been influential. Many organizations (not just Google) use gRPC now for microservice intercommunication because it brings the benefits of a distributed object/RPC system (efficient binary protocol, clear interface definition) without some of the earlier pitfalls (it is designed with modern networks in mind, e.g., handles streams and async, uses HTTP/2 which is firewall-friendly).

Google also illustrates the importance of APIs for external ecosystem. Google’s success of Android was partly due to APIs that third-party apps could use (Google Maps API on Android, etc.). And for enterprises, Google Cloud’s viability hinges on how well developers can integrate via APIs.

In summary, Google’s case shows that at the highest scales, the fundamentals of distributed objects and web services still apply: you need an RPC mechanism (they went with their own and then gRPC), you need clear interface definitions (protobuf IDL, analogous to CORBA IDL but simpler), and you expose services to the outside world via standardized APIs (largely RESTful or gRPC). They also highlight performance considerations that come in at scale – hence their heavy investment in binary protocols, HTTP/2, etc.

---