Hva er backend-utvikling?

Tilbake til kompetanseguidens hovedside

Backend-utvikling handler om den delen av nettsider og programvare som ligger bak det du ser – prosessene i bakgrunnen som får det hele til å fungere som det skal. Det et hav av backend-språk, hvor blant annet Java, Python, C++ og PHP er blant de mest brukte.

Vi har bedt Joanna Gaudyn, grunnleggeren av Le Wagon i Norge, og Harald Schult Ulriksen, seniorkonsulent og partner i Aurum, om å fortelle litt mer om hva backend-utvikling innebærer.

Kort oppsummert; Hva er backend-utvikling?Gaudyn:

Backend-utvikling er begrepet som blir brukt om «behind the scenes»-aktiviteter som skjer når man gjør noe på en nettside. Det kan være å logge inn på kontoen din, eller å kjøpe en lommebok fra en nettbutikk.

En backend-utvikler fokuserer på ting som server, applikasjonsarkitektur og database, som sammen gjør at den brukervendte delen av nettsiden i det hele tatt kan eksistere. Du kan tenke på det som en klokke: Frontend er det du ser, altså urskiven, mens backend er hele mekanismen bak, som har ansvar for at klokken går som den skal og viser riktig tid.

Ulriksen:

Backend-utvikling handler om laget under klientene, ofte ligger ansvaret for overholdelse av forretningsregler hos backend, selv om dette ikke fritar frontend.

Videre er det gjerne i backend man integrerer mot interne systemer eller tredjepart. Lagring og deling av data for videre bruk faller også naturlig inn hos backend. Og selv om frontend for eksempel rapporterer til Google analytics, så kan det gi mening at backend hjelper frontend med verdiene som skal sendes.

Hva brukes backend-utvikling til i 2020? Når er det viktig å kunne dette?Gaudyn:Backend er til stede overalt, selv om du kanskje ikke er klar over det. Uansett om du bestiller din neste ferie med Airbnb, spiller musikk med Spotify eller betaler med Vipps, så er det en logikk bak disse appene som er bygget av backend-utviklere.

Å forstå backend (og koding generelt) kan hjelpe deg å forstå hvordan systemene du bruker hver dag fungerer, men også å forvandle dine egne ideer til fungerende digitale løsninger.

Ulriksen:Det er få prosjekter uten backend, og det er viktig å forstå konsekvensene av de valgene man tar. Dette er valg som kan begrense forretningen, og man risikerer trege systemer, monolitter og store kostnader hvis det ikke deles opp og løses på en måte som understøtter de forretningsmessige behovene.

Så sent som i helgen var det et eksempel på Twitter (under) på at systemvalg begrenser forretningsprosessene. Dette kan selvfølgelig være gjort med overlegg fordi man er i en situasjon hvor man har tatt et kvalifisert valg , men det illustrerer godt at valg gjort på backend påvirker hele applikasjonskjeden.

Har du noen eksempler på typiske situasjoner eller utfordringer som backend blir brukt til å løse?Gaudyn:

En del av dette dekket jeg i forrige spørsmål, men det kan også være noe så enkelt som å få en repetitiv oppgave automatisert.

Ulriksen:Her kan jeg for eksempel nevne det siste prosjektet jeg var på hos NRK, hvor vi laget en løsning for å håndtere favoritter og sist sett/hørt for NRK TV og NRK Radio. Frontend-applikasjonene snakker med et backend-API som så kommuniserer med tjenesten.

Backend finner man stort sett overalt, det som varierer er at det ikke er alle backend-systemer som kommer med en frontend. Man kan finne alt fra backend-systemer som knapt nok har et admin-grensesnitt, til veldig synlige backend-systemer som f.eks. understøtter en mobilapplikasjon.

Er det noen vanlige språk, rammeverk eller verktøy som er særlig knyttet til backend-utvikling?Gaudyn:I motsetning til med frontend, hvor det bare er tre språk som brukes for å lage den synlige delen av en nettside, så finnes det hundrevis av språk du kan bruke til å bygge backend-delen. I Norge er Java et av de mest populære. Andre eksempler er Python, C++, Go eller PHP.

Hos Le Wagon har vi valgt Ruby som vårt backend-språk, av tre grunner:

• Det er det første språket som setter utvikleren i sentrum av skaperprosessen. De fleste språk ble laget med hensyn til maskinen (robusthet, stabilitet, prestasjon...). Konsekvensen er at programmeringsspråkene kan være lite intuitive og vanskelige å lære. Ruby ble skapt for å tilfredsstille utviklerne. Det er konsist, elegant og leses som engelsk. Så studenter kan fokusere på å utvikle sin logiske tenkning i stedet for å memorere syntaks.
• Det finnes mange backend-språk. Ruby er objektorientert akkurat som PHP, Python, Java og C++. Så fort du har lært objektorientert programmering, er du klar til å lære deg andre backend-språk. Du trenger bare litt tid og disiplin. Flesteparten av våre uteksaminerte studenter som nå jobber som profesjonelle utviklere, koder i mange forskjellige språk, rammeverk og stacks.
• Ruby, sammen med Ruby on Rails (et åpen kildekode-rammeverk), er en ekstremt effektiv måte å bygge webapplikasjoner på. Ruby on Rails har et fantastisk samfunn av utviklere, og ble brukt til å bygge selskaper som Airbnb, Twitter, Soundcloud, Kickstarter og Shopify.

Med andre ord: Når du vurderer å lære deg å kode, bør du ikke gjøre det for å lære ett språk, men for å bli i stand til å tenke som en programvareutvikler. Altså en som kan overføre problemer til programvarekomponenter og bygge løsninger fra bunnen. Koding er der for å bygge produkter og løse virkelige problemer.

Ulriksen:Java og C# har lenge vært to gjengangere, men også Node, Kotlin og Go gjør seg gjeldende. De siste par årene har funksjonelle språk fått en oppsving, enkelte har tatt det ut i Haskell, men også Elixir/Erlang har tatt seg opp, selv om Go, Kotlin og Clojure nok er de største funksjonelle språkene.

For egen del har jeg fått stor glede av å jobbe med F#, og er stadig overrasket over hvor få feil det er i løsningen vi laget, samtidig med hvor trygt og enkelt det er å endre når man jobber med et funksjonelt og sterkt typet språk.

Sett opp mot frontend er datalager/databaser noe man i backend-sfæren svært sjelden kommer utenom i en eller annen form. Systemintegrasjoner er også daglig kost, og det gjelder å vite hvordan man skal håndtere tredjepartssystemer på en god og trygg måte.

Hvordan er vanskelighetsgraden og læringskurven? Hvilke forkunnskaper er det eventuelt en fordel å ha hvis man ønsker å sette seg inn i det?Gaudyn:I Le Wagon mener vi at alle kan lære å kode. Du trenger ingen teknisk bakgrunn for å melde deg på vår webutvikling-bootcamp. Vi forventer tre ting fra studentene våre: Vær (veldig) motivert, vær nysgjerrig, vær sosial. Det sagt, læringskurven er veldig bratt, spesielt hvis du kommer fra et helt annet felt.

Noen ting som gjør det enklere å lære å programmere (men ingen av dem er en forutsetning for å komme i gang eller å bli god i det): 1) Å være god i matte, 2) å like gåter (problemløsing, det være seg kryssord, sudoku eller krimbøker), og 3) være god til å lære språk: Det kalles et programmeringsspråk av en grunn; hvis du er god til å forstå grammatikk vil du sannsynligvis finne ut av syntaks lettere.

Ulriksen:Starter man enkelt med en SQL-database og et ganske normalt HTTP web-API så er det ikke så mye som skal til, den store læringskurven ligger ofte i forståelse av forretningen og de følger dette får for implementasjonen. Hvis det gjør vondt, skalerer dårlig eller er vanskelig å vedlikeholde, så har man gjerne bommet på dette, kanskje på noe så basalt som oppdelingen av løsningen.

God kjennskap til underliggende teknologier som HTTP, databaser (både SQL og NoSQL), meldingstjenester, datastrømmer og REST er et godt utgangspunkt, og jeg tror det er enorm fordel å lytte til frontend-, forretnings- og andre backend-utviklere. Samtidig skal man ikke glemme at løsningen må kunne rulles ut uten nedetid og feil, for å klare dette er kunnskap om infrastruktur som kode, overvåking og kontinuerlig produksjonssetting viktig.

Hvilke ulemper eller utfordringer ser du med backend-utvikling?

Ulriksen:Det er et par utfordringer jeg ser nå, det ene er mengden ny teknologi fra skyleverandørene. Det går knapt en dag uten at de kommer med en ny tjeneste eller prismodell, bare å være oppdatert på Kubernetes er en jobb i seg selv.

Og her gjelder det å holde tunga rett i munnen, i det siste prosjektet jeg var på gikk vi fra en dokument-database til en tabellbasert lagring. Prisen falt fra ca. 20.000,- i måneden til 600,- for rundt 100GB data i ett enkelt miljø. Dette høres i utgangspunktet ut som et smart valg, samtidig må man klare å vurdere om dette gjør at man bruker mer utviklingstid på å lage funksjonalitet man ellers ville fått med dokument-databasen.

Hele situasjonen rundt skytjenester minner en del om det årlige kjøret om å bli det hotteste frontend-rammeverket. Her tror jeg det er lurt å ha is i magen og ikke bare går for den neste hypen. Det er derfor viktig at man kjenner funksjonaliteten, begrensningene og prismodellen til de forskjellige skytjenestene, og kan vurdere dem opp mot krav, slik at man gjør en kvalifisert beslutning. Man må heller ikke glemme operasjonaliseringen av tjenesten, med tanke på oppetid, responstid, last, innsikt, backup og daglig drift.

En annen utfordring går på forståelse av forretningen, hvis backend ikke kommer med i diskusjoner rundt funksjonalitet og krav er det veldig lett å bomme på implementasjonen. Man kjenner rett og slett ikke bakgrunnen for valgene som er tatt, det være seg ytelse eller funksjonalitet. Det er viktig at dette prioriteres, og at man klarer å lage små leveranser som gir verdi. I Aurum merker vi stadig at forretningsforståelse er viktig og etterspurt hos kundene. Vi bruker tid og ressurser på dette, eksempelvis i form av strategisk domenedrevet design, DDD-konferanser, kurs og workshops.

Hva er forhistorien til backend-utvikling, og hvordan har utviklingen vært?Ulriksen:Mye av det vi jobber med i dag baserer seg på avhandlinger og forskingsartikler fra 60-70-tallet, selv om teknologien i seg selv på langt nær har stått stille. Det være seg alt fra Actor Model som stammer fra en avhandling fra 1973, til algoritme-implementasjoner som Bloom filter som er fra 1970.

Og selv om mye av det man bygger på er gammelt, står det på ingen måte stille. De siste årene har skytjenester kommet for fullt, og gitt oss tilgang til verktøy og teknologier man tidligere ikke vurderte før man var av en helt annen størrelse. Det er også en profesjonalisering når det kommer til operasjonalisering, og en forventning om at alle problemer er løst, det være seg selvangivelse eller MGP, for Google og Facebook klarer det jo.

Her tror jeg man skal huske på at vi er et lite land og man har ikke nødvendigvis de samme ressursene til disposisjon, det betyr at det hver dag tas valg og avveininger mellom funksjonalitet og operasjonalisering.

Hvordan ser du for deg at backend-utvikling kan videreutvikles?

Ulriksen:Mange utviklere er veldig glad i å generalisere problemer, og går rett på tekniske løsninger. Jeg tror det vil være positivt om man i større grad jobber med forretningsforståelse, det å snakke med brukere og kunder, det å forstå bakgrunnen til kravene som er stilt, og også kunne utfordre disse.

Samtidig er det viktig å få tid og rom til å prioritere arbeid med operasjonalisering, alt fra kontinuerlig produksjonssetting, til overvåkning og test av systemet under stress. Enten om det er en tjeneste som feiler eller en overraskende mengde last.

Jeg er redd for at mange har et for stort fokus på leveranse av funksjonalitet, uten at man får tid til å jobbe med ivaretakelse av løsningen som er laget. I forbindelse med arbeidet rundt personalisering hos NRK kjente vi etter hvert systemet så godt at kun et kort kikk på overvåkingsskjermen kunne fortelle utviklerne om ytelsen var der den skulle, og om det hadde vært noen hendelser siden gårsdagen.

Hvilke råd kan du gi til en som ønsker å lære seg dette?Gaudyn:Vær nysgjerrig og motivert! Å lære noe nytt er aldri lett, så ikke bli demotivert hvis det er noe du ikke forstår med en gang. Bare stå på, og til slutt kommer ting til å falle på plass.

Det er mange gode ressurser på nett, som er en flott måte å komme i gang på. Vi arrangerer også gratis workshops for nybegynnere hos Le Wagon, så du kan bli med oss en kveld og skrive dine første linjer med kode.

Ulriksen:Jeg vil anbefale å sette seg inn i Devops, Devops Handbook og Continuous Delivery Maturity Model kan være fine utgangspunkt. Skytjenester kommer man rett og slett ikke utenom, det må læres, og gjerne fra mer enn en leverandør. Klarer man så å koble dette opp mot Devops-biten er man kommet langt.

Det å lese forskningsartikler, spesifikasjoner og bøker om sentrale tema er også en bra ting. Eksempelvis vil en forståelse av RFC 7234 om HTTP Cache påvirke design av Rest-endepunkter. «Papers we love» er en fin kilde til å oppdage nye emner og tema å sette seg inn i.

Funksjonell programmering mener jeg helt klart har noe for seg på backend, og jeg anbefaler å prøve det ut i et prosjekt.

Sist, men ikke minst, mener jeg domenedrevet design og forretningsforståelse er viktig. Evner man ikke å forstå hvorfor man lager det man gjør, så går det veldig ofte veldig dårlig.