Derfor valgte Spotify Googles protokol til mikrotjenester

Illustration: Bigstock/Wrightstudio
Det var et pragmatisk valg, da den svenske streaming-tjeneste droppede egen protokol til fordel for GRPC. Og hvis man bruger REST og HTTP, er der næppe grund til at skifte, mener chefudvikler hos Spotify.

Mikrotjenester, eller finkornet tjenestearkitektur (SOA), er én af de mest populære arkitekturer for server-programmer i dag.

Det er en måde at skære monolitiske applikationer op i bidder, som er nemmere at håndtere, og som udviklere kan arbejde på i separate hold.

Læs også: Efter ti år med mikrotjenester gør chefudvikler status: Småt er godt, men ...

Men tjenesterne skal kunne snakke sammen. Det er ikke nogen nyhed, og selv i gamle dage havde man standarder til den slags, med forkortelser som CORBA, IDL, DCOM og RMI.

Leverandørerne kunne ikke finde på et fælles bud i første omgang, men det kom med SOAP-standarden, der bygger på HTTP og XML.

Senere kom de såkaldte WS-stjerne-protokoller (WS-*) med i SOAP-hatten, men det blev REST, der løb af med sejren, i hvert fald i udviklernes hjerter.

Matthias Grüter er engineering manager i Spotify. Her blev Google-protokollen GRPC valgt, da der skulle skiftes protokol til kommunikation imellem server-tjenesterne. Illustration: Spotify

Denne fremgangsmåde tilbyder en væsentlig mindre tung grænseflade, end de tidskrævende og værktøjsbaserede alternativer i SOAP og WS-*.

Tillige benyttes REST ofte i kombination med det programmeringsnære format JSON, i stedet for XML, der kræver flere kræfter til læsning af meddelelser.

Nye protokoller på vej

Men en række nye protokoller stikker hovedet frem. Det gælder eksempelvis kø-protokollen AMQP (Advanced Message Queuing Protocol) og andre protokoller fra kø-systemer, såsom Kafka, samt nytilkomne bud som Rsocket.

Læs også: Tjep køkultur med Apache Kafka

Det er blandt andet et bedre forhold mellem data (payload) og overhead, i form af headere og andre metadata, som gør disse alternativer attraktive i forhold til den HTTP- og tekst-baserede REST-model.

Endeligt har protokollen GRPC fået mange fans i de seneste år. Den bygger på Googles binære Protocol Buffers til meddelelser, i stedet for XML eller JSON.

Og det er den, som den svenske streamingtjeneste Spotify har valgt, som afløser for sin egen hjemmestrikkede protokol.

Det fortæller stockholmeren Matthias Grüter, som er engineering manager i Spotifys Core infrastructure group, der skaber værktøjer og infrastruktur til backend, og servicerer firmaets udviklere, da Version2 møder ham på Øredev-konferencen i Malmø tidligere på måneden.

Spotify har hidtil anvendt deres egen hjemmestrikkede protokol, med navnet Hermes.

»Vi vil rigtig gerne væk fra hjemmelavede løsninger og i stedet benytte noget åbent. Vi kiggede efter alternativer og fandt GRPC,« forklarer Matthias Grüter, og uddyber:

»Hvis vi kun havde benyttet HTTP og REST havde casen for at skifte været mindre, og måske ikke stor nok til at ændre systemet.«

Best practices er indbygget fra starten

Hvis ens afdeling er ved at starte nye projekter, er den største fordel ved GRPC, at der er tale om et framework med mange indbyggede faciliteter, i modsætning til HTTP og REST, hvor man selv skal koble værktøjer og framework sammen, lyder synspunktet.

Men der findes også mange værktøjer til REST?

»Ja, men udviklerhold kan bruge lang tid på at finde ud af, hvilket sprog og teknologi, man skal benytte. GRPC har ‘best practices’ indbygget fra starten af. Eksempelvis er der kryptering som udgangspunkt. Protokollen bygger på HTTP/2, så der findes et større økosystem omkring den.«

HTTP som basis betyder eksempelvis, at proxy’er understøttes lige ud af posen, uden yderligere krumspring.

Stærkere typer end REST

En anden og stor fordel ved GRPC, er kodegenerering og stærke typer i dets Interface Definition Language (IDL), der specificerer grænsefladerne mellem tjenester.

»Det kan man også få med HTTP og REST, hvis man bruger Swagger og OpenAPI specs, men det er ikke så typestærkt som med GRPC. Den genererede kode er nemmere at håndtere, fordi du genererer kode og dokumentation fra én fil.«

Det er udvikler-produktivitet, der er vigtigt for Spotify i forhold til GRPC, og ikke payload-effektivitet?

»Udvikler-hastigheden er én ting. Det er i hvert fald ikke ydelse, for Hermes yder rigtig godt. I GRPC er det også robusthed, load balancing, routing, som er indbygget og er ‘opinionated’ på en måde, som vi er enige i.«

Spotifys platform er i overvejende grad JVM – dvs. Java samt de andre sprog, der understøttes af den virtuelle maskine.

I JVM-verdenen findes også den tidligere nævnte protokol Rsocket, som fortalerne mener er en mere strømlinet en af slagsen. Kritikken går blandt andet på, at GRPC består af et miskmask af HTTP/2, specifikke headers og specielt udformede URL'er, hvilket er bøvlet, ifølge synspunktet. GRPC understøttes heller ikke af browsere.

Læs også: Udvikler: Drop REST og HTTP til fordel for binær protokol

Matthias Grüter er ikke nødvendigvis uenig, og han synes, at Rsocket er et meget interessant projekt.

»Da vi startede med at kigge på GRPC var Rsocket ikke der, hvor det er nu. Og jeg mener også at det er en protokol på et lavere niveau i abstraktion. Spotifys udviklere behøver ikke med at have at gøre med selve ‘rørlægningen', hvor Rsocket altså fungerer på et lavere niveau. Men Rsocket er meget interessant, og det er noget, vi vil kigge nærmere på.«

Passer godt med Google

En anden fordel med GRPC er ifølge Matthias Grüter, at det er bredt anvendt i branchen.

»Vi er i Google Cloud, og bruger en masse løsninger derfra, såsom Bigtable og andre tjenester, der har api’er, som bygger på GRPC. Så det passer godt sammen. Det gav god mening for os, og det er en teknologi, der ikke forsvinder lige med det første.«

Spotify bruger mange Google-tjenester, og lige nu er Kubernetes én af firmaets største platforme.

»Vi har flyttet det hele fra vores egne container-platform, Helios, som også er open source. Nu bruger vi Googles tjeneste til Kubernetes. Hele vores backend er i Googles sky. Vi behøver ikke at bygge det hele selv, men kan fokusere på, hvor værdien skabes.«

Hvis en virksomhed har et HTTP/REST-system i forvejen til mikrotjenester, er der så grund til at skifte til GRPC?

»Hvis du er tilfreds med det, du har, så lad være med at skifte. Hvis du har et behov, hvis der mangler noget, og du ikke ved, hvordan du skal fikse det, eller problemer med at skalere, så kan GRPC være brugbart. Eller hvis du bygger noget helt nyt. Forandring blot for at få ny teknologi er ikke en god ide. For så vil du rykke videre til Rsocket om et par år, og videre derfra til ‘the next big thing.’ Det bliver en uendelig migrering, der aldrig slutter.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Cederberg

Hvis valget af kommunikationsprotocol eller serialization format har stor betydning for udviklerproduktiviteten, så er det en indikation af at ens micro-services er blevet for "micro". For hvis udviklere bruger meget tid på "plumbing" så bruger de mindre tid på funktionalitet der hjælper brugeren. I sidste ende laver vi IT for at hjælpe brugerne. Ikke for at glæde "arkitektur- eller teknik-guderne".

Men i øvrigt synes jeg GRPC er et strålende valg.

  • 3
  • 1
Christian Nobel

det programmeringsnære format JSON, i stedet for XML, der kræver flere kræfter til læsning af meddelelser.

Det kan så diskuteres.

For XML har en meget stringent struktur, og dermed mindre behov for "forudsigelse" end JSON har.

Husk lige at JS i JSON står for Javascript, med hvad deraf følger af kummerlig typing mv.

Det sidste jeg i hvertfald har behov for i et API er at skulle bruge tid på at gætte eller lave antagelser.

  • 2
  • 4
Log ind eller Opret konto for at kommentere