Stef De Waele
Dit artikel beantwoordt de vraag welke lokale ontwikkeloplossing wij gebruiken bij Calibrate en waarom deze oplossing lokal.host heet. In een aantal stappen bekijken we de criteria waaraan een lokale ontwikkelingsoplossing moet voldoen en welke oplossingen reeds bestaan. We maken onze keuze en beargumenteren waarom deze oplossing voor ons de beste is.
Een eerste criterium dat we hanteren is de ondersteuning van host platformen. Daarmee bedoelen we of de oplossing op ieder zijn favoriet besturingssysteem werkt. Web development gebeurt gangbaar op Mac of Linux. In de zeer recente geschiedenis verschijnen er ook steeds meer ontwikkelaars die op Windows willen werken.
Als tweede criterium bekijken we controle en compatibiliteit. Als (doorwinterde) ontwikkelaar wil je alle controle over je lokale ontwikkelingsoplossing. Het is immers zeer belangrijk nieuwe features of enige fouten zo correct mogelijk te testen of onderzoeken. Door lokaal te finetunen om zo dicht mogelijk bij de productie-omgeving aan leunen vermijd je ook een heleboel potentiële problemen.
Het derde criterium is flexibiliteit. In het huidig IT-landschap is er een zeer ruim aanbod aan technologieën waar je gebruik van wil maken. De versies van die technologieën volgen elkaar steeds sneller op. Als ontwikkelaar wil je zeer snel kunnen switchen tussen al deze mogelijkheden. Dit is ook zeer belangrijk voor agencies die langdurige support aanbieden omdat ze snel moeten kunnen schakelen tussen bestaande websites.
Als laatste factor hebben we ontwikkel snelheid. Eenmaal je website lokaal draait wil je dat bij het bezoeken van die website het geen tientallen seconden lang duurt voor je webpagina geladen is. Ook het uitvoeren van commando’s in je terminalvenster is idealiter beperkt in duurtijd. Om de simpele dat deze duurtijd recht evenredig is met de doorlooptijd van een website.
Om de volledige waaier aan bestaande oplossingen te overwegen verdelen we deze eerst in drie groepen.
We kiezen de groep die het best aansluit bij wat wij zoeken en gaan daar dieper op in.
Deze manier van ontwikkelen was lange tijd de enige manier waarop lokaal ontwikkelen mogelijk was. Alle nodige technologieën werden rechtstreeks geïnstalleerd op de ontwikkelmachine. Deze manier van werken is nog steeds de snelste omdat er geen extra complexiteit (overhead) bestaat bij het draaien van de website. Deze manier kan echter totaal niet bijbenen op het vlak van snelheid in gebruik. Door het talloze aantal technologieën en achterliggende versies is het praktisch onhaalbaar om deze allemaal te voorzien en constant te switchen. Ook het verschil tussen Operating Systems (OS) is hier bepalend. Elk OS moet zijn eigen setup voorzien want deze zijn totaal verschillend. Je controle en flexibiliteit zijn dan ook beperkt omdat je gebonden bent aan je OS. De laatste mokerslag is het feit dat, wanneer je een structurele fout introduceert aan je setup, je computer opnieuw volledig ingesteld moet worden. Deze manier is dus compleet achterhaald.
Onder een virtual machine verstaan we concreet dat een virtuele computer bestaat binnen je echte computer. Op deze virtuele computer worden alle nodige technologieën geïnstalleerd om je website te draaien. Het grote voordeel t.o.v. vorige manier is dat je meerdere van deze virtuele computers kan voorzien. Je gaat namelijk een virtuele computer voorzien per website die je wil draaien. Het voordeel is dat je kan switchen tussen virtuele computers en binnen die virtuele computer aanpassingen kan doorvoeren. Dat maakt switchen tussen verschillende technologieën een pak makkelijker en beheersbaarder. Bij kritieke fouten aan je setup kan je de virtuele computer weggooien en hem opnieuw laten genereren. Het nadeel is de grote overhead van de virtuele computer waardoor het initieel tientallen minuten kan duren voor je website lokaal bereikbaar is. Eenmaal de virtuele computer gebouwd zal dit veel minder lang duren om de website te draaien. Maar een kleine aanpassing aan de installatie zorgt ervoor dat dit hele proces opnieuw moet lopen wat de snelheid van gebruik toch aanzienlijk laat dalen. Op het vlak van ondersteuning van host platformen scoort deze oplossing super omdat al je instellingen binnen de virtuele computer gebeuren en deze is onafhankelijk van het host OS! Het maakt dus niet uit of je een Mac, Linux of Windows hebt, je kan de instellingen van de virtuele computer zonder problemen delen. Je website zelf kan snel draaien bij correct instellen van de virtuele computer. De mate van controle en flexibiliteit is hoog omdat je binnen de virtuele computer alle controle hebt.
Dit is een doorgedreven vorm van virtual machine based. I.p.v. een virtuele computer per website wordt er een zeer minimale virtuele computer per technologieversie voorzien. Een website draaien bestaat dan uit een aantal van deze mini-computers te laten samenwerken. De grote tijdswinst zit erin dat deze mini-computers gebouwd beschikbaar zijn en configuratie aanvaarden. Als je dus een niet structurele wijziging wil doorvoeren aan een technologie kan dat enorm snel omdat heel de omgeving niet opnieuw gebouwd moet worden. Wat bij het vorige onderdeel wel het geval was. Zelfs al zou er een structurele wijziging aan een technologie doorgevoerd moeten worden, moet enkel die zijn mini-computer opnieuw gebouwd worden. Dat kost significant minder tijd dan bij virtual machine based het geval was. Een nadeel bij deze manier van werken is dat deze mini-computers moeten samenwerken. Dit is dus de overhead die wordt geïntroduceerd door Docker zelf. Daardoor zal de snelheid van ontwikkelen lager liggen dan bij de andere oplossingen. Concreet hebben we dus alle voordelen van virtual machine based zonder de nadelen, mits een iets kleinere snelheid van ontwikkelen en in mindere mate gebruiksvriendelijkheid omwille van de kennis die je nodig hebt om docker te gebruiken. Ondertussen is docker zelf verder ontwikkeld en komen er steeds meer antwoorden op de deze laatste twee problemen. Het is dus binnen deze categorie waar we onze oplossing vinden.
Wrapper-oplossingen voeren abstractielagen in om enerzijds gebruiksvriendelijker en anderzijds performanter te zijn. De kost die je betaalt voor deze abstractielagen is dat je er ook aan gebonden bent en niet altijd weet wat er achterliggend gebeurt. Ze veroorzaken ook een discrepantie met de productie-omgeving omdat de wrapper-oplossing daar niet zal bestaan.
Voorbeelden van zo een wrapper-oplossingen zijn Lando, Docksal en DDEV. De ene oplossing heeft minder abstractielagen en dus ook kosten eraan gebonden dan de andere. Een vergelijking tussen deze platformen kan je online meerdere malen terugvinden.
Pure oplossingen werken rechtstreeks met docker zonder tussenliggende abstractielaag. An sich vergt dit meer kennis van docker maar is er meer controle mogelijk omdat je niet gebonden bent aan enige abstractielagen. Voor de pure oplossing hebben we enkel nog de mini-computers (images) nodig. Praktisch alle gangbare technologieën worden in de vorm van een image aangeboden door officiële uitgevers van die technologie. In principe hebben we daarmee genoeg om de website te draaien. Er zijn ook geoptimaliseerde images te vinden voor specifieke frameworks of CMS-en zoals Drupal. Een voorbeeld hiervan is Docker4drupal. Deze groep images zijn geoptimaliseerd voor Drupal en hoewel Calibrate veel met Drupal werkt, gebruiken we ook andere technologieën die niet gebaat zijn met deze optimalisaties. Daarom kiezen we ervoor eigen geoptimaliseerde images te gebruiken.
De keuze is gemaakt voor pure docker met eigen images omdat we de volledige controle en flexibiliteit van rechtstreeks met docker werken willen hanteren. Hoe je met docker werkt kan op talloze manieren gebeuren. Daar moeten dus afspraken rond gemaakt worden waarbij we volgende punten in het achterhoofd houden:
We willen volledige controle zodat power users geen beperkingen hebben in het gebruik. Het is dus zeer belangrijk afspraken te bundelen zonder abstractielagen te introduceren. Zo voorkomen we in de categorie wrapper-oplossing terecht te komen. Dit vermijdt de kost van abstractielagen en bootst lokaal de productie-omgeving zo exact mogelijk na.
Het is ook belangrijk dat we de setup niet complex maken zodat gebruik relatief vanzelfsprekend blijft en nieuwe mensen snel een website kunnen opzetten. Hierbij bieden we optionele hulpmiddelen en templates aan om lokaal ontwikkelen te versnellen.
Onze setup moet onderhouden worden. Technologieën die end-of-life (EOL) gaan moeten verdwijnen uit de setup zo niet is de setup niet te onderhouden. Op deze manier kunnen we legacy afscheiden en nieuwe functionaliteiten introduceren.
Oude projecten met EOL-technologieën moeten altijd nog kunnen opstarten. Je moet dus de mogelijkheid hebben om te switchen van versie van de setup zelf. Zo kan je terugkeren naar oudere versies waar specifieke EOL-technologieën ondersteund werden.
Met dat allemaal in het achterhoofd zijn we uitgekomen bij lokal.host. Deze setup zelf wordt onderhouden in een versiebeheersysteem waardoor gebruikers makkelijk kunnen switchen tussen verschillende versies. Wil je van de nieuwste snufjes gebruik maken word je wel aangeraden om je project bij te werken. Dit komt zowel de klant als jezelf ten goede. De setup bevat templates waarvan gestart wordt om sites snel op te kunnen zetten. Je hoeft deze templates niet te gebruiken en kan meteen losgehen op je eigen manier indien je genoeg vertrouwen in jezelf hebt.
In onze zoektocht naar een lokale ontwikkelingsomgeving die snel is in gebruik en ontwikkeling, werkt op de gangbare besturingssystemen en totale controle en flexibiliteit geeft aan de ontwikkelaar, zijn we dus uitgekomen op een pure Docker oplossing waar duidelijke afspraken rond gemaakt worden. Ook al zijn andere oplossingen misschien iets performanter en vergt onze aanpak regelmatig onderhoud, toch wegen deze nadelen niet op tegen de controle die we hebben, de mogelijkheid van lokaal nabootsen van de productie-omgeving en het vermijden van abstractielagen.
PS: de reden waarom lokal.host geen spellingsfout is: We ondersteunen HTTPS via een aangekocht certificaat en lokal.host was nog vrij 😊 . De clou zit 'm in de staart!
