Cloud Nine förklarar headless: Mikrotjänstarkitektur och tankar om framtiden

I den sista delen av vår headless-serie tänkte jag förklara uttrycket mikrotjänstarkitektur, som ofta nämns tillsammans med headless, samt nämna några korta tankar kring framtiden inom dessa två områden. I tidigare inlägg kan du läsa om vad headless innebär och vad du behöver tänka på innan du sätter igång med din headless-lösning.

Mikrotjänstarkitektur

Headless har varit en trend länge, men lite parallellt med det så är även mikrotjänstarkitektur något det pratas mycket om och som används i stor utsträckning. Det här är ett begrepp som ofta nämns tillsammans med headless, då det ofta är en större användning av just det. Här tänker man sig att man inte bara har ett, utan många system som samverkar och varje system gör en specifik sak. Till exempel kanske man har ett headless-CMS såsom Contentful eller Prismic, en molnbaserad headless-e-handel via Storm eller något annat, man använder en annan tjänst för sina e-postutskick, en tjänst för central hantering av användare för tillgång till inloggade funktioner och så vidare. En tjänst kan vara antingen en färdig molntjänst, eller en egenutvecklad sådan. Målet är att de ska kunna samverka till helheten, som då är den webbplats man bygger. Fördelarna med headless finns förstås här också, men förstärks ytterligare, då tanken är att varje individuell tjänst ska vara utbytbar. Man brukar prata om att man kan jobba efter en "best of breed"-idé, där man helt enkelt kan välja de tjänster man tycker är bäst för specifika ändamål, och även byta ut tjänsterna den dag man hittar ett bättre alternativ (där "bättre" förstås kan vara högst subjektivt, även en sådan sak som kostnad kan förstås göra att en tjänst är bättre än en annan om de i övrigt är mycket lika).

En mikrotjänstarkitektur kan dock bli mycket komplex, inte minst då man sällan kan jobba med helt vattentäta skott mellan tjänsterna. Om det finns användare i en tjänst vars rättigheter ska kunna styras från en CMS-tjänst, krävs det någon form av integrationsarbete och det kan lätt bli ganska komplicerat. Då gäller det att ha tungan rätt i munnen för att systemen inte ska bli så hårt sammankopplade att man tappar fördelen med mikrotjänsterna. En annan sak man behöver tänka på är de som ska jobba i systemet. Är det samma personer som ska jobba med innehåll från tre olika tjänster? Kommer deras arbetsbörda bara bli större om man går den här vägen eller blir det en prydlig uppdelning, alternativt kan man hitta någon smart lösning?

Vägen framåt

Vad vi på Cloud Nine ser från både våra kunder och från den flora av plattformar för webbplatser vi försöker hålla koll på, så ser det fortfarande ut att bli mer och mer headless framöver. Vi har gått så långt att vi tycker att fördelarna är så stora i nästan alla projekt, att vi i princip alltid rekommenderar en headless-lösning om det inte finns någon väldigt bra anledning till annat. Vi tycker att bara det faktum att man kan utveckla siterna smidigt med React, att vi får en prydlig uppdelning i utvecklingsarbetet och att vi har mycket lättare att göra snabba förändringar på webbplatserna är tillräckligt för att vi ska vilja bygga headless.

Men fler fördelar finns, framförallt i projekt med många olika tjänster och kanaler. Framöver tror vi att det bara kommer att gå mer åt det hållet, och bli lättare ju fler plattformar som har ett headless-tänk. Framförallt sådana som har det i grunden. I takt med det så ser vi också att mikrotjänst-tänket kommer att bli ännu mer tillgängligt, med en uppsjö av olika smidiga tjänster som är redo att sys ihop, både med varandra och med specialutvecklade tjänster för det som inte kan täckas in av en produkt som man plockar ned från hyllan. Det kommer helt enkelt att bli lättare att sätta ihop en lösning där man inte behöver leva med att ens val av plattform inte är så bra på vissa saker, eftersom man kan välja det bästa och mest passande systemet för varje enskilt behov.

Vill du veta vad vi kan göra för dig? Hör av dig till oss på
08 120 330 00 eller skicka oss ett mail.

/Ronnie Hillgren, Systemutvecklare