Een diepere kijk op hoe Drupal de 4 MACH principes toepast

Als we een stap terug zetten en naar de modulaire architectuur van Drupal kijken, zien we dat Drupal core inderdaad veel dingen doet en als monolithisch kan worden beschouwd. Drupal's core wordt echter steeds kleiner, waardoor meer en meer core modules naar contrib modules verschuiven. In Drupal 11 zal deze trend nog versnellen.

Hoewel core nog steeds veel doet, is het deze onderlinge afhankelijkheid van data, gebruikers en content die het mogelijk maakt om de meer ambitieuze multi-talen, landen, markten, kanalen, rollen, sites te bouwen... met meerdere integraties voor meerdere persona ervaringen. Aan de andere kant zijn er genoeg voorbeelden van DIY microservice hel, waar klanten externen moeten inhuren om al deze microservices te onderhouden, release management te doen, DevOps, en kennis te onderhouden van alle afzonderlijke services. Er worden veel risico's geïntroduceerd omwille van de snelheid. Dat is niet voor elke organisatie acceptabel. Monolieten worden vaak een grote bal slijk genoemd, microservice kunnen gemakkelijk een grote gedistribueerde bal slijk worden.

Een standaard in Drupal voor de interactie tussen modules en core zorgt voor stabiliteit en stelt de 1 miljoen leden tellende Drupal community in staat het 45k modules tellende ecosysteem van functionaliteit te onderhouden. Dus een beetje packaging en het creëren van waardevolle afhankelijkheden out of the box heeft veel waarde. Als klant geeft de mogelijkheid om je project naar een andere integrator te verplaatsen je ook veel vrijheid. Voor ontwikkelaars, wetende dat er standaarden zijn die het framework brengt, stelt het hen in staat om gemakkelijk projecten over te nemen, en dus minder nood aan helden die de dag redden. Deze herbruikbaarheid is de basis van contribution. Het is ook de basis van industrialisatie in een agency: in staat zijn om alle projecten op dezelfde manier te implementeren zorgt voor maximale onderhoudbaarheid.

De overgang van Drupal op automatische updates is een goede zaak. Het onderhoud van Drupal is ook nog nooit zo eenvoudig geweest. Ja, er is een zekere onderhoudskost aan Drupal en er is een niveau van complexiteit en afhankelijkheid aanwezig. Aan de andere kant is dit nodig om ambitieuze digitale ervaringen te bouwen en al die no-code/low-code kracht aan de sitebouwer te geven met behoud van de vrijheid van de ontwikkelaar.

Tenslotte is Drupal gebaseerd op Symfony, wat de mogelijkheid geeft om aangepaste onderdelen in de applicatie te ontwikkelen door bestaande code te overschrijven. Dit verhoogt de flexibiliteit waar nodig.

Ik geloof dat Drupal een goed evenwicht vindt tussen microservice en monoliet. Core brengt waarde in de zin dat er veel keuzes zijn gemaakt door 20 jaar evolutie. Microservice zijn of niet is niet de vraag. Het is hoe je het balanceert en er waarde mee creëert, dat is de vraag.

Drupal is niet cloud-native, maar bedrijven als aacquia.com, pantheon.io, platform.sh en dropsolid.io helpen je om Drupal in de cloud te draaien. Drupal ondersteunt evenementen zoals de Olympische Spelen, wat betekent dat het behoorlijk schaalbaar is. Is cloud-native ook hier een verkoopargument? Nee, het gaat erom hoe je waarde uit de cloud haalt. Gebruik de cloud waar nodig. Omdat Drupal open is, kun je Drupal ook op je eigen locatie draaien als je datasoevereiniteit wilt garanderen. Bedrijven als amazee.io en dropsolid.io helpen je daarbij.

Laat delen van je stack in de cloud lopen of gebruik cloud services waar dat zinvol is. De cloud kan je ook vastzetten en je kosten uit de hand doen lopen. Door een gevoel van openheid te behouden en je stack te kunnen verplaatsen, houd je een gezonde druk op cloudleveranciers en serviceproviders om de kosten onder controle te houden.

Ook hier geldt: to cloud or not to cloud is niet de vraag. Gebruik het waar het waarde voor u creëert, terwijl u uw soevereiniteit behoudt.