Hooked on HTTP/2 - Speaker Deck

Slide 1

Slide 1 text

Microservices development with gRPC Hooked on HTTP/2

Slide 2

Slide 2 text

@grpcio @tekgrrl Mandy Waite Developer Advocate +MandyWaite @tekgrrl

Slide 3

Slide 3 text

@grpcio @tekgrrl Hooked on HTTP/2 Protocol Buffers gRPC Clients & Microservices 1 2 3 4 Agenda

Slide 4

Slide 4 text

HTTP/2

Slide 5

Slide 5 text

@grpcio @tekgrrl So what’s up with HTTP/1? Today statistics show that there are on average: ● 12 distinct hosts per page ● 78 distinct requests per page ● 1,232 KB transferred per page Resulting in typical render times of 2.6-5.6 seconds (50th and 90th percentiles).

Slide 6

Slide 6 text

@grpcio @tekgrrl HTTP Pipelining ● Queue responses not requests Domain Sharding ● Need more than 6 connections per origin? Add more origins! Concatenation and Spriting ● Multiple JavaScript/CSS/Image files combined into a single resource Resource Inlining ● Inline JS/CSS/Images in the page Coping Strategies img1.example.com img2.example.com img3.example.com ...

Slide 7

Slide 7 text

@grpcio @tekgrrl HTTP Pipelining ● Head of Line blocking Domain Sharding ● Over sharding can kill performance Concatenation and Spriting ● Increased complexity, can hurt cache performance and page load Resource Inlining ● Can hurt cache performance, hard to get granularity right Copying Strategies - The downsides img1.example.com img2.example.com img3.example.com ...

Slide 8

Slide 8 text

● Improve end-user perceived latency ● Address the "head of line blocking" ● Not require multiple connections ● Retain the semantics of HTTP/1.1 "HTTP/2 is a protocol designed for low- latency transport of content over the World Wide Web"

Slide 9

Slide 9 text

@grpcio @tekgrrl ● One TCP connection ● Request → Stream ○ Streams are multiplexed ○ Streams are prioritized ● Binary framing layer ○ Prioritization ○ Flow control ○ Server push ● Header compression HTTP/2 in one slide…

Slide 10

Slide 10 text

“... we’re not replacing all of HTTP — the methods, status codes, and most of the headers you use today will be the same. Instead, we’re redefining how it gets used “on the wire” so it’s more efficient, and so that it is more gentle to the Internet itself ....” - Mark Nottingham (HTTPbis chair)

Slide 11

Slide 11 text

@grpcio @tekgrrl HTTP/2 binary framing 101 ● Sits between Socket interface and the API ● HTTP messages are decomposed into one or more frames ○ HEADERS for meta-data ○ DATA for payload ○ RST_STREAM to cancel ○ … ● Each frame has a common header ○ 9-byte, length prefixed ○ Easy and efficient to parse

Slide 12

Slide 12 text

@grpcio @tekgrrl Basic data flow in HTTP 2.0...

Slide 13

Slide 13 text

@grpcio @tekgrrl Basic data flow in HTTP 2.0... Streams are multiplexed, because frames can be interleaved All frames (e.g. HEADERS, DATA, etc) are sent over single TCP connection Frame delivery is prioritized based on stream dependencies and weights DATA frames are subject to per-stream and connection flow control

Slide 14

Slide 14 text

@grpcio @tekgrrl ● Each stream can have a weight ○ [1-256] integer value ● Each stream can have a dependency ○ parent is another stream ID Stream prioritization in HTTP/2... 1. E.g.. style.css (“A”) should get 2/3rd’s of available resources as compared to logo.jpg (“B”) 2. E.g.. product-photo-1.jpg (“D”) should be delivered before product-photo-2.jpg (“C”)

Slide 15

Slide 15 text

@grpcio @tekgrrl Examples NOTE: Prioritization is an advisory optimization hint to the server

Slide 16

Slide 16 text

@grpcio @tekgrrl HTTP/2 server: “You asked for /product/123, I know you’ll also need app.js and product-photo-1.jpg, so… I promise to deliver these to you, no need to ask for them. That is, unless you decline or cancel.” GET /product/123 /product/123 /app.js /product-photo-1.jpg ● Server push is optional and can be disabled by the client ● Server push is subject to flow control - e.g. “you can only push 5Kb” ● Pushed resources can be cached and prioritized individually Server push, “because you’ll also need…”

Slide 17

Slide 17 text

@grpcio @tekgrrl HTTP/2 client: “I want photo.jpg, please send the first 20KB.” HTTP/2 server: “Ok, 20KB… pausing stream until you tell me to send more.” HTTP/2 client: “Send me the rest now.” GET /product-photo.jpg /product-photo.jpg /product-photo.jpg WINDOW_UPDATE ● Flow control allows the client to pause stream delivery, and resume it later ● Flow control is a “credit-based” scheme ○ Sending DATA frames decrements the window ○ WINDOW_UPDATE frames update the window Per-stream flow control

Slide 18

Slide 18 text

@grpcio @tekgrrl HPACK header compression ● Literal values are (optionally) encoded with a static Huffman code ● Previously sent values are (optionally) indexed ○ e.g. “2” in above example expands to “method: GET”

Slide 19

Slide 19 text

Protocol Buffers

Slide 20

Slide 20 text

@grpcio @tekgrrl What are Protocol Buffers? Structured representation of data Google's lingua franca for data ● 48k+ Message Types ● 12k+ Proto files Evolutionary Development Incrementally solved problems, Now used for: ● RPC Systems ● Persistent Data Storage

Slide 21

Slide 21 text

@grpcio @tekgrrl Protocol buffers: ● Efficient and compact binary data representation ● Clear compatibility rules; can easily be extended over time ● Generates idiomatic, easy to use classes for many languages ● Strongly typed; less error prone Why Protocol Buffers?

Slide 22

Slide 22 text

@grpcio @tekgrrl Protocol Buffers also are: ● No use as a markup language ● Not human readable (native format) ● Only meaningful if you have the message definition Why not?

Slide 23

Slide 23 text

@grpcio @tekgrrl Uniquely numbered fields Typed Hierarchical Structure Optional and Repeated fields Extensible without breaking backward compatibility Message Format (proto2) message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; }

Slide 24

Slide 24 text

@grpcio @tekgrrl Protocol Buffers language version 3 Specified by syntax = “proto3”; proto2 continues to be supported All fields are optional in proto3 No user specified default values No groups (FYI for those that use them) Message Format (proto3) syntax = “proto3”; message Person { string name = 1; int32 id = 2; string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { string number = 1; PhoneType type = 2; } repeated PhoneNumber phone = 4; }

Slide 25

Slide 25 text

@grpcio @tekgrrl Add new fields without breaking backwards-compatibility old implementations ignore the new fields when parsing In proto3 any field can be removed, but don’t renumber existing fields Extensible syntax = “proto3”; message Person { string name = 1; int32 id = 2; string email = 3; address addr = 4; message address { string firstLine = 1; string secondLine = 2; string postalCode = 3; string country = 4; } ... }

Slide 26

Slide 26 text

@grpcio @tekgrrl https://github.com/google/protobuf Protocol Buffer Compiler

Slide 27

Slide 27 text

gRPC

Slide 28

Slide 28 text

gRPC goals Enable developers to build microservice-based applications Build an open source, standards-based, best-of-breed, feature-rich RPC system Create easy-to-use, efficient and idiomatic libraries micro-services performant and scalable efficient and idiomatic Provide a performant and scalable RPC framework

Slide 29

Slide 29 text

@grpcio @tekgrrl IDL to describe the API Automatically generated servers and clients in 10+ languages Takes advantage of feature set of HTTP/2 Lightweight open connections Point to point Streaming! Bidirectional streaming! gRPC in a nutshell

Slide 30

Slide 30 text

@grpcio @tekgrrl gRPC client/server architecture

Slide 31

Slide 31 text

@grpcio @tekgrrl Getting Started Define a service in a .proto file using Protocol Buffers IDL Generate server and client code using the protocol buffer compiler Use the gRPC API to write a simple client and server for your service in the languages of your choice

Slide 32

Slide 32 text

@grpcio @tekgrrl service RouteGuide { rpc GetFeature(Point) returns (Feature); } message Point { int32 latitude = 1; int32 longitude = 2; } message Feature { string name = 1; Point location = 2; } Service Definition

Slide 33

Slide 33 text

@grpcio @tekgrrl RPC Messages The most common use-case is a unary request-response RPC Msg1 MsgA Client Server

Slide 34

Slide 34 text

Slide 35

Slide 35 text

@grpcio @tekgrrl RPCs and Metadata Metadata mechanism for extensibility Msg1 MsgA Metadata Client Server Metadata

Slide 36

Slide 36 text

@grpcio @tekgrrl Ordered Bidirectional Streaming RPC Msg1 Msg2 Msg3 MsgA MsgB Metadata Metadata Metadata Client Server The second most common use-case is sending multiple request or response messages in the context of a single RPC call

Slide 37

Slide 37 text

@grpcio @tekgrrl service RouteGuide { rpc ListFeatures (Rectangle) returns (stream Features); ... } message Rectangle { Point lo = 1; Point hi = 2; } Server Streaming RPC Definition

Slide 38

Slide 38 text

@grpcio @tekgrrl service RouteGuide { rpc RecordRoute (stream Point) returns (RouteSummary); ... } message RouteSummary { int32 point_count = 1; int32 feature_count = 2; int32 distance = 3; int32 elapsed_time = 4; } Client Streaming RPC Definition

Slide 39

Slide 39 text

@grpcio @tekgrrl service RouteGuide { rpc RouteChat (stream RouteNote) returns (stream RouteNote); ... } message RouteNote { string location = 1; string message = 2; } Bidirectional Streaming RPC Definition

Slide 40

Slide 40 text

@grpcio @tekgrrl gRPC Language Support Implementations ● C core ○ Native bindings in C++, Node.js, Python, Ruby, ObjC, PHP, C# ● Java using Netty or OkHttp (+ inProcess for testing) ● Go

Slide 41

Slide 41 text

@grpcio @tekgrrl channel = NettyChannelBuilder.forAddress(host, port) .negotiationType(NegotiationType.PLAINTEXT) .build(); Channel Setup (Java Client)

Slide 42

Slide 42 text

Slide 43

Slide 43 text

@grpcio @tekgrrl channel = NettyChannelBuilder.forAddress(host, port) .negotiationType(NegotiationType.PLAINTEXT) .build(); blockingStub = RouteGuideGrpc.newBlockingStub(channel); asyncStub = RouteGuideGrpc.newStub(channel); Point request = Point.newBuilder().setLatitude(lat).setLongitude(lon).build(); Feature feature = blockingStub.getFeature(request); Unary Call (Java Client)

Slide 44

Slide 44 text

@grpcio @tekgrrl @Override public void getFeature(Point request, StreamObserver responseObserver) { responseObserver.onValue(checkFeature(request)); responseObserver.onCompleted(); } private Feature checkFeature(Point location) { for (Feature feature : features) { if (feature.getLocation().getLatitude() == location.getLatitude() && feature.getLocation().getLongitude() == location.getLongitude()) { return feature; } } // No feature was found, return an unnamed feature. return Feature.newBuilder().setName("").setLocation(location).build(); } Unary Call (Java Server)

Slide 45

Slide 45 text

@grpcio @tekgrrl Authentication SSL/TLS gRPC has SSL/TLS integration and promotes the use of SSL/TLS to authenticate the server, and encrypt all the data exchanged between the client and the server. Optional mechanisms are available for clients to provide certificates to accomplish mutual authentication. OAuth 2.0 gRPC provides a generic mechanism to attach metadata to requests and responses. Can be used to attach OAuth 2.0 Access Tokens to RPCs being made at a client.

Slide 46

Slide 46 text

Microservices

Slide 47

Slide 47 text

@grpcio @tekgrrl Decomposing Monolithic apps A B C D

Slide 48

Slide 48 text

@grpcio @tekgrrl Decomposing Monolithic apps A B C D

Slide 49

Slide 49 text

@grpcio @tekgrrl Decomposing Monolithic apps A B C D gRPC

Slide 50

Slide 50 text

@grpcio @tekgrrl Freedom to pick the language independently for each micro-service, based on performance, library availability, team expertise etc MicroServices using gRPC Loosely coupled development Blocks of functionality can be broken off into separate MicroService. Allows organic growth Multi-language High Performance Make use of the strengths of HTTP/2 and Protocol Buffers

Slide 51

Slide 51 text

@grpcio @tekgrrl Polyglot Microservices Architecture C++ Service gRPC server Golang Service gRPC server gRPC Stub Java Service gRPC Stub Python Service gRPC server gRPC Stub

Slide 52

Slide 52 text

Mobile

Slide 53

Slide 53 text

@grpcio @tekgrrl Abelana Mobile Sample App Photo-sharing App Mobile Clients communicate with gRPC endpoint Clients for iOS and Android https://cloud.google.com/solutions/mobile/image-management-mobile-apps-grpc

Slide 54

Slide 54 text

@grpcio @tekgrrl Abelana Architecture @grpcio @tekgrrl

Slide 55

Slide 55 text

Wrap-up

Slide 56

Slide 56 text

@grpcio @tekgrrl grpc is Open Source We want your help! http://grpc.io/contribute https://github.com/grpc irc.freenode.net #grpc @grpcio [email protected]

Slide 57

Slide 57 text

Hooked on HTTP/2