gRPC: hoe computers razendsnel met elkaar praten
Stel je een groot postbedrijf voor met honderden sorteercentra verspreid over het land. Elk centrum moet voortdurend pakketjes doorgeven aan andere centra, en dat moet snel, betrouwbaar en volgens strikte afspraken gebeuren: welk formaat heeft het etiket, welke route wordt gevolgd, wat gebeurt er als een centrum tijdelijk niet reageert? Iets vergelijkbaars speelt zich af binnen moderne software. Grote applicaties, zoals die van Netflix of Google, bestaan niet uit één groot programma maar uit tientallen of honderden kleine onderdelen (microservices) die continu gegevens en opdrachten naar elkaar sturen. gRPC is het stelsel van afspraken en technologie dat die onderlinge communicatie regelt.
De naam staat voor "gRPC Remote Procedure Calls", een letterwoord dat zichzelf bevat (de g verwijst inmiddels naar verschillende dingen, afhankelijk van de release, zoals "gRPC" zelf of een projectnaam bij Google). Het werd in 2015 door Google als open source gepubliceerd, gebaseerd op een intern systeem genaamd Stubby dat het bedrijf al jaren gebruikte om zijn eigen diensten te laten communiceren. Een "remote procedure call" betekent in essentie: een programma op computer A vraagt aan een programma op computer B om een bepaalde functie uit te voeren, alsof het een lokale functie-aanroep is, terwijl de daadwerkelijke uitvoering ergens anders op het netwerk plaatsvindt.
Wat is het precies?
gRPC bestaat uit een paar bouwstenen die samen de communicatie efficiënt maken. Het startpunt is een bestand waarin ontwikkelaars vastleggen welke functies ("services") beschikbaar zijn en welke gegevens daarbij horen. Dit gebeurt in een taal genaamd Protocol Buffers, kortweg protobuf, eveneens door Google ontwikkeld. In zo'n .proto-bestand staat bijvoorbeeld: "er is een functie HaalWeerOp die een stadsnaam ontvangt en een temperatuur teruggeeft".
Vervolgens genereert een compiler automatisch programmacode in de programmeertaal van keuze: Java, Python, Go, C++, en nog een stuk of tien andere talen worden officieel ondersteund. Dit is cruciaal, want het betekent dat de ene dienst in Python geschreven kan zijn en de andere in Java, zonder dat ontwikkelaars zich zorgen hoeven te maken over hoe die twee met elkaar praten. De gegenereerde code regelt dat.
Voor het daadwerkelijke transport over het netwerk gebruikt gRPC het protocol HTTP/2, de opvolger van het bekende HTTP/1.1 waarop het grootste deel van het web draait. HTTP/2 kan meerdere verzoeken tegelijk over één verbinding sturen (multiplexing) en comprimeert headers, wat sneller en zuiniger is dan oudere technieken. Hierdoor ondersteunt gRPC ook "streaming": niet alleen een eenmalige vraag-en-antwoord-uitwisseling, maar ook doorlopende stromen van gegevens in één of beide richtingen, bijvoorbeeld handig bij live-updates of grote bestanden die in stukjes worden verstuurd.
Een laatste onderdeel is dat de gegevens zelf in een compact binair formaat worden verstuurd in plaats van leesbare tekst zoals JSON. Dat scheelt bandbreedte en verwerkingstijd, maar heeft als nadeel dat je een bericht niet zomaar met het blote oog kunt lezen zoals bij een REST-API met JSON.
Wat wil men ermee bereiken?
De kern van de ambitie is snelheid en betrouwbaarheid bij schaal. Grote techbedrijven splitsen hun software op in honderden kleine diensten, en elke seconde vinden er miljoenen aanroepen tussen die diensten plaats. Elke milliseconde vertraging of elke byte aan overbodige data telt dan mee in kosten en gebruikerservaring. gRPC is ontworpen om die interne communicatie zo licht en voorspelbaar mogelijk te maken.
Daarnaast speelt type-veiligheid een grote rol. Doordat het contract tussen diensten vooraf strikt is vastgelegd in het .proto-bestand, ontstaan er minder fouten door miscommunicatie, zoals een veld dat de ene dienst als tekst verstuurt en de andere als getal verwacht. Wijzigingen aan een interface worden hierdoor ook makkelijker te beheren in grote organisaties met veel teams.
Een derde doelstelling is het standaardiseren van terugkerende netwerkproblemen: time-outs, het annuleren van een lopende aanvraag, het verdelen van verkeer over meerdere serverinstanties (load balancing) en beveiliging via TLS-versleuteling zijn standaard ingebouwd, zodat niet elk team dit opnieuw hoeft uit te vinden.
Voorbeelden uit de praktijk
Google zelf gebruikt de voorloper Stubby en later gRPC al sinds de jaren 2000 voor praktisch al het interne verkeer tussen zijn datacenters, goed voor miljarden aanroepen per dag.
etcd en Kubernetes: de gedistribueerde database etcd, die de status van Kubernetes-clusters bijhoudt, stapte in 2016 met versie 3 over op een gRPC-gebaseerde API. Omdat Kubernetes wereldwijd de standaard is geworden voor het beheren van containers, draait er sindsdien voortdurend gRPC-verkeer onder de motorkap van talloze clouddiensten.
Netflix beschreef rond 2017-2018 in technische blogposts hoe het gRPC inzette voor een deel van de communicatie tussen zijn interne diensten, als aanvulling op bestaande protocollen, vanwege de prestatievoordelen bij streaming-achtige verkeerspatronen.
Dropbox bouwde een eigen intern raamwerk genaamd Courier bovenop gRPC, gepresenteerd in 2018, om de duizenden onderlinge serviceaanroepen binnen het bedrijf te standaardiseren en te vervangen wat voorheen een lappendeken aan oudere oplossingen was.
Square (nu onderdeel van Block) behoorde tot de eerste externe partijen die al vóór de publieke lancering in 2015 met Google samenwerkten en een vergelijkbaar eigen systeem integreerden, wat mede heeft bijgedragen aan het uiteindelijke ontwerp van gRPC.
Hoe ver is de techniek?
gRPC is inmiddels volwassen technologie, geen experimenteel project meer. Het werd in 2017 opgenomen als "incubating project" bij de Cloud Native Computing Foundation (CNCF), de stichting die ook Kubernetes beheert, en bereikte in 2019 de hoogste status, "graduated", wat aangeeft dat het project breed gebruikt wordt, goed onderhouden is en een stabiel bestuur kent.
De belangrijkste beperking zit niet in de kerntechnologie maar in de randvoorwaarden. Webbrowsers geven ontwikkelaars geen directe controle over de onderliggende HTTP/2-verbindingen, waardoor gRPC niet rechtstreeks vanuit een browser kan worden aangeroepen. Hiervoor bestaat een aparte variant, grpc-web, die via een tussenlaag (proxy) werkt, maar dit voegt complexiteit toe. Daarnaast maakt het binaire berichtformaat het lastiger om snel met simpele tools als curl te testen; gespecialiseerde hulpmiddelen zoals grpcurl of plug-ins voor Postman zijn ondertussen beschikbaar om dat te verzachten.
In de praktijk zie je gRPC vooral "achter de schermen", in de interne machinekamer van bedrijven, terwijl naar buiten toe gerichte publieke API's vaak nog gewoon op REST met JSON draaien, omdat dat beter aansluit bij de brede ontwikkelaarsgemeenschap en browsercompatibiliteit. Die verdeling lijkt de komende jaren niet snel te veranderen.
Wie werken eraan?
Google blijft de grootste drijvende kracht achter gRPC en levert het leeuwendeel van de kerncode en documentatie. Sinds 2017 valt het project onder de paraplu van de CNCF, onderdeel van de Linux Foundation, die ook zorgt voor neutraal bestuur zodat niet één bedrijf alleen beslist over de toekomst van het project.
Daarnaast dragen bedrijven als Square/Block, Microsoft, IBM, Cisco, Netflix, Lyft en Datadog actief bij aan de broncode en aan uitbreidingen, bijvoorbeeld voor specifieke programmeertalen of integraties. De ontwikkeling vindt grotendeels in het openbaar plaats via de repository grpc/grpc op GitHub, waar ook onafhankelijke ontwikkelaars en kleinere bedrijven issues melden en code bijdragen.
Ook aanpalende cloud-native projecten zoals de netwerkproxy Envoy, eveneens een CNCF-project, ondersteunen gRPC standaard, wat de positie van de technologie binnen het bredere ecosysteem van moderne, in containers draaiende software verder verstevigt.