Composable architecture versus Mach: de overeenkomsten, verschillen en toegevoegde waarde voor platformontwikkeling

10 min read

Heb je wel eens een verkenningstocht gemaakt in de wereld van de moderne applicatie- en platformontwikkeling? Dan is de kans groot dat de termen MACH en composable architecture een belletje doen rinkelen. Maar wat houden ze precies in? Wat zijn de belangrijkste overeenkomsten en verschillen tussen de twee werkwijzen? En wat is de toegevoegde waarde van MACH en composable architecture voor platformontwikkeling? Je leest het in dit artikel.

Composable architecture versus MACH

MACH: wat is het?

MACH staat voor microservices, API, cloud-native en headless en is een bundeling van deze vier architectuurprincipes. Het is een werkwijze die we bij Oberon al een tijdlang gebruiken om platformen te bouwen.

Headless is inmiddels al jaren dé standaard in de wereld van platformontwikkeling. Het kwam voort uit de wens om, mede ingegeven door de stormachtige opkomst van mobiele apparaten en toepassingen, een ‘app-gevoel’ op het web te creëren. Een hoge mate van interactie en snel kunnen navigeren zonder de pagina te verlaten zijn belangrijke en kenmerkende eigenschappen van dergelijke webplatforms. Bij headless platforms ontwikkelen specialisten de front- en backend apart van elkaar en zijn deze twee elementen niet meer met elkaar verweven.

API-first houdt in dat je ervoor kiest om alle delen van je architectuur via Application Programming Interfaces (API’s) met elkaar te laten communiceren. In die API’s staat heel strak gedefinieerd welke functionaliteiten een (micro)service ter beschikking stelt en welke data daar precies voor nodig zijn.

Microservices gaat over het opsplitsen van je software in meerdere kleinere stukken. Bij microservices ontwikkel en deploy je onderdelen van een platform los van elkaar. Een microservice draait in feite als een aparte applicatie en kun je dus individueel schalen, optimaliseren, verbeteren of zelfs compleet vervangen. De verschillende microservices communiceren met elkaar door middel van API’s (meestal JSON, eventueel in combinatie met GraphQL). Het wordt zo veel makkelijker om individuele onderdelen en diensten binnen een platform aan te passen zonder dat de functionaliteit van het geheel eronder lijdt. Benieuwd naar alle voor en nadelen van microservices en hoe je ze het beste kan inzetten? In ons artikel over Microservices lees je hier meer over.

Cloud-native betekent dat je software ontwerpt en bouwt die specifiek bedoeld is om in de cloud te draaien. Bij Oberon maken we gebruik van cloudservices en richten we onze architectuur cloud-native in. We richten ons daarbij vooral op AWS.

De toegevoegde waarde van MACH voor platformontwikkeling

MACH biedt op verschillende vlakken toegevoegde waarde bij het ontwikkelen van platformen. Hieronder een uiteenzetting.

Betere performance door headless

Headless levert een significante bijdrage aan een betere performance, vooral omdat de losse frontend de backend ontlast en in de browser snel reageert op gebruikersinteracties. Zonder headless moet je vaker wachten tot de server een nieuwe pagina genereert. Deze verbetering biedt direct opties voor schaalbaarheid, omdat de frontend overbelasting van de backend kan voorkomen, bijvoorbeeld middels static site generation (SSG). Hierbij genereert het platform of de website pagina’s eenmalig met data uit de backend.

Meer schaalbaarheid door de cloud

De cloud biedt schaalbaarheid in de kern. Je gebruikt niet meer specifiek een (virtual) server met harde limieten. In de cloud kun je softwarematig meer resources (CPU, memory, storage) bijschalen. Veel services zijn zelfs elastic, waardoor ze virtueel geen limieten hebben: de cloud geeft zijn resources ter beschikking, zoveel als je nodig hebt. Hierdoor blijft je platform toekomstbestendig als het aantal gebruikers van je platform groeit.

Meer beheersbaarheid en flexibiliteit met microservices en API's

Microservices vergroten vaak de beheersbaarheid van je platform. Je hebt niet langer één grote codebase waarin alles gebeurt (de klassieke monoliet), maar duidelijk afgebakende microservices die met elkaar communiceren via API's. Je kunt naar hartelust sleutelen aan de afzonderlijke microservices en ze los van elkaar deployen.

Een hele belangrijke reden om te kiezen voor meer of minder microservices is je development team en je doelen in ontwikkelsnelheid: wil je snel ontwikkelen met veel developers, dan maak je meerdere development teams en deel je je software op in verschillende microservices, zodat elk team parallel aan elkaar kan ontwikkelen zonder elkaar in de weg te zitten.

Dit heeft wel een keerzijde: een overdaad aan microservices kan de complexiteit van je platform verhogen. Er zijn meer services die je in de cloud moet draaien en monitoren, er zijn meer plekken waar iets fout kan gaan (communicatie tussen services) en meer services die je up-to-date moet houden (software-updates).

Een voordeel is wel weer dat microservices de schaalbaarheid en performance vaak verbeteren. Belasting op drukke onderdelen van het platform treffen vaak een specifieke microservice zonder dat het de andere microservices en de werking van het platform als geheel beïnvloedt. Dit is een groot verschil met een monoliet, waarbij het hele systeem hinder ondervindt van de overbelasting van een of enkele platformonderdelen.

Composable architecture: wat is het?

Een composable architecture is primair gericht op hergebruik. Je splitst bepaalde onderdelen van een platform op in zogenoemde packaged business capabilities (PBC’s). Je kijkt hierbij naar de verschillende businessonderdelen in je platform. Een goed en populair voorbeeld is contentmanagement. Het beheren van content is een business capability en kun je los zien van andere business capabilities (zoals user management, e-commerce, customer service of search indexing) van het platform.

Een CMS is daarom een PBC: een afgebakend stuk software dat een specifiek onderdeel van je onderneming dient. Zulke business capabilities zijn vaak niet uniek voor een bepaald platform (of een bepaalde business). Heel veel platformen hebben bijvoorbeeld contentmanagement nodig. Er zijn inmiddels veel herbruikbare PBC’s te vinden, vaak in de vorm van SaaS-oplossingen. Hierdoor kun je een platform bouwen door het naar eigen inzicht samen te stellen (‘composen’) uit bestaande PBC’s. Vaak is het wel nodig om een deel van de PCB’s als maatwerk voor het specifieke platform te bouwen. In een composable architecture heb je daarom geregeld een of meerdere ‘custom PBC’s’. Die combineer je moeiteloos met herbruikbare PBC’s, zoals bestaande SaaS-oplossingen.

De toegevoegde waarde van composable voor platformontwikkeling

Omdat je PCB’s naar eigen inzicht en behoefte vervangt, toevoegt of verwijdert, kun je een platform flexibel maken en nauwkeurig sturen op de ontwikkelkosten. Daarom biedt composable vaak betere oplossingen dan alles zelf bouwen, vooral omdat je een best-of-breed-oplossing kiest voor verschillende onderdelen van je platform: een herbruikbare PBC is doorgaans al ver doorontwikkeld en heel goed in zijn specifieke taak.

Maar over het algemeen zul je ook geregeld genoegen moeten nemen met oplossingen die minder specifiek aansluiten op jouw wensen. Je zult ook merken dat je verschillende data op verschillende plekken moet beheren. Waar je voorheen misschien een adminpanel had waar alles in te beheren was, zul je bij composable veelal naar de juiste PBC moeten om de gewenste acties uit te voeren.

Composable

Mach en composable: de belangrijkste verschillen

MACH en composable zijn niet zozeer twee radicaal verschillende benaderingen waar je uit moet kiezen. Composable legt een sterkere nadruk op het in kaart brengen van de business capabilities van je platform en zoekt daar zoveel mogelijk herbruikbare oplossingen bij die fungeren als aparte services in je architectuur. Een PBC kan een op zichzelf staande microservice zijn of juist uit meerdere microservices bestaan. Een PBC herbergt aan de binnenkant vaak een MACH-architectuur.

MACH focust meer op de technische implementatie en heeft als belangrijkste doel om de schaalbaarheid, performance en beheersbaarheid van een platform te verbeteren. MACH is ook een vrij technische manier om naar platformontwikkeling te kijken, terwijl composable nog net wat sterker de klant en zijn business als belangrijkste leidraad neemt.

Meer weten?

Wil je meer weten over MACH en composable architecture? En ben je benieuwd hoe beide werkwijzen jou van dienst kunnen zijn bij het bouwen van mooie, functionele en toekomstbestendige platformen? Dan helpt Oberon je graag verder. Neem gerust vrijblijvend contact met ons op zodat we samen de mogelijkheden kunnen verkennen!

Meer weten over MACH en composable architecture?