Adjöken CMS-monolit!

12 september 2019

Minns ni när ett CMS var en allt-i-ett lösning? I CMS-projektet, både strukturellt och i kod, fanns allt; integrationer, språkhantering, tredjepartskomponenter och mycket annat. Inte sällan fanns integrationer till affärskritiska system som gjorde att inget fungerade om inte alla komponenter var online.

Kanske gjorde det inte så stor skillnad i den vattenfallsvärld vi jobbade i då, men ändå var vi tvungna att till exempel göra en release av hela kodbasen för att rätta en bugg eller ändra en parameter i kod. Beroenden fanns överallt. Knappast var detta i linje med SOLID-principernas “Single responsibility principle” som kanske fungerade i kod men knappast arkitekturellt.

Kortsiktiga lösningar ledde till dyr förvaltning

Eftersom CMS:et fungerade som nav för allt inkommande på webbplatsen fungerade den såklart också för allt som kom ut, även sådant som inte skulle visas på webbplatsen utan användas på andra ställen som en del i en omnikanalstrategi. Upplägget gynnade konsultbyråerna och CMS-leverantörernas licensförsäljning, om än kortsiktigt. Då alla beroenden var komplexa och svåra att bryta ut blev uppdateringarna få, förvaltningen dyr och man landade ofta i att bygga en helt ny webbplats efter tre-fyra år. Någon som känner igen scenariot?

 

CMS-monolit 

Modern arkitektur råder bot på monolit-problematiken 

Kanske är det lätt att bli raljant, men många leveranser såg ut så här för bara några år sedan. Däremot fanns det då inte samma förutsättningar tekniskt och infrastrukturmässigt som det gör idag med till exempel Azure, AWS och GCP. Container-utvecklingen de senaste åren har också inneburit stora möjligheter för att råda bot på monolit-problematiken. Genom att separera funktionalitet, integrationer, separera back-end och front-end, använda API Management och modern mikroservice-arkitektur blir monoliten ett minne blott. Behovet av ett CMS minskar rejält och fokus flyttar från själva CMS:et till hur arkitekturen är uppbyggd.

 

I en ren tjänstebaserad arkitektur blir då CMS:et en av alla andra tjänster. En pragmatisk och sund utveckling, med minskade beroenden. Skillnaden blir påtaglig över tid. Skalbarhet, utbytbarhet, snabba releaser och mycket mer fås på köpet med en liknande arkitektur.

 

CMS in Micro Service Architecture

Även om detta är ett exempel går det att använda tänket på olika sätt beroende på förutsättningar och behov. Trenden är ändå tydlig. CMS:ets betydelse i en större arkitektur blir mindre för det fokuserar på det CMS:et faktiskt ska göra – hantera content.

Automatisering snabbar upp utvecklingen

Fokus kan idag läggas på att bygga bra tjänster och API:er som inte behöver vara i samma programmeringsspråk, eller plattform för den delen, utan kan snurra helt fritt, bara den fungerar i arkitekturen. Nu kan alla tjänster och lager releasas var för sig, när som helst. Med en hög grad av automatiserade tester och bra utförd devops-implementation kan tjänster distribueras automatiskt när de är ändrade istället för att vänta på “den stora releasen”. 

 

Summan är att ett agilt arbetssätt med en mikrotjänstbaserad arkitektur blir en väldigt bra kombination gällande digitala lösningar. Användandet av containers och automatisering snabbar upp utvecklingen samtidigt som utvecklarna kan fokusera på att bygga så mycket värde som möjligt, vilket borde vara varje teams mål.

 

Av: Andreas Thente, Forefront Consulting

Nästa nyhet

Intryck från Google Cloud Summit 2019

11 september 2019