Page 50 - MSDN Magazine, October 2019

Cutting EdgE DINO ESPOSITO Using gRPC in a Microservice Architecture
The microservice architecture style has been taking the software industry by storm in the recent past and with some good argu- ments. It objectively delivers key benefits that make the resulting systemresilienttofailureandscalableatthedesiredlevelofgranu- larity. In an enterprise scenario, a microservice architecture enables the use of heterogeneous technologies and different architectural patterns. It also dramatically simplifies deployment and allows the engineering department to more easily shape up a bespoke project that reflects the internal organization.
All that said, what’s the concrete result of designing and deploy- ing a microservice-based architecture? The commonly accepted answer to this question is the trigger for this month’s article, and the logical background for introducing the gRPC framework in a microservice architecture.
Breaking Up the Monolith
Although no official definition of microservices probably exists, nearly everybody agrees on a definition that goes along the lines of organizing the entire logic of a single software application in a collection of smaller services. Each constituent service ends up being considerably smaller in size and complexity than the single application in its entirety. These (micro) services are treated as independent units of the application and are implemented and deployed autonomously. Also important, is each microservice be fully responsible for its own data.
In a nutshell, the microservice architecture breaks up a single software monolith into a myriad of independent and distributed components. Note that in this context the term myriad is a bit of a hyperbole, with the number of microservices usually measured on the order of tens. A smart (if relative and non-quantitative) definition of the ideal microservice size is that it should never be larger than a problem’s subdomain and never smaller than a cluster of related domain objects.
In a microservice application, the individual components form a distributed architecture in which each component runs its own process and communicates with others over possibly lightweight protocols. There are many ways in which two distinct microservices can communicate over the network. Most of the time, they do it using REST interfaces and JSON for data serialization. The whole Web services world was devised to use SOAP as the underlying pro- tocol for communication and XML as the data serialization format. SOAP wasn’t necessarily ideal, but it was the best the industry could work out 20 years ago. Later came REST and RESTful interfaces,
which offered important advantages over SOAP with its well-defined and standardized messaging patterns (like the WS-XXX family).
REST arrived as an antidote to the perceived complexity of SOAP,performingdirectaccesstothedataanddefinedinthe form of resources. Access to resources occurs using the verbs (and the rules) of the underlying HTTP protocol. In other words, a RESTful interface has no need to define interfaces and constraints, other than those set by the underlying HTTP protocol itself. In this picture, JSON is only a serialization format, less verbose and more flexible than XML. Today REST and JSON together represent the lion’s share of microservices communications, but there are other, and possibly better, communication technologies to consider. The most enticing is the gRPC framework.
Bringing gRPC to the Table of Microservices
At first, using the gRPC framework to connect distributed compo- nents may look like a step backward. After celebrating the advent of REST as the triumph of flexibility and decoupling, the industry is now carefully considering an approach centered on the concept of remote procedure calls (RPC). By design, an RPC requires some level of coupling between the caller and receiver.
In addition, the gRPC framework pushes well-defined messages, versioning and contracted endpoints. The framework runs over the newer HTTP/2 protocol and exchanges data in a binary format. Under the hood, a number of other, subtler differences exist that make gRPC worth a closer look. But is gRPC a better REST, or is it just particularly suited to a microservices scenario?
The point is that REST in itself is only the formalization of an ideal uniform interface to connect components. Inspired in 2000 by the way the Web was developing, REST never really achieved the goal of enabling any RESTful client to talk to any RESTful server regard- less of knowing much of the details. How many RESTful Web APIs return 200 OK to report an error? And how many use the same POST verb to add, delete and update resources? REST definitely works, but beyond hype and fanfare it’s nothing more than a plain API exposed over HTTP that just requires an HTTP call to return a response. Each developer calling any endpoint of any declared REST API needs to know all of its details and, often, he is free to place calls in a different way than is documented and still get a valid response. As brutal as it may sound, there’s no (concretely applied) standard around REST.
As implemented in most real-world applications today, REST is basically a simplified, unstructured and improvable form of RPC in which HTTP elements (headers, query string, payloads, status
46 msdn magazine