App-udviklere skifter 'PHP-monolit' ud med Erlang og GraphQL

Erlang er bygget til at klare, at noget går galt, og det gør det velegnet til microservices, forklarer teknisk direktør Morten Bo Rønsholdt fra Shopgun. Illustration: Tine Sletting
Erlang er bygget til at lade funktionerne crashe, og det gør det nemt at lave microservices.

Når man står med en platform, der alligevel skal udbygges for at understøtte nye forretningsmuligheder, så er det oplagt at se på, om man kunne bygge den helt anderledes, end det man havde i forvejen. Men for den danske app-virksomhed Shopgun er resultatet blevet et skift til en lidt usædvanlig kombination.

Firmaet har nemlig kombineret det gamle telekommunikationsprogrammeringsprog Erlang med Facebooks nye GraphQL - og det har vist sig at give god mening.

»Hvis der er et eller andet, der går galt for eksempel på virtuelle maskiner eller netværket, så er Erlang ret fantastisk til at håndtere de her fejl, fordi det er lavet til, at ting bare skal crashe og så genstarte en proces,« fortæller teknisk direktør og medstifter af Shopgun Morten Bo Rønsholdt til Version2.

Erlang har rødder tilbage til udviklingen af digitale telefonnetværk hos Ericsson, hvor det var vigtigt, at en switch kunne håndtere fejl. Derfor er Erlang-applikationer bygget som eventdrevne processer, der enten udfører det, de får besked på, eller fejler på en måde, så det samlede system kan reagere og eksempelvis starte en ny proces op.

Ingen PHP-monolit

Opbygningen i Erlang-applikationer minder derfor også om micro services, der lige nu er et varmt emne inden for softwareudvikling, og det giver også nogle af de samme fordele.

»Vi kunne have bygget en monolit i PHP, men med Erlang kan vi lave meget små services. Og det er nemt at skrive services, som man kan komme tilbage til et halvt år efter og stadig gennemskue,« forklarer Morten Bo Rønsholdt.

Eventdrevne mikroservices kunne også laves med eksempelvis Node.js, men ifølge Morten Bo Rønsholdt var det ikke noget, de havde lyst til.

»Node.js kan egentligt det samme, men man skal holde tungen lige i munden, hvis man skal undgå, at det bliver uoverskueligt,« siger Morten Bo Rønsholdt.

Vejen til Erlang var dog ikke nødvendigvis en nøje afsøgning af mulige teknologier for Shopgun, men skete mere ved et tilfælde.

»Vi satte os ikke ned for to år siden og sagde, at sådan her skal det være. Det var meget organisk. Det startede faktisk med at Alexander, en af vores første ansatte, skulle lave et system internt til at tælle statistik. Vi har ikke nogen politik om, at du skal skrive i et bestemt sprog, så han valgte simpelthen at skrive det i Erlang, fordi han havde en stor interesse for det. Og så fandt vi ret hurtigt ud af, at det virkede rigtig, rigtig godt og var en meget elegant service, der kørte superstabilt,« fortæller Morten Bo Rønholdt.

Det blev startskuddet på at begynde at omforme mange af de services, der lå i Shopguns primære API.

Svært at vedligeholde API

Erlang har også vist sig at være velegnet sammen med GraphQL, som Facebook oprindeligt udviklede, fordi SQL og et RESTful API blev for komplekst og tungt til den type forespørgsler, som Facebook benytter sig af. Hos Shopgun stod de med et lignende problem, og det gav problemer med at vedligeholde apps.

Shopsguns app, hvor den danske version er eTilbudsavis, indekserer indholdet af tilbudsaviser, så man kan finde tilbud på produkter i alle ugens tilbudsaviser. Det krævede ganske store forespørgsler til API'et, og når der blevet lavet nye versioner, så skulle man være sikker på, at det stadig virkede for de tidligere versioner.

MMed GraphQL er det nemmere at lave forespørgsler på enkelte datafelter og grave ned i relationer imellem objekter. Med GraphQL er klienterne i kontrol, hvilket medfører bedre bagudkompatibilitet og man slipper for versionering på serveren.

»Vi håber, vi har fået et API, vi ikke længere skal versionere,« siger Morten Bo Rønholdt.

Erlang har dog også begrænsninger. Det er ikke det bedste valg på hastighed, så det er ikke alt, der laves i Erlang. Og så er der dét med at finde udviklere, der kender sproget.

»Mængden af udviklere er ikke stor i forhold til sprog som Go eller sådan noget som Node. Erlang er et funktionelt sprog, og læringskurven kan være ret stejl. Men funktionelle sprog er ved at få en renæssance,« siger Morten Bo Rønholdt.

Nødt til at finde folk fra hele verden

Erlang har også fået overbygningen Elixir, der gør det lidt nemmere at arbejde med Erlang, og har gjort lidt af det samme for Erlang, som Ruby on Rails gjorde for Ruby. Eksempelvis kommer Elixir med pakkehåndtering og Unicode, og Elixir har også en lidt mere konventionel syntaks. Men det kører på Erlang og er kompatibelt med Erlang.

Det begrænsede udbud af Erlang-udviklere har dog også hjulpet Shopgun, for efterspørgslen er tilsvarende meget spredt. Selvom der er bud efter udviklere, der kender Erlang eller Elixir, i San Francisco, så er det ikke nødvendigvis tilfældet, hvis man sidder i Sydamerika.

»Vi har haft folk fra hele verden, som skrev til os, fordi de sad i lande, hvor ingen brugte Erlang. Så vi er ved at hente folk til København. Men ja, vi er nødt til at gå ud og finde folk fra andre lande,« siger Morten Bo Rønholdt.

Erlangs opbygning er lidt anderledes i forhold til de mere almindelige programmeringssprog, webudviklere kommer i kontakt med, så det kan tage tid at lære sproget.

»Vi har en udvikler, som var ansvarlig for vores PHP, som vi nu er ved at udfase. Så han har sat sig til at lære Erlang. Det er back to basics. Jeg er også selv begyndt at skrive lidt Erlang, og det er et fedt sprog,« fortæller Morten Bo Rønholdt.

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

Dynamisk hot-loading af koden er ret anvendt i udvikling, men det er forbundet med et vist overhead hvis det skal fungere i drift. Af den grund benytter man det typisk kun hvis der ikke er andre veje ud. Komplikationen består i at du skal have styr på hvordan intern state i din applikation ændrer sig mellem versionerne. Det koster noget udviklingstid at have styr på dette.

Den typiske observation er at du har nogen stateful long-lived connections over TCP/IP du helst ikke vil miste. F.eks. IRC clients, BGP sessions og lignende. Der giver det mening at lave hot-deploy i stedet for at vende maskinen og miste samtlige sessions. Men selv om du er f.eks. et computer-spil med en serverside, kan du nogen gange dræne den gamle server og når der ikke er flere spillere på den så lukke den ned og opdatere den. Det anvendes ret meget af MMORPG-spil blandt andet og det eneste der sker er at spilleren ender med at der er færre og færre at spille sammen med. En anden taktik er at have 2 systemer: et system tager connections og intet andet. Det andet tager selve arbejdet, men kan så vendes uden at det går ud over connections.

I vores tilfælde dominerer short-lived requests der kan håndteres mere eller mindre stateless. Det gør at vi kan håndtere en genstart af systemerne uden problemer. Vi benytter to metoder til at håndtere deployment:

1) For baggrundsprocesser benytter vi en RabbitMQ broker imellem services. Det gør at vi bare kan lukke servicen ned og lade queue vokse lidt i brokeren mens vi genstarter. Nogen services er simpelthen for små i belastning til at vi kører mere end en enkelt maskine. Brokeren sikrer også at vi kan skalere horisontalt op til et punkt uden for meget sved på panden. Mange har valgt at designe deres interne microservice fabric over HTTP, men det har den pris at alle systemer selv skal håndtere queuing.

2) Services der kræver immediate response bliver bare rullet en af gangen i et standard deploy, og vi lader så en loadbalancer håndtere at maskiner vender. Det giver også mulighed for canary-deploys med rollback. Typisk reboot er målt i sekunder så det er ikke pt noget problem.

Når det så er sagt, så er det rart at en fejl kan håndteres ved lige at loade et modul i produktion udenom det normale deployment. Det gør at du kan lave en canary der checker om ens fix løser problemet. Hvis det gør kan man så via den normale procedure opdatere systemet. Vi har ikke haft det behov endnu, men det er til stede hvis nødvendigt.

  • 1
  • 0
Log ind eller Opret konto for at kommentere