Casestudie: Hathora sparer millioner ved å kombinere skyen og fysiske servere

Noen ganger ender selve infrastrukturen som hjelper deg med å oppnå en vellykket lansering, opp med å bli en hindring når virksomheten din skyter fart.

For Hathora var dette både bokstavelig talt sant og en smule ironisk: Selskapet driver med å levere kritisk infrastruktur og serverorkestrering til videospillstudioer, slik at de kan være vert for og skalere flerspillerspill på nettet.

Det er et enormt marked etter de fleste målestokker. Analyseselskapet Technavio anslo for eksempel at markedet for massivt flerspillerspill på nettet (MMO) vil vokse med nesten 30 milliarder dollar mellom 2025 og 2029. Andre analytikere anslår tilsvarende vekst de neste rundt fem årene.

Hathora ønsket å lansere og skalere plattformen sin raskt, så selskapet fulgte det som har blitt en vanlig oppskrift for mange oppstartsbedrifter, små team og andre virksomheter: De satset fullt ut på skyen og kjørte alt på Amazon Web Services med EKS, skygigantens fullstendig administrerte Kubernetes-tjeneste. Ambisjonene deres så ut til å være grenseløse: Hathora ønsket å betjene spillutviklere i alle størrelser, fra de minste teamene til de største studioene og alle imellom

Og det fungerte – til et visst punkt. Mer enn 100 spillstudioer tok i bruk Hathora-plattformen i løpet av seks måneder etter den første lanseringen. Denne innledende suksessen avdekket et grunnleggende problem, gitt Hathoras mål om å betjene spillstudioer i alle størrelser og fra hele verden: Da de begynte å samarbeide med stadig større studioer, ble økonomien i den skybaserte infrastrukturen raskt uholdbar – i en slik grad at de risikerte å gå glipp av en stor og lukrativ del av det totale markedet.

I denne casestudien får vi et førstehåndsinnblikk i hvordan Hathoras CTO og team forvandlet selskapets opprinnelige forretnings- og teknologistrategi med potensielt dramatiske resultater – i tillegg til noen lærdommer for andre teknologiledere i alle bransjer.

Selskapet og CTO-en

Selskap: Hathora, en global leverandør av kritisk infrastruktur og serverorkestrering for videospill studioer, slik at de kan være vert for flerspillerspillene sine på nettet.

CTO-en: Harsh Pandey, som også er selskapets grunnlegger:

«Vi bygde Hathora for å gi spillstudioer i alle størrelser tilgang til infrastruktur i global skala uten at de måtte bygge den selv. Men da vi begynte å beregne prisene for større studioer, brøt økonomien sammen. Kostnadene i skyen, særlig datautgående trafikk, gjorde tilbudet vårt uholdbart for akkurat den typen kunder vi ønsket å betjene.»

Hovedkontor: New York City

Kundebase: I dag betjener Hathora (bokstavelig talt) kunder over hele verden fra 14 globale regioner fordelt på seks kontinenter.

Forretningsproblemet

Store ambisjoner byr vanligvis på store utfordringer, og det var nettopp tilfellet for Harsh og Hathora.

Noe av dette er grunnleggende knyttet til spillbransjens natur: MMO-spill er ikke små lokale butikker med forutsigbare trafikkmønstre. Flerspillerspill må derimot levere konstante oppdateringer til hver eneste tilkoblede spiller samtidig, på en svært effektiv måte.

Det betyr at enorme mengder data regelmessig flyttes frem og tilbake mellom backend-infrastrukturen og enkeltspillere, som kan telle millioner for de største spillene. Og hvis du synes kundene dine er krevende, vel, la oss bare si at seriøse spillere ikke nødvendigvis er særlig tålmodige når det gjelder spillytelse og brukeropplevelse.

Å kjøre spillserverarbeidsbelastninger fra Hathoras skybaserte plattform fungerte godt for mindre studioer. Men da et større studio kontaktet selskapet om priser, innså Harsh og teamet begrensningene ved den økonomiske modellen.

«Vi visste at vi hadde en utfordring å håndtere da et stort spillstudio som brukte plattformen vår for spillserverhosting til interne spilltester, spurte om prisen for lansering,» fortalte Harsh oss. «Den anslåtte båndbreddekostnaden deres kom på over én million dollar i måneden.»

Det var fire ganger de normalt forventede databehandlingskostnadene for å kjøre spillet, ifølge Harsh. Det var ikke bærekraftig for studioet eller Hathora. Det satte Hathora ved et såkalt veiskille: fortsette med den opprinnelige, skybaserte strategien og risikere å miste segmentet for store studioer, eller gjøre en endring.

«Problemet som måtte løses, var prisen, enkelt og greit», sier Harsh.

Løsningen var imidlertid teknisk: Hathora måtte forvandle sin egen infrastruktur for bedre å møte de unike kravene til spillserverarbeidsbelastninger, samtidig som de tok i bruk en prismodell som selv de største studioene enkelt kunne benytte.

Hva de gjorde med det, og hvorfor

Teknologifolk innen alle områder har hørt rikelig med presentasjoner om fordelene ved å flytte infrastruktur og arbeidsbelastninger til skyen, eller ganske enkelt lansere en virksomhet som bare bruker skyen. Dette har vært en tydelig trend i flere år, og Hathora var ikke noe unntak.

Hathora gikk i nærmest motsatt retning for å løse problemet med store kunder, ved å ta i bruk en hybridsky-arkitektur og til slutt satse stort på en gammel traver: fysiske servere. 

(Les artikkelen vår om denne nyere trenden med å flytte ut av skymiljøer og over til lokal infrastruktur.)

Harsh forteller om selskapets utvikling:

«Vi gikk over til en hybridmodell og fulgte med på infrastrukturkostnad per samtidige økt, ytelsen for forsinkelse på tvers av globale regioner og ingeniørarbeidet som krevdes for å drifte alt. Ved å flytte 80 % av arbeidsbelastningene våre til fysiske servere kan vi redusere beregningskostnadene nesten med halvparten og få båndbreddekostnadene ned med mer enn 90 %. Nå administrerer vi over 30 000 kjerner på tvers av 14 regioner med et relativt lite ingeniørteam. Denne effektiviteten og rekkevidden ville vært umulig med den opprinnelige arkitekturen vår.»

De bruker fortsatt skyinfrastruktur for skalerbarhet og etterspørselstopper, som utgjør omtrent 20 % av arbeidsbelastningene (i stedet for 100 %). Hathoras teknologistakk baserer seg imidlertid nå på ressurser fra to leverandører av fysiske servere samt AWS- og GCP-skyressurser, i stedet for å ha alt på AWS. Harsh og teamet valgte Talos Linux, en minimalistisk distribusjon utviklet spesielt for Kubernetes-miljøer, og Omni (også fra Sidero Labs) for orkestrering fra ett enkelt kontrollplan på tvers av hybridmiljøene.

Det sier seg selv at dette ikke var like enkelt som å slå en lysbryter av eller på. I tillegg var det fordeler og ulemper å ta hensyn til. Det å bruke bare skyen hjalp i utgangspunktet Hathora med å lansere raskt og vellykket. Å gå bort fra denne modellen innebar at de måtte gi avkall på noen av fordelene skyen tilbyr, i hvert fall til å begynne med:

«Å gjøre en endring innebar å gi avkall på mye av bekvemmeligheten skyplattformer tilbyr», sier Harsh. «Vi ville miste enkel automatisk skalering, innebygd overvåking og administrerte tjenester. Det økte den driftsmessige kompleksiteten. Vi måtte også bevise at vi kunne matche eller overgå skyens ytelse. Det var ingen garanti for at vi ville finne leverandører eller verktøy som fungerte slik vi trengte. Men vi mente at det var avgjørende for forretningsmodellen vår å få kostnader og ytelse under kontroll, og vi var klare til å ta den risikoen.»

Satsingen gir resultater og baner vei for neste fase i Hathoras vekst: Selskapet betjener nå kunder på seks kontinenter. Det kan levere den samme kritiske infrastrukturen til de største studioene til en betydelig lavere kostnad enn tidligere. Det tilbyr også mer detaljert kontroll over de unike kravene til spillarbeidsbelastninger (dette er også en viktig fordel med programvare for kravhåndtering), med kontroll på nodenivå gjennom Talos Linux og samlet klyngeorkestrering med Omni, uavhengig av hvor arbeidsbelastningene kjører.

«Disse verktøyene er minimalistiske, sikre og enkle å drifte på tvers av ulike infrastrukturer», sier Harsh. «Vi vurderte teknologistakken vår basert på ytelse, kostnad og hvor mye kontroll vi ville beholde. Det nye oppsettet gjør at vi kan drifte med et lite team og skalere globalt uten å være bundet til én bestemt leverandør.»

Det lille ingeniørteamet i Hathora har faktisk blitt en slags uoffisiell KPI. Det viste umiddelbare ytelses- og kostnadsgevinster etter at den første komplette regionen ble flyttet til hybridmodellen, og skalerte deretter raskt (driver nå 14 regioner over hele verden).

«Hver gang noen får vite at infrastrukturen vår bare administreres av noen få ingeniører, blir det et øyeblikk som minner oss på hvor langt vi har kommet.»

Viktige innsikter & lærdommer

Du trenger ikke å jobbe i bransjene for digital infrastruktur eller videospill for å ta i bruk lignende prinsipper og lærdommer i din egen virksomhet.

• Lytt til kundene dine: Harsh og teamet innså at de hadde et problem – og at de måtte være proaktive for å løse det – ved å lytte til kundene sine, særlig det store studioet som hadde brukt Hathora til intern testing og senere ba om kostnadsestimater dersom de kjørte selve spillet på plattformen. CTO-er har like stort ansvar for å løse kundenes problemer som for å bygge teknologiske løsninger – de to tingene henger uløselig sammen.

• Ikke vær redd for å endre kurs. «Sky først», «skyfødt» og lignende uttrykk bør behandles som tilpasningsdyktige strategier, ikke som hellige dogmer. Det samme prinsippet gjelder i stor utstrekning: Bare fordi du starter med en bestemt strategi, betyr ikke det at du må holde fast ved den for alltid. Hathora kunne ha stått på stedet hvil og fortsatt utelukkende i skyen, men det ville ha begrenset vekstpotensialet og til syvende og sist ytelsen til spillene som kjører på infrastrukturen deres.

Overgangen til en hybridmodell gjorde det mulig for selskapet å betjene kunder av alle størrelser og forbedre ytelsen takket være større fleksibilitet og kontroll ved håndtering av de spesifikke kravene til spillarbeidsbelastninger. Hathora har siden kunnet lansere et bedriftsnivå som gir de største studioene forutsigbare priser og sterke ytelsesgarantier.

• Vær grundig i analysen. En slik transformasjon kan ikke gjennomføres ved gjetting. Harsh og teamet gjennomførte en fullstendig konsepttest med Talos og Omni for å sette det strategiske skiftet på prøve:

«Da vi hadde validert at vi kunne orkestrere alt gjennom ett system, migrerte vi vår første komplette region. Ytelsesforbedringene kom umiddelbart. Derfra rullet vi ut modellen globalt og la til leverandører og lokasjoner underveis», sa Harsh.

De analyserte fordeler og ulemper – inkludert det innledende tapet av fordelene ved skyen som Harsh beskrev ovenfor – for å minimere overraskelser. De visste at de måtte finne en Kubernetes-vennlig løsning som kunne orkestrere alt på tvers av flere miljøer og regioner, og i praksis behandle alle maskiner likt, uansett om de kjørte på fysisk maskinvare eller i en sky.

Harsh bemerket at de også gikk grundig til verks med leverandørtesting, sammenlignet AMD- og Intel-prosessorer, testet nettverksytelse i virkelige situasjoner og vurderte leverandørene ut fra hvor godt de presterte sammenlignet med AWS’ Global Accelerator. 

«Vi sørget for at det nye oppsettet vårt ikke bare var billigere, men også raskere og mer pålitelig i de regionene som betydde mest.»

• Tenk langsiktig: Omfattende kursendringer som denne handler ikke bare om å løse engangsproblemer. Når de gjennomføres riktig, åpner de for stadig flere muligheter fremover. Det langsiktige perspektivet gir allerede resultater for Hathora. De fortsetter å utvikle nye funksjoner for større studioer, som dedikerte klyngealternativer, regional peering for overføringer med lav forsinkelse og forbedret observasjon under direktesendte arrangementer.

Harsh sa også at Hathoras nye infrastrukturmodell for spill viser potensielt utbytte i andre bransjer som krever respons i sanntid og høy gjennomstrømming, og at selskapets langsiktige plan er å rulle ut nye løsninger for utviklere utenfor spillbransjen.

«Overgangen til en hybridmodell ga oss langsiktig fleksibilitet. Nå kan vi gå inn i nye regioner raskt, teste nye maskinvareleverandører uten leverandørbinding og gi kundene mer kontroll over hvordan infrastrukturen deres distribueres. Plattformen har blitt langt mer modulær og tilpasningsdyktig.»

For flere casestudier og veiledninger kan du abonnere på nyhetsbrevet til The CTO Club.