MicroServices on gRPC

Nginx announced support for gRPC (check it out here) in mid march this year. This is a big deal for people who want to build microservices with gRPC. Developers can load balance gRPC based microservices behind Nginx and expose it out to the world.

The MicroService Architecture

Wikipedia states micro services architecture as :

Microservices is a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services.

A typical micro service setup has a lot of services communicating with the outside world as well as communicating with each other internally. These are deployed mostly inside the same cluster or a VPC.

Image result for microservices example

Till now the only available option(most reliable and easy to use) for inter service communication was REST APIs(HTTP calls). However google gRPC(check here) changes all that.

Google GRPC – Better than REST

Mobile

Google gRPC is a high performance open source remote procedure call framework.  Client machines can seamlessly call server machines as if they are in the same execution environment.

gRPC not only is newer technology , it also is much more optimized than the standard HTTP calls that one makes. As of today gRPC offers 2 performance advantages of over HTTP calls with out actually losing the anything that HTTP offers.

  • Google gRPC is based on HTTP2: That mean it has access to all the new features(Connection Multiplexing!!!) that it has to offer. Read about all the new features of HTTP2 here.
  • It uses protocol buffers for data transmission: Instead of relying on JSON or XML (which are extremely bulky) gRPC sends data using google ProtocolBuffers. This can decrease the size of the message being transmitted over the network by more than 30% on average and in some cases message size can be less then 20% of the original message. That directly translates to your system using anywhere between 30%-80% less bandwidth than before.

Components of GRPC

A gRPC calls has three basic components that make the protocol work.

  1. gRPC stub definition: This is a  configuration file which contains all proto definitions along with them it also contains declaration for all the remote procedure calls are to be served.
  2. gRPC Server: This is the actual server which will be serving your remote procedure calls. Kind of like an HTTP server
  3. gRPC Client: A remote gRPC server is accessed using a gRPC client.  This is what makes using  gRPC simple. Calling a gRPC method feels like calling another function.

 

How does gRPC fit into the microservice:

Instead of writing all the functionality of a micro service from the point of view of a HTTP call, one could simply write it from the prospective of a gRPC setup.

This would involve identifying all the actions that need to be provided by a microservice, declaring them in the proto file. The next step is to generate stubs for a server and a client for the gRPC service(I’ll follow up with a tutorial soon).

From a deployment prospective you will have to deploy the gRPC server as a microservice. You can go ahead distribute the gRPC client in to whomsoever you want ,and they will be able to use it seamlessly as a function or a method in their code base.

Polyglot implementation

Numerous number of times you would want to write the backend of a system in a high performance language like C++ , but also want the fast iteration capabilities of a language like Python.

More and more microservices are choosing to go the polyglot route with the core/maximum load part of the system being implemented in the performance intensive way possible and the rest in a language that aids fast iteration and expressiveness.

Using gRPC you could very well implement the most high throughput part of the system in a language like go or c++ . Once their gRPC servers are deployed you could implement their clients in javascript or python, and what you get immediately is a remote system call to a much faster and optimized system which takes care of the heavy lifting.

Conclusion

gRPC opens up new avenues it terms of performance and design constructs. While it is stable and mature enough to be deployed to production environments, however there still some essential features which are still missing. ( Kubernetes does not support health checks for gRPC natively check it out here )

Have experience with using gRPC based microservices in production? Tell me all about it in the comments!!!.

Also check out my article on writing you first gRPC service here

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s