Gå reaktiv!

Reaktiv manifestet

For bare få år siden ville en stor applikasjon kjøres på noen titalls servere, responstiden ville måles i sekunder, nedetid for vedlikehold ville vare timer og datamengden som ble behandlet ble målt i gigabytes.
En stor applikasjon i dag rulles ut på alt fra små håndholdte enheter til skyplattformer med flere tusen noder. Brukerne forventer respons innen millisekunder og ingen nedetid. Dataene som behandles måles i petabye (1000 terrabyte eller millioner gigabyte).

Nye utfordringer krever nye måter å tenke løsninger på, en ny arkitektur. Bort fra store monolittiske enterprise systemer. Vi trenger systemer som kan reagere raskt – på hendelser, på brukerforespørsler, på endringer i last, på feilsituasjoner. Vi trenger en Reaktiv Arkitektur og vi trenger Reaktiv programmering for å fylle den med innhold.

The reactive manifesto ble publisert for snart et år siden og, selv om ideene bak en slik arkitektur slett ikke er nye, så presenterer manifestet en felles terminologi og en beskrivelse av hva det betyr for en løsning å være reaktiv. Manifestet knytter ikke arkitekturen til noen spesiell underliggende plattform eller noe spesielt programmeringsspråk, men legger frem noen grunnleggende karakteristikker som må oppfylles.

The reactive manifesto beskriver fire kritiske egenskaper som er nødvendig for å gå reaktiv.

De reaktive egenskapene

Event-drevet

På bunnen av det hele, ligger det at applikasjonen må være event-drevet. I det ligger det at alle komponenter i applikasjonen interagerer med hverandre gjennom produksjon og konsumering av eventer; diskrete biter med informasjon som beskriver fakta. Eventene sendes og mottas asynkront og uten blokking.

Skalerbar

Event-modellen gir en løs kobling mellom komponenter, og en programmeringsmodell og en semantikk som kan brukes like godt for distribuerte systemer som systemer som kjører på en enkelt node (lokasjons-transparent). Dette åpner for skalerbarhet.

Feil-tolerant(resilient)

Ved å gjøre feilsituasjonene og kompromissene i distribuert prosessering eksplisitte i programmeringsmodellen, gjør man feilhåndtering ikke til en ettertanke, men til en del av designet helt fra start. Den løse koblingen i en event-drevet modell gir isolerte komponenter der feil kan fanges opp i sin kontekst, pakkes inn som meldinger og sendes av gårde til andre komponenter som kan inspisere feilen og bestemme hvordan det skal reageres.

Responsiv

Alle disse er egenskaper er det som gjør applikasjonen i stand til å respondere raskt, både på brukerforespørsler, ytre og indre hendelser, økning eller minking av last, eller feil i ytre eller indre grensesnitt.

Functional Reactive Programming (FRP)

Reactive Manifestet er plattform- og språk-agnostisk, og beskriver heller en del grunnleggende design prinsipper som i teorien kan implementeres i et hvilket som helst programmeringsmiljø. Så hvorfor bruker jeg spalteplass for Scala & JVM faggruppen på dette? Det er flere grunner til dette. Scala & JVM gruppen har viet mye av sin tid til å arbeide med Typesafe plattformen (se faktaboks), en plattform som foreløpig er ganske unik ved at den tilbyr en komplett verktøykasse for å bygge reaktive applikasjoner. Under dette arbeidet har vi kommet til unison enighet om at den riktige måten å angripe reaktiv programmering på er gjennom funksjonell programmering.

Typesafe plattformen

Typesafe plattformen er en lettvekts applikasjons-stakk som er bygget opp rundt nettopp prinsippene i Reactive Manifestet: event-drevet, skalerbar, feil-tolerant og responsiv. Den kjører på Java Virtual Machine (JVM), enten som en standalone applikasjon, eller du kan deploye den til dine eksisterende applikasjonsservere. Den består av Play rammeverket, Akka og Scala.

Så hva er galt med OOP?

En av de mest fundamentale suksesskriteriene til objekt orientert programmering (OOP) er evnen til å modellere store komplekse systemer på en forståelig måte. Komplekse objekter settes sammen av enklere komponenter og mer spesialiserte komponenter kan arve grunnleggende egenskaper og oppførsel fra objekter i et objekt hierarki. I OOP er det naturlig og intuitivt å bygge oppførselen inn i objektene. Det medfører at man får en sterk kobling mellom dataene og behandling av disse. Modellen i sin natur inviterer til bruk av delt muterbar tilstand. Det vil enkelt si at tilstanden i systemet er modellert gjennom objekter og at alle brukerne (i utvidet forstand) er avhengig av å få tilgang til én konsistent og sann versjon av denne tilstanden.

Det er utstrakt enighet om at delt muterbar tilstand er spikeren i kista for distribuert prosessering.

Modularitet er også et problematisk felt innenfor OOP. Modularitet er muligheten til å bygge en applikasjon eller en funksjonalitet ved å sette sammen moduler som hver har sitt streng avgrensede ansvarsområde. Dette er problematisk innenfor OOP hovedsakelig på grunn av de mange avhengigheter som introduseres til andre objekter i komplekse objekt-hierarkier. Dette gjør både testing vanskelig og kan gjøre at selv små endringer i underliggende kode kan forplante seg langt og ukontrollert ut i applikasjonen.

Modularitet er en svært viktig, spesielt når man skal bygge store systemer, der mange aktører er involvert.

FP til unnsetning

Så, hva er det funksjonell programmering (FP) bringer til bordet i denne sammenheng? Vår evne til å dekomponere et problem ned til små deler avhenger av vår evne til å lime disse bitene sammen til en helhet. Den funksjonelle programmeringsmodellen gir oss to nye typer ‘lim’ – høyere ordens funksjoner og lat evaluering. Å utdype og eksemplifisere disse konseptene får være mat for en senere blogg, der vi blant annet vil vise at:

  • FP gjør det enklere å resonnere om kode, om hva som skjer i koden og hvorfor
  • FP gjør det enklere å komponere (compose) prosessering, slik at man kan oppnå avansert prosessering ved å sette sammen enkle prosesseringskomponenter.
  • FP gjør det mye enklere å unngå kode med delt muterbar tilstand, og oppmuntrer en kodestil som forenkler distribuert prosessering
  • FP gir kompakt og enkelt forståelig kode med færre feil

Gled dere…

Hans Petter Simonsen currently works as a java developer. Before becoming a full time developer, he spent quite a few years working with databases. Programming in general has always been a keen interest, but as of late he has taken a particular interest in functional programming.
Kontakt Hans Petter: