The document presents an overview of gRPC and HTTP/2, highlighting the limitations of REST and the advantages of using gRPC for microservices, including lower latency and better performance. It discusses the architecture, protocol buffers (protobuf), and the benefits of transitioning to these technologies for efficient communication in distributed systems. A demo is included to illustrate the implementation of gRPC services using Golang.

1. Built by Luca Ferrari Version 1.0
The new (is it really?) API
stack
by Luca Ferrari
EMEASolutionArchitect
Red Hat
1

2. Built by Luca Ferrari Version 1.0
What we are going to see today:
➔ Intro to grpc (and HTTP/2)
➔ Intro to protobuf
➔ Layering on Golang
➔ Comparison with REST
2
➔ Demo building a microservice
➔ Protection with API
Management
➔ Resources

3. Overview
Why we are speaking today about gRPC?
3

4. Trend
Microservices
gRPC
4

5. Also...
● One of the protocols supported by Istio Service Mesh
● Reaching some of the limits of REST
● Reaching some of the limits of HTTP/1.1
● What about yourself?
5

6. What is HTTP/2
and why it’s important to know about it
6

7. History
1991
HTTP 0.9
1996
HTTP 1.0
1997
HTTP 1.1
2009
SPDY 1.0
2015
HTTP 2.0
7

8. Principles
new version of HTTP:
1. Simplicity
2. High performance
3. Robustness
Aim:
● reduce latency in processing
browser requests
● while maintaining compatibility
8

9. HTTP/1.1 issues
1
HTTP/1.1 was limited to processing only
one outstanding request per TCP
connection, forcing browsers to use
multiple TCP connections to process
multiple requests simultaneously.
2
However, using too many TCP connections
in parallel leads to TCP congestion that
causes unfair monopolization of network
resources
3
Issuing multiple requests from the browser
also causes data duplication on data
transmission wires, which in turn requires
additional protocols to extract the desired
information free of errors at the end-nodes.
4
Security loopholes (like Cookie Hack)*
9* [ http://http2.github.io/http2-spec/#TLSUsage ]

10. HTTP/2 solutions
1 Multiplexed streams:
Earlier iterations of the HTTP protocol were capable of transmitting only one stream at a time along
with some time delay between each stream transmission.
Receiving tons of media content via individual streams sent one by one is both inefficient and resource
consuming.
This new layer allows client and server to disintegrate the HTTP payload into small, independent and
manageable interleaved sequence of frames.
Benefits:
● The parallel multiplexed requests and response do not block each other.
● A single TCP connection is used despite transmitting multiple data streams.
● Reduced latency, faster web performance, better search engine rankings.
10

11. HTTP/2 solutions
2 Server Push:
This capability allows the server to send additional cacheable information to the client that isn’t
requested but is anticipated in future requests.
For example, if the client requests for the resource X and it is understood that the resource Y is
referenced with the requested file, the server can choose to push Y along with X instead of waiting for
an appropriate client request. This mechanism saves a request-respond round trip and reduces network
latency.
Benefits:
● The client can reuse these cached resources across different pages.
● The server can multiplex pushed resources along with originally requested information within
the same TCP connection.
● The client can decline pushed resources to maintain an effective repository of cached resources
or disable Server Push entirely.
11

12. HTTP/2 solutions
3 Binary protocols:
HTTP1.x used to process text commands to complete request-response cycles. HTTP/2 will use binary
commands (in 1s and 0s) to execute the same tasks.
Although it will probably take more efforts to read binary as compared text commands, it is easier for
the network to generate and parse frames available in binary. The actual semantics remain unchanged.
Benefits:
● Low overhead in parsing data
● Less prone to errors
● Lighter network footprint
● Eliminating security concerns associated with the textual nature of HTTP1.x such as response
splitting attacks*
12* [ https://resources.infosecinstitute.com/http-response-splitting-attack/#gref ]

13. HTTP/2 solutions
4 Stream prioritization:
Stream prioritization works with Dependencies and Weight assigned to each stream. Although all
streams are inherently dependent on each other except, the dependent streams are also assigned
weight between 1 and 256. The details for stream prioritization mechanisms are still debated.
Holding off data stream processing requests on a random basis undermines the efficiencies and end-
user experience promised by HTTP/2 changes.
Benefits:
● Effective network resource utilization.
● Reduced time to deliver primary content requests.
● Improved page load speed and end-user experience.
13

14. HTTP/2 solutions
5 Header Compression:
The HTTP application protocol is stateless, which means each client request must include as much
information as the server needs to perform the desired operation. This mechanism causes the data
streams to carry multiple repetitive frames of information such that the server itself does not have to
store information from previous client requests.
HTTP/2 adds the ability to compress large number of redundant header frames. It uses the HPACK
specification. Both client and server maintain a list of headers used in previous client-server requests.
Benefits:
● Reduced resource overhead
● Encodes large headers as well as commonly used headers which eliminates the need to send the
entire header frame itself.
● Not vulnerable to security attacks such as CRIME
14

15. HTTP/2 solutions
6 Security:
HTTP/2 defines a profile of TLS that is required; this includes the version, a ciphersuite blacklist, and
extensions used (with TLS1.2 set as minimum ciphersuite)
There is also discussion of additional mechanisms, such as using TLS for HTTP:// URLs (so-called
“opportunistic encryption”).
15

16. Quick demo
Two elements:
● Is a website HTTP/2 ready: https://tools.keycdn.com/http2-test [facebook.com]
● Do a speed comparison between HTTP/1.1 and HTTP/2: https://http2.akamai.com/demo
16

17. What is gRPC
and why it’s important to know about it
17

18. REST issues
1
Not built for microservices chattiness
architecture
2
JSON format not optimized for efficiency
or performance
3
Streaming APIs not native to REST
4
API Spec loosely coupled to REST
Client generation issues
18

19. Definition
gRPC, short for “gRPC Remote Procedure Call,” is Google’s lightweight, open source RPC framework
gRPC is a high performance, open-source remote procedure call (RPC) framework that can run anywhere. It enables client and
server applications to communicate transparently, and makes it easier to build connected systems.
gRPC follows HTTP semantics over HTTP/2. It allows you to build services with both synchronous and asynchronous
communication model. It supports traditional Request/Response model and bidirectional streams. Its capability for building
full-duplex streaming lets you use it for advanced scenarios where both client and server applications can send stream of data
asynchronously
19

20. Principles
Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of
microservicesrunning within and acrossourdata centersfor over a decade …
https://grpc.io/blog/principles/
gRPC is a Cloud Native Computing Foundation (CNCF) project.
20

21. Use cases
● Low latency, highly scalable, distributed systems.
● Developing mobile clients which are communicating to a cloud server.
● Designing a new protocol that needs to be accurate, efficient and language independent.
● Layered design to enable extension eg. authentication, load balancing, logging and monitoring etc.
21

22. Data Format
By default, gRPC uses Protocol Buffers as the Interface Definition Language (IDL) and as its underlying message interchange
format.
But it comes with external support for other content types such as FlatBuffers and Thrift, at varying levels of maturity.
22

23. What is protobuf
and why it’s important to know about it
23

24. Definition
Protocol Buffers (Protobuf) is a method of serializing structured data. The method involves an interface descriptionlanguage
that describes the structure of some data and a program that generates source code from that description for generating or
parsing a stream of bytes that represents the structured data.
It is a simple language-neutral and platform-neutral Interface Definition Language (IDL) for defining data structure schemas
and programming interfaces. It supports both binary and text wire formats, and works with many different wire protocols on
different platforms.
The design goals for Protocol Buffers emphasized simplicity and performance. In particular, it was designed to be smaller and
faster than XML.
24

25. How does it work
Unlike JSON and XML, Protocol Buffers are not just message
interchange format, it’s also used for describing the service
interfaces (service endpoints). Thus Protocol Buffers are
used for both the service interface and the structure of the
payload messages.
Like a typical communication between a client application
and a RPC system, a gRPC client application can directly call
methods on a remote server as if it was a local object in your
client application.
25

26. To Go or
not to Go
26

27. Language
Natural choice for gRPC and protobuf is Golang given the
plugins and tools available
There are also plugins in the following languages:
● C++
● Java
● Python
● Ruby
● Node.js
● C#
27

28. 2 minutes setup
go get -u github.com/golang/protobuf/proto
go get -u github.com/golang/protobuf/protoc-gen-go
go get google.golang.org/grpc
28

29. How RESTful is
this?
29

30. gRPC advantage
The main advantage of developing services and clients with gRPC is that your service code or client side code doesn’t need
to worry about parsing JSON or similar text-based message formats (within the code or implicitly inside the underlying
libraries such as Jackson, which is hidden from service code).
What comes in the wire is a binary format, which is unmarshalled into an object. Therefore, as a general practice, we can use
gRPC for all synchronous communications between internal microservices.
Other synchronous messaging technologies such as RESTful services and GraphQL are more suitable for external-facing
services.
30

31. REST comparison
31
Feature gRPC HTTP APIs with JSON
Contract Required (.proto) Optional (OpenAPI)
Protocol HTTP/2 HTTP
Payload Protobuf (small, binary)
JSON (large, human
readable)
Prescriptiveness Strict specification Loose. Any HTTP is valid.
Streaming
Client, server, bi-
directional Client, server
Browser support No (requires grpc-web) Yes
Security Transport (TLS) Transport (TLS)
Client code-
generation Yes
OpenAPI + third-party
tooling

32. Sweet spot
32

33. Did you say SOAP?
You can think about gRPC Web Services as a throwback to the original Web Service technologies, SOAP and WSDL.
Unlike REST, gRPC isn't an architectural style that comes with a lot of design principles or guidelines on how you should
structure your services.
Instead, like WSDL/SOAP services, gRPC is a technical specification that lets you call methods over the Internet without
worrying about what platform the service or the client is running on
33

34. Demo time!
34

35. Building the demo
35
Define service interface in
protobuf01
● Customer service with 2 methods
● Defined in .proto file
● Request / response or stream

36. Building the demo
36
Generate code for client and
server02 ● Use protocol buffer compiler
● Outputs go files
Define service interface in
protobuf01
● Customer service with 2 methods
● Defined in .proto file
● Request / response or stream

37. Building the demo
37
Implement the gRPC server
03 ● Implement the 2 service methods
Generate code for client and
server02 ● Use protocol buffer compiler
● Outputs go files
Define service interface in
protobuf01
● Customer service with 2 methods
● Defined in .proto file
● Request / response or stream

38. Building the demo
38
Implement the gRPC server
03 ● Implement the 2 service methods
Generate code for client and
server02 ● Use protocol buffer compiler
● Outputs go files
Define service interface in
protobuf01
● Customer service with 2 methods
● Defined in .proto file
● Request / response or stream
Use the gRPC client
04 ● Or use a curl tool to test the service (remember to
set the HTTP2 option)

39. Setup
Local setup on my machine
3 folders:
1. Client
2. Server
3. Service definition
Using self-signed certificate and server reflection
39
go run main.go
grpcui -plaintext localhost:50051
grpcui -cacert "cert/ca.cert" localhost:50051

40. 40

41. API Management
you said?
41

42. API Gateway
Most recent API Management solutions can understand:
● HTTP/2
● gRPC
https://github.com/3scale/APIcast/pull/1128
42

43. Closing
43

44. Performance
comparison
Test performed on the same service implemented using either
grpc/protobuf or REST/JSON
Both services are using Golang
Latency CPUandmemory Bandwidth
44
Unexpectedly very similar
results in terms of both CPU
and memory usage

45. Conclusion
Whento use gRPC:
● Well suited for IoT and Mobile cases, given bandwidth efficiency
● Well suited for intra microservice communication
● Standard way to document interface and messages
● Standard way to produce client and server code from service definition (language agnostic)
● Don’t want to deal with serialization / deserialization
45

46. Conclusion
Whennot to use gRPC:
● You don’t want your client and server to be tightly coupled
● You are using REST not in a RESTful way and hope gRPC will solve all your problems
● You love the buzzword
46

47. Resources
https://kinsta.com/learn/what-is-http2/#
https://medium.com/@shijuvar/building-high-performance-
apis-in-go-using-grpc-and-protocol-buffers-2eda5b80771b
https://medium.com/google-cloud/exploring-grpc-on-
google-cloud-platform-82531b4b82b7
47

48. Thank you!
48