Med nesten to millioner brukere om dagen er VG landets største avis, og med trafikktopper som kan være mye høyere under store hendelser stilles det store krav til løsningene som lages av utviklerne.
– På dagtid har Varnish-serverne våre rett under 20.000 samtidige TCP klientforbindelser fra nettlesere hele tiden. Trafikk-volumet varierer normalt mellom 2 og 3 gigabit per sekund. Riggen vår takler ganske mye mer, forteller Nicolai Langfeldt, devops-utvikler i Schibsted.
Nylig bestemte VG seg for å gjøre en del større endringer i teknologistacken sin, blant annet ved å gå over til Astro-rammeverket.
Vi ba VGs Nicolai Langfeldt og Edvard Høiby fortelle litt mer om teknologiene de bruker – og hvilke vurderinger de gjorde når de skulle bytte deler av stacken sin.
Mens Langfeldt har vært i Schibsted/VG i 7 år og har mer enn 30 års utviklererfaring, er Høiby lærling og har vært i VG i ett og et halvt år.
– Hvordan lager dere frontenden?
Edvard Høiby svarer:
– Vi har valgt Astro som plattform eller fullstack-rammeverk. Her kan vi bruke Island-teknologien og skyte inn komponenter fra forskjellige frontendrammverk som for eksempel React eller Svelte. Frem til nå har vi kun brukt React, men jeg ser ikke bort ifra at det vil lure seg inn litt Svelte etterhvert også.
– Når det gjelder språk så har vi valgt TypeScript, etter noen diskusjoner. Det andre valget vi så på var JSDoc med typehinting, men flertallet på teamet ville ha litt strengere typing enn det og da ga det ikke mening for oss å bruke JSDoc fordi syntaksen til TypeScript var foretrukket.
– Vi bruker Turborepo for å få en monorepo-struktur og for å gjøre bygge- og utviklingsprosessen kjappere. For å håndtere og dele "dependencies", bruker vi NPM Workspaces.
– Vi bruker også Sentry for feilhåndtering. Det hjelper oss å spore og fikse feil fort, noe som forbedrer brukeropplevelsen.
– Astro gir deg superkrefter! mener Stian, som svarer på alt vi lurer på
– Hvorfor valgte dere dette?
– Turborepo gjør bygge- og utviklingsprosessen kjappere. I stedet for å ha en massiv applikasjon, har vi flere mindre apper, én for tag-sider, én for artikler, og så videre. Dette gir oss muligheten til å gjøre raske endringer i forskjellige deler av stacken, uten å måtte skrive om store deler av stacken når vi introduserer nye teknologier.
– Vi får også større fleksibilitet ved at vi kan bruke ulike rammeverk for forskjellige deler av stacken. For eksempel så kan artiklene være utviklet i React, mens tag-sider kan benytte Svelte eller Astro.
– Per nå har vi valgt Astro som plattform for alle appene i det nye monorepoet. Dette er fordi det er et rammeverk som fokuserer på performance, har et aktivt community og en god DX. I Astro skjer det meste av prosessering på server – på treige enheter eller enheter med dårlig internettforbindelse er det ofte kjappere med SSR enn å gjøre prosesseringen på klient. Serverrendret HTML er kjapt, bra for SEO og "accessible".
– Island-arkitekturen i Astro lar deg isolere dynamiske komponenter på siten og hydrere dem uavhengig. Default blir ikke komponentene hydrert, dette må du definere med en av de 4 forskjellige klientdirektivene de har. Disse definerer når komponentene skal hydreres. Dette gjør at man har et bedre forhold til hva man hydrerer på klient. Dette gir redusert initiell lastetid, noe som både er bra for brukeren og SEO-score.
«Vi er en gjeng med utviklere som er glad i forskjellige frontend-rammeverk.»
– Det at Astro er UI-agnostisk er også en grunn til at vi valgte det. Vi er en gjeng med utviklere som er glad i forskjellige frontend-rammeverk. Noen liker React andre Svelte, kanskje man vil teste ut web components eller HTMX. Astro har støtte for å bruke disse og flere som islands. Da har man mulighet til å teste ut nye frontendrammverk for komponenter uten å måtte skrive om renderinglogikken til serveren eller bytte serverrammeverk.
2 av 10 bruker web components: «Bra nok for YouTube, bra nok for deg»
– For reaktive komponenter bruker vi React. Dette er fordi vi er vant til det fra andre repoer og har endel React-spesifikke pakker, men som sagt tidligere så kan det være at det vil snike seg inn noe Svelte etterhvert.
– Vi har rullet ut tre apps fra repoet vårt i produksjon, dette har fungert bra. Det er bra performance og god SEO. Vi har også fått til en god DX synes jeg.
– Nå jobber vi med å kode artiklene i dette repoet også. Når du jobber med flere apper i et monorepo, er det viktig å ikke gjenta koden. Hvis den samme koden skrives mer enn én gang, gjør vi det om til en komponent eller util-funksjon som kan gjenbrukes i de andre appene. Vi har vært flinke på dette og det er moro å jobbe i repoet!
– Hva brukte dere før Astro?
Teknologidirektør Johannes Gorset svarer:
– Før Astro lagde vi et felles web-rammeverk for alle avisene i Schibsted. Det var løst basert på Koa, men aller mest vår egen kode. Det var delt opp i to, én web-frontend, og en backend som tjente både web-frontenden og native-appene våre.
– Det var en gjennomtenkt løsning med mange gode løsninger for å dele kode, men uansett ble det naturligvis komplisert å løse så mange behov samtidig. Derfor hadde vi tro på at å skreddersy en enklere løsning for VG både gir oss mer fleksibilitet og tar mindre tid, og så langt taler alt for at det stemmer!
– Hvordan lager dere backenden?
Nicolai Langfeldt svarer:
– Når man ser på “ops” i VG er “frontenden” vår Varnish sin cacheserver og den har 452 backender. “Backendene” varierer mellom Kubernetes i våre egne datasentere, Kubernetes i AWS, S3-bøtter, eksterne leverandører som leverer tjenester på alle mulige plattformer, og gammeldagse Apache og NGiNX-servere som kjører på fysiske og virtuelle servere i våre egne to datasentre.
– Appene er skrevet i alt fra PHP til React og Astro. Vi leier datasenterplass fra to forskjellige leverandører på to forskjellige steder i Oslo-området. Der eier vi våre egne servere, lastbalanserere, og lagring. Vi bruker veldig lite tid på å være tilstede på datasenterne og montere utstyr: De siste 7 årene har en av kollegaene vært innom der for å bytte disker og batterier en del ganger og for å bytte lagring og lastbalanserer i prosjekt i tre perioder.
– Vi bruker det meste av tiden vår på å lage tjenester for utviklerne og det går en del omtanke og tid med på å ha bra redundans på de viktigste frontend-tjenestene våre. Krigen i Ukraina fikk mange til å tenke på nytt om robusthet og redundans – på en veldig god måte. Vi deltar også nå og da på nyhetsprodukt-utviklingsprosjekter.
– Hvis man står i VMene og Kubernetes i våre egne datasentre så har de også backender: Lagring på Ceph og Netapp og nettverk via Cumulus-svitsjer. Foran, mot internett, står F5 BigIP-lastbalanserere som også har sikkerhetsfunksjoner inkludert DDoS-beskyttelse. Og foran der igjen har vi to forskjellige nettverksleverandører som vi har 10 GB-linker til og en ekstern leverandør som hjelper med å håndtere DDoS. VG er veldig synlig og ganske utsatt for DDoS.
– Nå som de fleste nye tjenester settes opp på kubernetes bruker vi også ganske lite tid på konfigurering og ordning med BigIP, men den har mye fin funksjonalitet og kan programmeres, av alle ting, i Tcl. Det er også mulig å konfigurere den med Terraform, noe jeg har hatt et lite prosjekt med.
– Vi som "opser" mest liker IaC (infrastruktur som kode) godt. På virtuelle og fysiske maskiner bruker vi Chef. Chef har sitt eget DSL men vi har en grei prosent ganske ren Ruby inni der også. Vi bruker ganske mye Terraform til konfigurering av sky-tjenester, men noen av brukermiljøene våre – data, analyse og AI – bruker mest "clickops"fordi de driver mye med utforsking og eksperimentering.
Hva er greia med Terraform og infrastruktur som kode? - Bratt læringskurve
– Vi er open source-folk og på serverne våre går det i Linux, og Cumulus-switcher kjører Linux og Chef de også. Akkurat nå er det litt under 200 fysiske og virtuelle servere. Det blir stadig færre av dem, da jeg startet her var det over 300. For tiden holder vi på å migrere bort fra CentOS og over til Debian. Personlig liker jeg Debian (og Ubuntu) veldig godt og ser fram til å kunne dist-upgrade mellom Debian-versjoner istedenfor å gjøre full reinstall som vi har måttet gjøre med CentOS.
– Ingen devops-stack er komplett uten observability. Fordi riggen vår har lang historie har vi litt mange varianter: Munin, collectd, carbon, influxdb, telegraf, prometheus, grafana og Nagios. For applikasjonene har vi også Sentry. Og dessuten Humio, et skybasert logg-innsamlingssystem som får logger fra alle maskinene og sky-løsningene våre.
– Det som kommer til å leve videre er Munin og Prometheus+Grafana. Munin fordi det har ferdige og enkle dashbord, har massevis av plugins, og er velegnet for fysiske og virtuelle maskiner. På Debian gjennomfører vi også Prometheus for alt vi kan finne det for og visualiserer det i Grafana.
– Jeg føler at Grafana krever ganske mye oppmerksomhet og kjærlighet fordi Prometheus har data på opptil flere formater for de samme tingene. Det er fordi Prometheus-exporterne til forskjellige programmer bytter eksportformat “ganske ofte” noe som krever justering av Grafana-dashbordene som bruker dataene. Fordelen med Munin er at den krever lite diskbåndbredde, lite diskplass og lagrer data i opptil et år.
– Fordelen med Prometheus er at det er veldig fleksibelt og kan samle inn data mange ganger i minuttet, på den andre siden kjører det diskene ganske hardt. Grafana har kjempestor fleksibilitet til å lage grafer og organisere dashbord.
– Bruker dere andre verktøy?
Høiby:
– For tester i dette monorepoet bruker vi Jest. Vi har ikke full coverage, men har noen tester. Vi har skrevet mest unit-tester og noen snapshot-tester, vi jobber også nå med å skrive en fullstendig integrasjonstest som skal teste at tracking fungerer riktig og ikke er feil.
Langfeldt:
– Vi har brukt Jenkins med en customisert pipeline som over tid har gjort det lett å rulle ut til forskjellige container-orkestreringssystemer: For noen år siden mesos og så, med minimale anstrengelser for utviklerne, til Kubernetes i egne datasentre eller i AWS.
– Vi har eksperimentert med Github Actions et års tid og holder nå på å lage actioner for å støtte like enkel utrulling til alle de Kubernetes-clusterne vi måtte ha til enhver tid. Vi regner med å legge ned Jenkins “snart”.
