MACH-økosystemet og Composable Commerce - hvad er nu det?

Der er ikke noget nyt i, at sige "monolitten er død", når snakken falder på it-arkitektur og ecommerce.

Laver man en Google-søgning på "monolithic architecture e-commerce", vil de første 10 resultater fortælle dig, at microservices er fremtiden, og at de store, tunge custom-built platforme, der førhen var standarden, er en døende race. 

I kølvandet på denne diskurs er MACH-principperne opstået som et modsvar til en rigid monolitisk arkitektur, der udfordrer forretningens ambitioner om vækst og agilitet.

MACH står for:

• Microservice-based
  • Microservices beskriver en it-arkitektur hvori så mange funktioner som muligt, er deres egne uafhængige services. I stedet for at have et enkelt system, der skal løfte ALLE opgaver (checkout, kurv, analytics, produkt-håndtering), brydes systemet ned i mindre services (microservices), der hver især udfører en specifik funktion
• API-first
  • Har man først sagt Microservices, har man næsten per automatik også sagt API-first. API'er (Applikation Programming Interface) tillader kort og godt, at dine systemer snakker sammen. Bygger I jeres applikation op af mange små services, vil det naturligvis være nødvendigt at disse kan udveksle data, og derfor vil API'er automatisk være en kritisk del af en MACH-konform løsning
• Cloud-native
  
  • Cloud-platformene hos Amazon, Microsoft, Google osv. tillader i dag administration af jeres løsning i skyen, hvilket giver langt mere computerkraft, øget sikkerhed mindre hardware at vedligeholde samt større skalérbarhed, når dine applikationer har behov for det. Derfor anses Cloud også for at være den foretrukne hosting-løsning for ambitiøse ecommerce platforme
• Headless
  
  • Når en løsning er Headless, er backend og frontend er skilt ad. Først og fremmest betyder det, at I får komplet frihed til at designe og udvikle jeres hjemmeside eller app, således at brugeroplevelsen bliver præcist som I vil have den. Dernæst betyder det også, at I får frihed til at bygge jeres backend med de komponenter, der passer jeres forretning bedst.

Hvert princip i MACH-konstruktionen understøtter ideen om et skalérbart og mindre omkostningstungt ecommerce setup, der ultimativt kan tilpasses til at møde morgendagens udfordringer.

Manifestationen af MACH-principperne er det, man i branchen kalder "Composable Commerce". Det vil sige komponentbaserede e-handelsløsninger, hvor hver enkelt funktion på platformen er sin egen microservice, der kommunikerer med "naboerne" vha. smarte API'er.

Der er ikke nogen ejer på MACH-principperne eller på Composable Commerce-begrebet. Vil man alligevel vide mere om MACH, er The MACH Alliance dog et godt sted at starte. Composable Commerce er møntet af Commercetools.

Og med den intro, er vi klar til at dykke dybere ned i, hvad MACH-principperne dækker over.

En Microservice-arkitektur dækker over applikationer, der er bygget af en række uafhængige services (microservices).

I sin rene form er hver enkelt microservice sin egen applikation, der understøtter en afgrænset funktionalitet (fx "kurv" på en webshop), og som kommunikerer vha. et API.

Hvorfor er microservices interessant?

Microservices-tankegangen bygger på et ønske om, at systemer kun skal udføre lige præcist de opgaver, vi beder dem om. Dermed er Microservices også et opgør med “monolit-tankegangen”, hvor alle funktioner samles i et enkelt system.

I en Microservice-arkitektur uddelegeres funktioner til individuelle komponenter, der er gensidigt uafhængige. I praksis afføder dette en række mindre-komplekse komponenter, der uafhængigt af hinanden kan opdateres og vedligeholdes. 

Således bliver logikken i hver komponent lettere at overskue, forbedre og styre. Det giver dig friheden til at arbejde på de komponenter, der understøtter de forretningsgange, der er mest kritiske her-og-nu, uden at hele systemet nødvendigvis skal tages i betragtning.

En Microservice-arkitektur giver følgende gevinster:

• Eliminerer risikoen for en "single point of failure"
• Afskaffer unønskede gensidige afhængigheder, der øger kompleksiteten af jeres system
• Afføder komponenter med overskuelige interne logikker, der let kan opdateres
• Øger muligheden for leverandørfrihed (du kan vælge "best-of-breed"-teknologier der, hvor dette giver mest mening økonomisk/funktionelt)
• Få en hurtigere time-to-market som følge af mere enkle vedligeholdelses og deployment-processer
• Større fokus på at understørre forretningen - ikke på at vedligeholde “deadweight”-teknologi.

Det er svært at forestille sig en velfungerende Microservice-arkitektur, der ikke er understøttet af gode API’er. Et API giver dine microservices mulighed for at kommunikere med hinanden, ved at udstille data i et ønsket format, på et ønsket tidspunkt.

Hermed kan alle individuelle services (fx i en Microservice-arkitektur) udveksle data, når jeres brugere benytter jeres tjenester.

Hvorfor er API first-tankgegangen relevant for din arkitektur?

Med MACH-principperne i baghovedet er en API-first tilgang en nødvendighed. Har man valgt at arbejde med en Microservice-arkitekturer, er det API’er, der lader dine services arbejde sammen.

API’er er ikke en ny opfindelse, men i takt med at ecommerce-løsninger i højere grad kommer til at bestå af små, uafhængige services, er vigtigheden af at have API’er som en top-prioritet i sin it-strategi en nødvendighed.

En API first-tankgegang giver følgende gevinster:

• Smarte API'er er et vilkår for en velfungerende it-arkitektur
• API'er kan genbruges til smart udveksling og anvendelse af data - også i fremtidige services
• Afskaffer unønskede gensidige afhængigheder, der øger kompleksiteten af jeres system
• "Tvinger" organisationen og udviklingsteamet til at kortlægge kommunikations- og arbejdsgange i systemet, så brugerens behov kan understøttes.

Når I bygger jeres løsning i skyen, er det typisk med henblik på at indfri de mange gevinster, en moderne Cloud-platform (fx Microsoft Azure, AWS eller Google Cloud) tilbyder.

Foruden at sikre jer de bedst mulige forudsætninger for skalering af jeres it-platform, kommer moderne cloud-platforme også med en række indbyggede værktøjer, der tillader automatisering af processer (opdateringer, backup mv.), analyse (AI) og eliminering af udgifter til opgradering og vedligeholdelse af hardware.

Set i lyset af de øvrige principper i MACH, kan ideen om udskiftelige komponenter, hurtige retningsskift mv. hurtigt bliver dyrt, hvis hardware konstant skal følge med behovet. Af den årsag er alene retfærdiggør skyen sin plads i et moderne it-setup.

Hvorfor være Cloud-native?

Hvor principperne om Microservice-arkitektur og API-first begge fokuserer på udvikling og software (development), relaterer Cloud-native princippet sig i højere grad til infrastruktur (operations).

“Skyen” buldrer frem, og både Google, Amazon og Microsoft har fuld fokus på at levere de bedste Cloud-platforme til enterprise-segmentet.

For jeres organisation betyder det mindre vedligehold, flere tilgængelige funktioner på SaaS-basis, mindre vedligehold (og dermed mere tid til udvikling og innovation) samt adgang til et skalérbart fundament for jeres commerce-stack.

Gevinster forbundet med en Cloud-hosted applikation:

• En Cloud-platform kan hjælpe med at automatisere jeres release-cycle og reducere omkostninger forbundet med deployment (fx hyppige opdateringer af microservices)
• De fleste moderne Cloud-platforme er spækket med værktøjer til administration af jeres Cloud-miljøer, hvilket reducerer jeres omkostninger forbundet med hosting og deployment
• En Cloud-platform kan skaleres op og ned efter behov, i modsætning til on-site hardware.

Et traditionelt CMS (Content Management System) består af to lag; backend (body) og frontend (head).

Backenden styrer typisk jeres content, mens frontenden håndterer visningen heraf (altså det grafiske interface jeres brugere møder).

Hvor det traditionelle CMS-system typisk håndterer begge lag, vil en Headless applikation derimod gøre det muligt at bruge et CMS (fx Umbraco) til backenden, imens frontenden kan bygges med valgfri teknologier.

Præcist som i microservice-tankegangen, kan I dermed bygge en samlet brugeroplevelse baseret på de teknologier, der giver bedst mening - og ikke dem, jeres foretrukne backend "tvinger" jer til at bruge.

Hvornår skal man arbejde med Headless?

Vi oplever at virksomheder, der gerne vil have let adgang til at tilføje og redigere content, uden at gå på kompromis med kreativ frihed i deres udgivelseskanaler, vælger Headless.

Dog øges kompleksiteten af den samlede platform også, hvilket gør Headless dyrere at komme i gang med, end en "Best of Suite"-platform.

En Headless applikation giver følgende fordele:

• Teknologi-agnostisk - I kan vælge de teknologier og frameworks der passer jer bedst
• Den modulare tilgang fremtidssikrer jeres applikation og arkitektur langt ud i fremtiden
• Hurtigere time-to-market grundet lavere omkostninger forbundet med videreudvikling af platformen

Som med så mange andre trends fylder snak ofte mere end praksis.

Når vi kigger på det faktiske ecommerce landskab er MACH-principperne ingen undtagelse. I hvert fald ikke, hvis vi kigger på antallet af platforme, der er 100% "MACH-compliant".

Det skyldes med stor sandsynlighed at "man jo skal starte et sted".

Mange virksomheder har vælger uden tvivl et mere beskedent/prisvenligt ecommerce setup, når de skal i gang med online handel.

Disse virksomheder risikerer, at deres første løsning ikke kan skalere til tidens behov. Hermed ikke sagt, at mange virksomheder er digitalt umodne - tiderne er ganske enkelt bare skiftet.

Enten kan virksomhederne så vælge at skifte hele platformen ud, eller undersøge muligheden for at skifte dele af platformen ud.

MACH-principperne som ledende stjerne

Når vi alligevel har brugt tid på at skrive om MACH-principperne skyldes det, at principperne er værdifulde at have in mente, når man i 2022 arbejder med digital strategi. 

Composable Commerce er et interessant begreb, der i bund og grund kan siges at være manifestationen af MACH-principperne.

Har man en microservice-arkitektur, tænker man API-first, er man i skyen og arbejder man i et headless-setup, så har man ret beset kastet sig over et "komponerbart ecommerce setup", og kan høste de mange fordele, vi har beskrevet herover.

God for de mange, perfekt for de få

En 100% compliance til MACH-principperne er ikke for alle. Alligevel er de gevinster, man kan høste ved at investere i fx Cloud til at få øje på. 

Derfor er det heller ikke gavnligt, at være MACH-purist. Værdiskabelsen i it-projekter findes altid i de tilfælde hvor teknologien kan tilpasses til forretningens behov. Og her vil en MACH/Best of Breed-løsning ofte være en omkostnings- og vedligeholdelsestung løsning som førstegangsinvestering.

Bruges principperne som benchmark i forbindelse med afklaringsfasen af et projekt, kan de fleste it-arkitekter spotte de oplagte muligheder for fx at arbejde med Headless, eller for at tænke på intelligent dataudveksling med API'er. Den modne virksomhed orienterer sig altid i markedet, når de investerer i ny teknologi. I 2022 vil MACH-principperne højest sandsynligt være en del af samtalen, og med rette.

I fremtiden, og i takt med at flere uafhængige udbydere af plug-and-play microservices til bl.a. ecommerce ser dagens lys, vil MACH-principperne og alle de tilhørende gevinster, være meget lettere at få glæde af for rigtig mange virksomheder. Vi holder løbende øje med udviklingen på området, så vi sammen med vores kunder kan finde de rigtige løsninger.