Netflix 是一家基于订阅的视频流公司，也是大规模实践微服务架构的先驱之一，其中所有视频流功能都是通过面向外部的托管服务（或 API）提供给消费者的，有数百个后端服务支撑着其 API。因此，在 Netflix 使用场景中，进程间（或服务间）通信是最重要的方面之一。在微服务实现的初期，Netflix 使用基于 HTTP/1.1 的 RESTful 服务构建了自己的进程间通信技术栈，这支撑了 Netflix 产品大约 98% 的业务场景。
但是，在互联网规模的运维中，Netflix 发现了 RESTful 服务方式的一些局限性。对于 RESTful 微服务的消费者，他们会首先探查 RESTful 服务的资源及其所需的消息格式，然后开始进行编写。这种方式非常耗时，影响了开发人员的效率，并且增加了代码出错的风险。由于缺乏统一的服务接口定义，服务的实现和消费也面临着挑战，因此 Netflix 最初想构建一个内部的 RPC 框架来突破这些限制，但在评估了可用的技术栈后，它选择了 gRPC 作为其服务间通信技术。在评估的过程中，Netflix发现 gRPC 最实用的地方就是将所有需要的职责封装到一个易于使用的包中。
在采用 gRPC 之后，Netflix 见证了开发效率的巨大提升。举例来说，对于每个客户端，几百行的自定义代码被替换成了只有两三行的 proto 配置代码。原来创建客户端可能需要两三周的时间，现在使用 gRPC 几分钟就能完成。平台的稳定性也得到了很大的提升，这是因为大多数商业化特性不再需要手动编写代码，而且现在有了一种全面且安全的方式来定义服务接口。得益于 gRPC 所带来的性能提升，Netflix 整个平台的延迟也有所减少。由于大多数的进程间通信场景已采用了 gRPC，因此对于一些为使用 REST 和 HTTP 等协议的进程间通信而构建的内部项目（如 Ribbon），Netflix 似乎已将其设置为维护模式（不在积极开发中），并转而使用 gRPC。
