Shoprockets reise til mikrotjenester: Del 1

Noen måneder inn i jobben min hos Shoprocket begynte jeg å bli frustrert. Vi hadde en PHP-applikasjon som ble utviklet av vårt lille team av lysende utviklere, spredt over hele verden. Hvorfor ble jeg frustrert? For meg så det ut som om feilrettinger skapte flere feil, integrering av nye funksjoner ikke var så enkelt som det kunne vært, og utplasseringer var sjeldne og stressende. Årsaken til disse problemene: høyt sammenknyttede koder.

Vi hadde en monolitisk applikasjon, og nesten all vår kodebase befant seg i ett GitHub-repository. Oppdateringer eller rettinger av én funksjon skjedde ofte på flere steder. For testing hadde vi en peer review-prosess, hvor minst to andre utviklere måtte godkjenne en gren før den ble flettet inn i master og utplassert. Alt dette betydde at når feil klarte å snike seg inn under radaren, var det ofte vanskelig å finne de ødeleggende endringene. Og når vi først gjorde det, ville rettingene gjennomgå den samme prosessen, og hele applikasjonen måtte settes ut på nytt.

Som en entusiastisk ung utvikler som alltid så etter det nye, når jeg kom over mikrotjenester, tenkte jeg at denne arkitekturstilen ville løse alle våre problemer. Det finnes ingen formell definisjon av mikrotjenester, men fra min forskning tok jeg med meg at mikrotjenestearkitektur er en måte å designe programvareapplikasjoner som distribuerte systemer av uavhengige tjenester, hver svært spesialisert og med sitt eget livssyklus. For lesere som ønsker en mer detaljert introduksjon til konseptet, anbefaler jeg Martin Fowlers utmerkede artikkel.

Det var mange aspekter ved mikrotjenester som interessert meg, men to spesielt: For det første, ideen om å dele opp applikasjonen i tjenester med svært strenge grenser. Dette reduserer sjansen for at logikk spesifikk for én forretningskontekst lekker mellom komponenter fordi grensesnittene mellom grensene må planlegges nøye. Det er ikke så enkelt som å gjøre lokale funksjonskall; For det andre kan hver komponent ha sin egen uavhengige livssyklus. Dette lar teamene ta eierskap over koden sin og bruke en teknologistack som er best egnet for den individuelle tjenesten. I tillegg tillater det mer finmasket kontroll over applikasjonen, siden endringer kan settes ut på én tjeneste om gangen, og rulles tilbake uten å påvirke resten av applikasjonen hvis noe går galt.

Så, jeg var solgt. Shoprocket ville dele opp monolitten! Dette er den første i en kort serie med blogginnlegg som følger denne reisen. Mitt håp er at lesere som planlegger eller går gjennom en lignende overgang vil lære av våre suksesser og feil, og føle seg bedre forberedt på å ta på seg denne utfordringen i egne prosjekter.

Min første utfordring var ikke teknisk, men menneskelig. Jeg måtte selge ideen til resten av teamet. De så nysgjerrige ut, men delte ikke den samme entusiasmen og var motvillige til å gi opp utviklingstimer på dette tidlige stadiet av produktets liv. Heldigvis ville CTO-en at jeg skulle se på vår sesjonsadministrasjon, og jeg grep muligheten ved å overbevise ham om at jeg kunne dele av en sesjonstjeneste.

I retrospekt kan dette kanskje ha vært et dårlig valg av komponent for en første tjeneste. Produktet vårt inkluderer en javascript-plugin som muliggjør e-handel på enhver nettside. Vi behandler sesjoner som en ressurs, ved å lagre sesjonsinformasjon i databasen for detaljert analyse av KPI-er som handlekurvforlatelse. Imidlertid er denne ressursen ikke så håndgripelig som noe som bestillinger eller linjeelementer. Dessuten brukte vi sesjonsressursen med nesten hver endring i applikasjonsstatus. Dette betydde at tjenesten uunngåelig ville være omgjengelig med resten av applikasjonen, noe jeg ikke forutså, men som gjorde oppgaven min vanskelig.

Etter å ha overbevist sjefen min, økte jeg forskningen min på mikrotjenester. Bortsett fra den nevnte artikkelen, fant jeg også Sam Newmans ‘Building Microservices’ som en uvurderlig ressurs. Jeg vil ofte referere til dem begge i innleggene mine.

I boken sin anbefaler Newman først å restrukturere en eksisterende applikasjon til moduler som gjenspeiler domenegrensede kontekster. Deretter, når utviklerne er fornøyde, kan modulene deles av i sine egne tjenester. Grunnen til dette er at det er mye enklere å bryte ned og skrive om moduler hvis grensene deres ble dårlig valgt, enn å bryte ned og skrive om hele tjenester, med all sin ekstra rørleggerkode og vedvarende ressurser. Men på grunn av tidsbegrensninger og min iver etter å bygge en komponent av egen, gikk jeg videre med den første tjenesten.

Jeg valgte en stakk som bare var marginalt forskjellig fra den vi brukte for monolitten vår og begynte å bygge. Selve bygget gikk ganske raskt, og tok noen uker å produsere en frittstående applikasjon med et REST API. Først da begynte de virkelige utfordringene.

Jeg måtte få tjenesten til å snakke med monolitten. Det var på dette punktet at jeg lærte hvor tett sammenknyttet sesjonsadministrasjonen var med resten av koden. Det tok meg en stund å bryte ned eksisterende funksjonskall og oversette dem til API-kall. Dette var vanskelig. Ettersom sesjonstjenesten og monolitten hadde sine egne databaseskjemaer, måtte jeg skrive om all logikk i monolitten som brukte sesjonsressurser fra den gamle databasen, og omstrukturere dataene ved applikasjonsgrensen for å opprettholde kompatibilitet med klienter som vår javascript-plugin.

Å integrere tjenesten med våres eksisterende applikasjon tok lenger tid enn det tok å skrive selve tjenesten, og dette inkluderte ikke mye av den ekstra overheaden som mikrotjenester vanligvis medfører, som tjenesteoppdagelse, logging og overvåking. Videre, på grunn av tett sammenkobling, ble endringer foretatt på mange områder av koden. Da teamet hadde jobbet med ulike områder av koden parallelt i løpet av denne tiden, ville det kreve mye mer arbeid for å slå sammen endringene og få sesjonstjenesten i produksjon.

Tjenesten kan snart gå i produksjon, men jeg føler nå at jeg burde ha fulgt Newmans råd og lagt inn innsatsen min i å modulere vår eksisterende applikasjon. Fordelen med å ha én tjeneste som lever på egenhånd er marginal. Den reelle fordelen vil komme fra å dele opp hele greia, i det minste i grovt maskerte tjenester, som chatter så lite som mulig. Dette krever meget godt gjennomtenkte komponentgrenser, og vi er ikke helt der ennå.

Jeg er fortsatt solgt på ideen om mikrotjenester, og jeg ser mitt forsøk på å dele av en tjeneste som et vellykket eksperiment. Jeg lærte mye om applikasjonsarkitektur og domenemodellering i prosessen, og forbedret min forståelse av REST-prinsipper, blant annet. Disse har hatt en umiddelbar ringvirkning i andre områder av koden vår.

For lesere som ønsker å konvertere, ville jeg absolutt sørge for å lese så mye som mulig om emnet, og utsette arbeidet til du er veldig trygg med din eksisterende kodebase og din domenemodell. Det finnes andre måter å introdusere stabilitet og robusthet i en monolitisk applikasjon. Testdrevet utvikling og automatiserte enhetstester og funksjonstester hjelper mye. Horisontal skalerbarhet hjelper også med å gjøre utplasseringer litt jevnere.

Shoprocket vil fortsette sin reise mot mikrotjenester. Vi ser frem til å fortelle deg mer i del 2!