En lang reise fra enterprise til lettvekt

Historiens begynnelse, valg av opprinnelig plattform

Alle historier har en begynnelse. Kantega kom ombord i 2008 og var med på den første vellykkede prodsettingen av enterprise-plattformen, men egentlig startet historien enda litt før dette. SpareBank 1 Utvikling, heretter kalt banken, hadde kjent på en del smerte relatert til integrasjoner mot andre leverandører sine systemer. Grensesnittene var lite homogene og vanskelige å operere mot, og krevde gjerne mye overhead og sikkerhet. Det ble dermed sett på som gunstig å lage en mer organisert kommunikasjon mot systemene, et integrasjonslag som kunne sørge for at alle nødvendige steg for integrasjon var tatt hånd om, slik at bankens øvrige applikasjoner kunne gjøre mer standardiserte kall til dette integrasjonslaget.

Samtidig med dette, så var SOA i vinden, og alle skulle plutselig levere tjenesteorientert, da i betydningen Web Services og SOAP/XML. Dette gjaldt også den største leverandøren av baksystemer. Dermed var det forlokkende med et verktøy som gjorde seg uavhengig av programmeringsspråk og kjøreplattform, og som blant sine salgsargumenter kunne skryte av klikk-og-dra for å integrere mellom de ulike grensesnittene. Det som altså seilet opp som en tilsynelatende god kandidat, var Oracle Service Bus, heretter kalt OSB. Det var jo på den tiden også vanlig å velge produkter fra de store og trygge leverandørene, og man kunne gjerne bli møtt av argumenter som “se alle disse andre store selskapene har valgt dette produktet”, og “dere får et stort supportapparat med på kjøpet”.

Når salgsargumentene ikke treffer våre behov

Sannheten skulle, som med så mange andre tilfeller i IT-verdenen, vise seg å være en annen. Banken opplevde at etter å ha bestilt en ferdig utviklet plattform fra et konsulentselskap, så klarte de ikke å deploye og prodsette den. Kantega ble da i 2008 dratt inn for å hjelpe til, og startet med å lage mange script for å få ting til å henge sammen og la seg prodsette. Utrulling ble uansett ikke smidig, der deploy medførte nedetid, etterhvert meeeeget lang nedetid, og prosessen tok mye tid med fortsatt mange manuelle steg. Da plattformen var oppe og kjørte, så fungerte den i det minste til sitt formål - det ble laget integrasjoner mot baksystemer fra ulike leverandører, og grensesnittene som OSB selv eksponerte internt i banken ble standardisert etter beste evne. Nettbanken og øvrige applikasjoner fikk da en enklere hverdag.

Men det skulle også dukke opp mange andre utfordringer med OSB som integrasjonsplattform i banken. Et imponerende antall utfordringer, faktisk. Det er viktig nå å ha i bakhodet at de kommende avsnittene ikke er skrevet for å kritisere et produkt, de er skrevet for å illustrere hvor mange utfordringer som senere skulle bli løst av å lage en ny integrasjonsplattform.

Utfordringer med gammel plattform

La oss begynne med at selv om OSB kjørte på en JVM i bunn, så var det i utgangspunktet ingen Java-programmering involvert. Selv om det kanskje ikke var fryktelig komplisert å utvikle tjenester på plattformen, så var OSB meget forskjellig fra hva utviklere flest var vant til, og ble regnet som både frustrerende å jobbe med og lite “CV-byggende”. Dermed viste det seg å være vanskelig å finne folk villige til å jobbe på OSB. Dette medførte blant annet at man gjorde seg avhengige av enkeltpersoner, og fikk mindre fleksibilitet til skalering av team og oppgaver. Det ble da ett dedikert team som jobbet på plattformen, og alle oppgaver måtte via dette teamet. Dermed lagde man seg et vannfallsregime med bestillinger, kø og endelig implementering. Først lenge etter bestilling, da tjenestene ble tilgjengelige i testmiljøer, kunne bestiller se om det som ble laget var det de trengte. Dette ga en frustrerende lang vei fra identifisert behov til man faktisk kunne ta i bruk nye integrasjoner nettbanken.

Opprinnelig fantes ingen databasestøtte i OSB, slik at for integrasjoner mot database var det opprinnelig nødvendig å skrive egne applikasjoner ved siden av, og så integrere mot disse applikasjonene. Etterhvert kom det patcher som tillot databasekall, hvilket gjorde situasjonen noe bedre, men samtidig opplevde utviklerne store mengder utfordringer med å få disse databasekallene til å fungere som forventet. For øvrig, når vi nå nevner patcher, så kan vi ta med at det å oppgradere plattformen ofte var en lang og tung prosess, som involverte å kjøre mange tester før prodsetting, samt at hele miljøet måtte tas ned et visst tidsrom. Spennende nok var enkelte patcher inkompatible med andre patcher og måtte fikses på. Patchen med det klingende navnet “XKRR” ble det jobbet sammen med support i månedsvis for å få ut. Hvilket igjen bringer oss over på at supportavtalen med leverandøren nok ikke var så god som den hørtes ut som på papiret - det vi rapporterte inn var som regel meget vanskelige tilfeller, som det tok tid for et begrenset supportapparat å forstå og finne ut av. Google kunne typisk heller ikke hjelpe, da dette var proprietær teknologi som ikke hadde like mange innslag på Stackoverflow som mye annet.

Enterprise er ofte unødvendig stort og komplekst i forhold til problemet som skal løses

Enterprise er ofte unødvendig stort og komplekst i forhold til problemet som skal løses

Det ble flere ganger nødvendig å ta i bruk udokumenterte features i plattformen, for å løse ting slik man ønsket. Etterhvert var viktig kjernefunksjonalitet basert på slike udokumenterte features, hvilket alltid er en risikosport - plutselig kan noe bli blokkert, eller ikke fungere helt som før ved en ny patch.

Planer om ny plattform

Kantega, og banken selv, var flere ganger inne på tanken om å bytte ut plattformen med noe som bedre løste utfordringene vi opplevde. Dette var en modningsprosess, da det var investert mye i gammel plattform, men alle utfordringene vi opplevde tvang frem initiativer. Flere alternativer ble seriøst vurdert allerede i 2013 og 2014, men det var først i 2017 at et internt forprosjekt hadde overbevist banken om at en egenutviklet lettvektsplattform ville være den beste løsningen. Å skulle utvikle en hel plattform selv, samt å migrere alle eksisterende tjenester over på denne, er naturligvis antatt å være en relativt kostbar affære. Da er det kjekt at mye av essensen av planene var å bruke open source og kjøremiljøer med minimale tilhørende kostnader. Dette ville da gjøre at arbeidstimene kunne tjenes inn gjennom sparte lisenskostnader for den gamle plattformen.

Allianse integrasjonslag

SpareBank 1 er en allianse, og når produkter lages til felles bruk, så navngis de gjerne deretter. Den nye integrasjonsplattformen ble da kalt AIL, for Allianse integrasjonslag.

Mål man hadde med AIL, var blant annet å lage en velfungerende plattform basert på lettvekt, open source, utvikling skulle være enkel og effektiv, utrulling skulle være lett, plattformen skulle ha så få “inngripende” avhengigheter som mulig og dermed legge få unødvendige føringer på hvordan utviklere skulle lage koden. Videre ble det tenkt at det er ryddigere og bedre for alle om det er så lett å bygge og rulle ut ny versjon at det aldri blir behov for å gå inn på servere i produksjon for å tukle med konfigurasjon og sertifikater og annet. Alt dette var med på å gjøre hverdagen til en utvikler i banken vesentlig bedre. Som leseren nå sikkert har skjønt, så lyktes man altså med alle disse målene.

Om AIL

Opprinnelig ble AIL skrevet i Java, men etterhvert som Kotlin gjorde sitt inntog er mye nå skrevet i nettopp Kotlin. Disse to språkene fungerer fint sammen. Det er laget støtte for enkelt å sette opp både REST- og SOAP-tjenester (mye god legacy er jo fortsatt på SOAP…). Det er også støtte for å gjøre kall til begge slike typer baksystemer, samt database. Det er også mye mer som kommer out-of-the-box, for eksempel transaksjonslogging, autentiseringsmekanismer, registrering og eksponering i bankens tjenestekatalog, helsesjekk-endepunkt, oppsett for å kjøre i Docker-container, oppsett for praktisk bruk av Wiremock i tester og mye mer. Det ble også laget en såkalt applikasjonsgenerator i Yeoman, der en utvikler enkelt kan svare på en håndfull spørsmål om ønsket applikasjon, og få generert opp et skall som i løpet av minutter faktisk kan kjøres opp i testmiljø og med et par manuelle steg også i produksjon. Generatoren kan blant annet opprette git-repository automatisk, slik at CI-verktøyet Jenkins automatisk plukker opp applikasjonen og umiddelbart sørger for bygging og deploy til et testmiljø.

AIL er basert på Maven for bygging, og utviklere frykter gjerne “dependency hell” og slik moro, at man har ulike versjoner av avhengigheter dratt inn, og applikasjonen står og faller på hvilken som faktisk leses inn ved kjøretid. Dette er løst gjennom bruk av en såkalt framework BOM, bill of materials, der et sett med kjente versjonsnumre som fungerer sammen er definert, og det er da i utgangspunktet disse hver applikasjon benytter. Slik kan man også relativt enkelt sørge for raskt å tette sikkerhetshull, når alt som må gjøres er at versjonsnumre oppdateres i BOM, og applikasjonene bare oppdaterer sin link til BOM. Som et ytterligere tiltak, så er maven enforcer plugin tatt i bruk, denne tillater ikke at ulike versjoner dras inn ved bygging.

Lettvekt - lett som en fjær

Lettvekt - lett som en fjær

Det som først føltes litt rart, med tanke på all historikk, men som så ble helt naturlig, er at behovet for å logge inn på servere og “ta en titt” eller “fikse konfigurasjon” bare er borte.

Nå finnes ikke lenger noen supportavtale med en ekstern aktør, men til gjengjeld er helt ordinær open source brukt, slik at o store internett som regel har løsninger. Og her finnes ikke lenger spor etter proprietære produkter eller bruk av udokumenterte features.

Prikken over i-en

Opprinnelig var jo den gamle integrasjonsplattformen og teamet som forvaltet denne en flaskehals. På AIL, derimot, viste det seg fort at alle utviklere i alle team i banken kunne implementere integrasjonene sine selv, og fikk dermed full vertikal kontroll på funksjonalitet. Samt at man slapp å gå via bestillinger og vente. Da kunne også de andre teamene ta eierskap til sine integrasjoner. Som en bonus viste det seg at utviklet kode og byggesteiner i AIL kunne hentes til annen bruk også.

Tommel opp til SpareBank 1 Utvikling for det vi har opplevd som godt samarbeid hele veien, og for å ha laget en utrolig god integrasjonsplattform! Arbeidet med AIL ble startet i 2017, de første tjenestene kjørte i produksjon tidlig i 2018, og deretter gikk det slag i slag og den ble relativt raskt den dominerende plattformen med tanke på antall tjenester og trafikk. I klassisk stil er det alltid et etterslep, men våren 2021 ble OSB skrudd av og all trafikk var over på AIL.

Om noen skulle være interessert i litt flere tanker om den menneskelige faktor oppi dette, les gjerne også En solskinnshistorie om å legge ned et team.