Jamstack, MACH, headless, mikropalvelut – mitä!?mitä?!

Drupalin isä Dries Buytaert kirjoitti hiljattain omia näkemyksiään tästä sekamelskasta. Artikkelissa hän havainnoi etenkin uusimpien trenditeknologioiden kehittymistä kohti perinteisiä CMS-ratkaisuja. Uudet mallit ovat toki tuoneet uusia lähestymisiä ja tapoja alalle, mutta samalla kypsyessään, ne kohtaavat samoja haasteita kuin perinteisemmät CMS-ratkaisut, ja samalla nämä uudet pelurit alkavat muistuttaa yhä enemmän vanhoja pelureita.

Lue koko artikkeli: The new old: Jamstack and MACH’s journey towards traditional CMS concepts

Buytaert ei toki missään tapauksessa ole mikään neutraali havainnoija, koska Drupal ja Acquia ovat isoja pelureita tässä samassa ankkalammikossa. Moni kuitenkin arvostaa Buytaerttia myös laajemmin web-teknologioita ymmärtävänä asiantuntijana, joka on esimerkiksi vuosittaisissa Drupal-konferensseissa usein ottanut esille teemoja, jotka eivät välttämättä ole olleet mieluisia tai edes yhteensopivia Drupal-yhteisön sen hetkisen ajattelun kanssa. Täten Buytaerttia voinee kuvailla aika itsenäiseksi ajattelijaksi webin teknologioiden saralla, vaikka Drupalin luojana hänellä toki on oma historiansa näkemyksiensä takana.

Buytaert nostaa esiin muun muassa Jamstackin muuntumisen yhä enemmän perinteisempien CMS-ratkaisujen suuntaan.

”Jamstack, born in 2015, began as an approach for building static sites. The term Jamstack stands for JavaScript, APIs and Markup. Jamstack is an architectural approach that decouples the web experience layer from content and business logic. The web experience layer is often pre-rendered as static pages (markup), served via a Content Delivery Network (CDN).

By 2023, the Jamstack community underwent a considerable transformation. It evolved significantly from its roots, increasingly integrating traditional CMS features, such as “content previews”. This shift is driven by the need to handle more complex websites and to make the Jamstack more user-friendly for marketers, moving beyond its developer-centric origins.

Netlify, a leader in the Jamstack community, has acknowledged this shift. As part of that, they are publicly moving away from the term “Jamstack” towards being a “composable web platform”.”

Viime vuosien headless-buumissa onkin ehkä kiinnostavinta ollut se, miten sen termin varjolla on lähdetty usein vaihtamaan kaikki mahdolliset tekniset komponentit.

Näin siitäkin huolimatta, että isoin muutos on koskenut nimenomaan pinnan, eli frontin, rakentamistapaa.

Syystä tai toisesta, on hyvin usein päätetty vaihtaa myös taustalla oleva CMS- tai verkkokaupparatkaisu johonkin trendikkäämpään vaihtoehtoon. Joskus samaan soppaan on yhdistetty tarve vaihtaa myös rajapintakerros uudempaan, jollain tavalla modernimpaan ratkaisuun. Lopputulos onkin usein ollut monikerroksinen ja aika monimutkainen arkkitehtuuri, vaikka lähtökohtana on saattanut olla vain “parempi fronttikerros”, mutta jotenkin vain paketissa on tullut mukana muutakin.

Tämä lienee yksi syy siihen, miksi on syntynyt jonkin verran vastakkainasettelua ”uuden” ja ”vanhan” maailman välille.

”Modern CMSes integrate well with various JavaScript frameworks, have GraphQL backends, can render static pages, and much more.

This combination of both methods is known as “hybrid”. Most traditional CMSes have adopted this hybrid approach. For example, Drupal has championed a headless approach for over a decade, predating both the terms “Jamstack” and “Headless”.

Asserting that traditional CMSes are “monolithic” and “outdated” is a narrow-minded view held by people who have overlooked their evolution. In reality, today’s choice is between a purely Headless or a Hybrid CMS.”

Tästä vastakkainasettelusta ollaan toki tultu jo pitkälti pois. Nykyisin moni headless-mallia edustava toimistokin tarjoaa sisällönhallintaan herkästi WordPressiä. Drupal-maailmassa tämä on tietysti ollut lähtökohta jo pitkään – eli vaikka headless olisi ehdotettu malli, tarjotaan taustalle kuitenkin Drupalia.

Yhä useampi toimisto myös ymmärtää nykyisin, että samassa ratkaisussa voi olla erilaisia osioita. Asiointiprosessit voidaan rakentaa headless-ajattelulla, ja silti perinteisemmät sivupohjaiset osiot voivat hyödyntää julkaisujärjestelmän tarjoamaa esityskerrosta, jolloin myös markkinointi-ihmiset voivat muokata osioita varsin monipuolisesti. Yhä enemmän on myös asiakkaita, joilla voi olla headless-mallia käytössä asiakkaiden extranet-ratkaisussa, Drupal pääsivuston ratkaisuna ja WordPress pienempien markkinoiden sivustojen web-alustana. Ja vaikka näiden kehityksessä olisi kaikissa eri kumppanit, ei se ole ongelma välttämättä käytännössä, joskus se voi olla jopa vahvuus.

Toinen viime vuosien teknologiatrendi on ollut MACH-ajattelu, jolla yleensä viitataan eräänlaiseen äärimmäiseen palasista koostamiseen. Suomessa tämä MACH-termi ei ole kovin laajalti saanut tulta alleen. Suomessa ehkä mikropalveluista ja niihin liittyvistä arkkitehtuurimalleista puhuminen on ollut tyypillisempi tämän trendin ilmentymä. Keskeinen erohan on lähinnä vain se, että MACH-ajattelussa eri palaset ovat usein jonkinlaisia valmiita palveluna ostettavia ohjelmistotuotteita, eivät suinkaan räätälinä tehtyjä komponentteja (mutta voivat olla näitäkin).

”Many readers, especially people in the Drupal community, might be unaware of MACH. MACH is an acronym for Microservices, API-first, Cloud-native SaaS, Headless. It specifies an architectural approach where each business function is a distinct cloud service, often created and maintained by separate vendors and integrated by the end user.

Imagine creating an online store with MACH certified solutions: you’d use different cloud services for each aspect – one for handling payments, another for your product catalog, and so on. A key architectural concept of MACH is that each of these services can be developed, deployed, and managed independently.”

Kuten todettua, tämä pienistä palasista koostaminen ei ole Suomessa saanut valtavaa suosiota, vaikka moni toimisto puhuukin modulaarisuudesta ja edellä mainituista mikropalveluarkkitehtuureista. Suomessa yleensä hyväksytään ajatus siitä, että useimmissa kokonaisuuksissa on jokin ydinjärjestelmä, eikä sellaisen olemassaolo ole mitenkään huono asia. MACH-ajattelussahan on vahvana se, että minkäänlaista ydinjärjestelmää ei saisi olla, vaan kaikki komponentit tulisi olla mahdollisimman itsenäisiä ja vaihdettavia.

”More importantly, what is often overlooked is the vital role a core platform plays in maintaining a consistent user experience, centralized account management, handling integration compatibility and upgrades, streamlining translation and content workflows across integrations, and more. The core platform essentially offers “shared services” aimed to help improve the end user and developer experience. Without a core platform, there can be increased development and maintenance costs, a fragmented user experience, and significant challenges in composability.

This aligns with a phenomenon that I call “MACH fatigue”. Increasingly, organizations come to terms with the expenses of developing and maintaining a MACH-based system. Moreover, end-users often face a fragmented user experience. Instead of a seamlessly integrated interface, they often have to navigate multiple disconnected systems to complete their tasks.”

Mikropalveluarkkitehtuurienkin saralla on usein törmätty tähän ilmiöön, jossa eri komponenttien keskinäiset riippuvuudet alkavat olla niin merkittäviä, että muutoksien tekeminen järjestelmään tulee haastavaksi juuri näistä riippuvuuksista johtuen. Jos toisiinsa liittyvät asiat pilkotaan väkisin itsenäisiksi kokonaisuuksiksi, voi jatkokehittäminen olla työlästä ja hidasta, vaikka arkkitehtuurillisesti olisikin saavutettu kaunis kokonaisuus.

Usein erittäin modulaarisesti asioiden ratkaiseminen johtaa myös maailmaan, jossa eri osien käyttöliittymät ovat erilaisia. Ja vaikka asiakkaille käyttöliittymät yhtenäistettäisiin kovalla työllä ja design-systeemin avulla, ovat ylläpitäjien ja liiketoimintaihmisten käyttöliittymät yleensä hyvin kirjavat, kun jokaisella osakomponentilla on omat käyttöliittymänsä ja omat kehitystiiminsä.

Ei olekaan automaattisesti selvää, että minkäänlainen mikropalveluarkkitehtuuri olisi jotenkin ydinjärjestelmään nojaavaa arkkitehtuurimallia parempi – ja usein käytännössä kannattaa valita jotain näiden ulottuvuuksien välistä. Modulaarinen ajattelu on ilman muuta hyvä asia, ja yleensä sitä parempi, mitä laajemmista ja monimutkaisemmista järjestelmistä on kyse. Missä raja menee milloinkin, on sitten jo paljon vaikeampi kysymys.

Julkaisujärjestelmien ja verkkokauppa-alustojen kohdalla on toki jo todettu eri yhteyksissä, että räätälinä rakentaminen ja jonkinlainen headless-lähestyminen on yleensä huomattavasti tuotepohjaista rakentamista kalliimpaa. Myös MACH-ajattelun ytimessä oleva erilaisten saas-palveluiden kytkeminen toisiinsa rajapintojen avulla on usein monimutkaisempaa kuin miltä se vaikuttaa myyntikalvoilla.

Nyrkkisääntönä voinee pitää, että jos oma budjetti on ”vain” 200 000 euroa tai vähemmän, ei yleensä kannata flirttailla näiden eksoottisempien kirjainyhdistelmien ja mikroarkkitehtuurimallien kanssa. Jos taas homma pyörii omalla tiimillä ohjelmistokehittäjiä, käyttäjiä on digipalveluilla päivittäin kymmeniä tuhansia ja liiketoiminta huutaa jatkuvasti villejä uusia ominaisuuksia, kannattaa ehkä perehtyä näihin modulaarisiin arkkitehtuurimalleihin vähän tarkemmin.

Ja jotta asiat eivät olisi liian selkeitä, on ilman muuta nähtävissä myös näiden eri alueiden lähentyminen. Kaikki headless CMS:t eivät ole enää hankalia käyttää, osa jopa pystyy esikatseluihin ja visuaaliseen sivuasetteluun. Ja samalla WordPress ja Drupal ja kumppanit tarjoavat yhä paremmat rajapinnat ja kyvykkyydet toimia erilaisten räätälöityjen käyttöliittymien taustajärjestelminä.

Esimerkiksi, vaikka asiakkaana olisi päättänyt mennä headless-malliin, ei se välttämättä enää tarkoita, että taustalla olevan CMS-ratkaisun pitää myös olla viime vuonna perustetun startup-firman tekemä. Ehkä tällaista ehdotusta jopa kannattaisi asiakkaana kyseenalaistaa, jos sellainen vielä joltakin toimittajalta tulee vastaan.

”In recent years, we’ve witnessed a variety of technical approaches in the CMS/DXP landscape, with MACH, Jamstack, decoupled, and headless architectures each carving out their paths.

Initially, these paths appeared to diverge. However, we’re now seeing a trend of convergence, where different systems are learning from each other and integrating their unique strengths.

The Jamstack is evolving beyond its original focus on static site generation into a more dynamic and complex approach, narrowing the gap with traditional CMSes.”

Yksi asia on nimittäin selvää. ”Uusi teknologia” ja ”vanha teknologia” ovat ohjelmistoalalla yhä enemmän verbaalisia lyömäaseita, joita käytetään, kun halutaan haukkua jotain kilpailevaa ratkaisua. Todellisuuden kanssa näillä ei usein ole mitään tekemistä, etenkin jos uutta teknologiaa ajatellaan jotenkin automaattisesti parempana teknologiana. Tämän ovat tämänkin alan headless- ja jamstack ja muut seikkailut hyvin todistaneet. Se, että keksitään pyörä uudestaan hieman uudenlaisella rakenteella ja kuorrutuksella, ei välttämättä johda asiakkaiden ongelmienratkaisun kannalta parempaan lopputulokseen.

Mutta jostain uudet teknologiat aina kumpuavat, ja yleensä taustalla on ainakin joitakin hyviä syitä. Asiakkaana kannattaa kuitenkin olla tarkkana, onko uuden teknologian tai arkkitehtuurin taustalla vain parempi “kehittäjäkokemus” järjestelmän rakentavalle ohjelmistokehitystiimille, vai onko taustalla myös asioita, jotka johtavat loppukäyttäjien kannalta parempaan maailmaan ja asiakkaalle helpommin ja nopeammin jatkokehitettävään ratkaisuun.

Viime vuosien trendit ovat olleet vauhdikkaita, eikä läheskään kaikkien näiden takana ole ollut loppukäyttäjille tarjottavat parannukset, vaan varsin usein on ollut kysymys ohjelmistokehittäjien tarpeesta luoda itselleen parempia työkaluja ja kehitysympäristöjä. Asiakkaana kannattaa tunnistaa, milloin on kyse mistäkin, ja kuinka merkityksellinen ohjelmistokehittäjien kokemus on oman liiketoiminnan kannalta.

Joskus tästä paremmasta kehittäjäkokemuksesta ja modulaarisuudesta kannattaa maksaa, mutta aina kannattaisi pyrkiä tekemään päätökset tietoisena siitä, mitä on valitsemassa, ja mitkä ovat tämän valinnan vahvuudet ja heikkoudet.

Lue lisää: Web-sovellukset ja näiden tekniikat – kaikki artikkelit Vierityspalkissa