Nu weten we hoe een Headless Architecture uw Front-End flexibeler, schaalbaarder en gemakkelijker te onderhouden maakt. Wat als we ditzelfde principe toepassen op Back-End systemen?

Wat als we Back-End processen definiëren als afzonderlijke diensten, bijvoorbeeld orderbeheer, voorraadbeheer, assortimentsbeheer, logistieke diensten, betalingsdiensten, en meer - en ze allemaal ontkoppeld van elkaar bouwen? In dit geval bouwen we een gedecentraliseerd systeem... een servicegerichte architectuur. Een dergelijke architectuur brengt flexibiliteit, uitbreidbaarheid, schaalbaarheid en betrouwbaarheid voor zowel Front-End als Back-End processen - de ingrediënten die nodig zijn om een robuust, maar lichtgewicht bedrijfssysteem te bouwen dat klaar is om elk bedrijf te versnellen.

Dienstgerichte architecturen en middleware

De Service-Oriented Architecture heeft een aanzienlijke invloed op de relatie tussen de verschillende systemen en de database. In plaats van één databaseschema te delen met andere diensten, heeft elke dienst zijn eigen databaseschema. Het hebben van een databaseschema per dienst is essentieel als je optimaal wilt profiteren, omdat het zorgt voor losse koppeling. Bovendien kan een dienst een type database gebruiken dat het beste past bij zijn behoeften (ook wel polyglot persistence architecture genoemd).

Dus hoe werkt dat? Met al deze systemen apart en gedecentraliseerd, waar wisselen we dan gegevens uit? En hoe zorgen we ervoor dat de gegevens schoon zijn, dat er geen dubbele gegevens bestaan en dat de gegevens slechts "één bron van waarheid" kennen?

We zouden allemaal aparte API's per dienst kunnen bouwen en in elke dienst bijhouden waar de gegevens naartoe moeten (en wat het werkelijke punt van de gegevens is). Maar met veel gegevensstromen, complexe individuele diensten en snelgroeiende bedrijven die snel functionaliteiten willen uitbreiden, zou dit rommelig en zeer complex kunnen worden.

Daarom gebruiken we in een echte Service-Oriented Architecture een Middleware. Deze (slimme) Middleware verbindt alle punten tussen de systemen en diensten. Hij regelt waar de gegevens vandaan komen, waar ze naartoe moeten, en waar de echte bron van de gegevens is. Processen die we in Middleware kunnen vinden zijn authenticatie handlers en messaging systemen.

In een traditionele SOA zouden we een Service Orchestrator en ETL-tool (Extract, Transform, Load) gebruiken om onze gegevens toegankelijk, zinvol en bruikbaar te maken voor verschillende datasystemen. In modernere technologiestacks kunnen we hiervoor GraphQL met een API gebruiken.

Voordelen van servicegeoriënteerde architecturen

Het bouwen van een dergelijke architectuur geeft u de (Front-End) voordelen van een Headless Architecture en brengt dezelfde schaalbaarheid, flexibiliteit, uitbreidbaarheid, prestaties, enz. naar de Back-End processen. Men zou kunnen zeggen dat een "Headless Architecture" een "lichte" of "vroege" versie is van een Service-Oriented Architecture.

Een servicegerichte architectuur pakt het probleem van de complexiteit van monolieten aan door de monoliet te ontleden in een reeks beheersbare diensten. Deze zijn veel sneller te ontwikkelen, veel gemakkelijker te begrijpen, veel gemakkelijker te onderhouden, en veel flexibeler. U kunt gemakkelijker en veel sneller aanpassen, uitbreiden en doen wat uw bedrijf nodig heeft.

Aangezien elke dienst een op zichzelf staande applicatie is, kan hij als zodanig worden ontwikkeld, onderhouden en ingezet. Dit maakt onafhankelijke (externe) teams, continue inzet, probleemloze uitbreidbaarheid en onbeperkte schaalbaarheid per dienst mogelijk.

De invoering van nieuwe technologieën verloopt veel sneller, en ontwikkelaars kunnen voor elke dienst de juiste technologie kiezen en zijn niet gebonden aan de (legacy) technologie die bij het begin van het project werd gekozen.

Als laatste, maar zeker niet de minste. Het is het vermelden waard dat er, specifiek voor eCommerce, veel diensten op de markt zijn die bepaalde taken perfect uitvoeren. We kennen allemaal diensten als Algolia voor search, PayPal voor betalingen, Akaneo voor het beheer van productinformatie, WordPress voor content, enz. Met zoveel geweldige tools die er zijn, zou het zonde zijn (en onnodig complex) om elke dienst zelf opnieuw te bouwen. In een Service-Oriented Architecture kunt u elke bestaande dienst koppelen aan uw Middleware en zo de beste set tools voor uw bedrijf samenstellen, en uw landschap aanvullen met op maat gemaakte diensten waar dat nodig is.

Door het gebruik van Middleware en een Service-Oriented Architecture krijgt u volledige vrijheid in wat u gebruikt, hoe u uw bedrijf opbouwt, en wat u daarna wilt doen. Geen enkele keuze zal u jarenlang binden of enorm veel tijd kosten. Uw bedrijf wordt flexibel, schaalbaar en kan zich net zo snel aanpassen als de markt verandert.