Kies het juiste webbureau: check deze 12 kwaliteitsstandaarden

Bij veel bedrijven maakt digitaal een groot deel uit van hun bedrijfsvoering. Technisch talent is steeds moeilijker te vinden en binden. Dus is het belangrijk dat je met de juiste bureaus (waar deze talenten vaak nog wel te vinden zijn) werkt. De juiste bureaukeuze kan een bedrijf enorme concurrentievoordelen bieden. Ook levert het op lange termijn vaak kostenbesparingen op, omdat technische architecturen lang meegaan.

Scherp op kwaliteit met standaarden

Ik zie vaak dat bureauselectie voornamelijk op gevoel gedaan wordt, en dat is ook goed. Nog beter is het om je onderbuikgevoel te staven met harde relevante criteria. Belangrijke criteria zijn de technische standaarden die een bureau hanteert en hoe standaarden geïmplementeerd worden bij haar ontwikkelaars. Veel bureaus hanteren helemaal geen standaarden, omdat ze dit niet belangrijk genoeg vinden of omdat ze het simpelweg niet kennen. Wie geen benul heeft van technische standaarden, heeft zich nog nooit afgevraagd hoe je betere kwaliteit kunt leveren.

Een bureau hoeft zich niet per se aan standaarden als W3C en code-style-standaarden te houden, maar het volgen van standaarden biedt wel grote voordelen: het zijn beproefde recepten, worden vaak breed gedragen door de communities (denk ook aan standaard-enforcement tooling) en ze zijn uitgebreid gedocumenteerd en bediscussieerd. Als je scherp bent op kwaliteit, kunnen standaarden je helpen bij het behalen van hoogwaardige resultaten.

‘The twelve-factor app principle’

Tegenwoordig wordt software vooral geleverd als applicatie of als software-as-a-service. Een leidend manifesto voor technische standaarden is The twelve-factor app principle. Dit is een kwaliteitsdefinitie voor het bouwen van moderne software. Het is geschreven door de co-founder van Heroku (hosting-platform) en volledig in de organisatie van Heroku en service geïntegreerd. Als je van deze principes gebruikt maakt:

• Zet je een standaard neer voor het opzetten van projecten, zodat collega-developers weten hoe ze moeten starten met de ontwikkeling van een applicatie.
• Ben je zo weinig mogelijk afhankelijk van het onderliggende (operating)systeem, waardoor je applicaties makkelijker over te hevelen zijn naar andere systemen
• Kun je je applicatie sneller releasen met zo min mogelijk downtime
• Minimaliseer je de verschillen tussen verschillende test/productie omgevingen om zo fouten te voorkomen
• En kun je veel makkelijker opschalen, mocht je applicatie populairder worden

Hieronder een beschrijving van de 12 punten:

1. Codebase

Een 12 factor-app bewaart al haar code op één plek, namelijk in een versiebeheersysteem. Dan kun je die code overal draaien (standalone). Kan dat niet, dan heb je niet alles op één plek opgeslagen. Dit is over het algemeen geen probleem, omdat vrijwel alle bureaus dit al op orde hebben.

2. Dependencies

Software is vaak afhankelijk van andere software (dependencies). In een applicatie waar dependencies goed ingeregeld zijn, is het duidelijk welke afhankelijkheden er zijn en welke versies van deze dependencies (denk aan een framework) worden gebruikt. Stel, je developmentteam gebruikt Symfony, Laravel of Yii als webframework, dan is dit framework op zichzelf een dependency. Als er een update komt, wil je niet dat jouw applicatie daardoor breekt. Dit moet je voor zijn, en dat doe je door jouw dependencies in te regelen.

3. Config

Bureaus gebruiken vaak verschillende ‘omgevingen’, zoals een test-, acceptatie- en productieserver. Configuratie verschilt per omgeving – code niet. Een 12 factor-app slaat daarom de configuratie niet op in de code, maar afgezonderd in de omgeving. Als je de configuratie wel opslaat in de code, dan zouden bijvoorbeeld wachtwoorden (in een extreem geval) op straat kunnen komen te liggen.

4. Backing services

Software is vaak afhankelijk van andere services. Deze services moeten makkelijk te vervangen zijn (denk aan het vervangen van een lokale databaseserver voor een losstaande databaseserver). Dit zorgt voor flexibiliteit en maakt een 12 factor-app schaalbaar. Iemand in je team kan dan een lokale service (Redis bijvoorbeeld) vervangen door een instance van Amazon (Elasticache) zonder dat je code hoeft aan te passen. Erg belangrijk.

5. Build, release, run

Aan het uitbrengen van een update voor een 12 factor-app gaan een aantal stappen vooraf. Eerst maakt het bureau de software productieklaar (‘builden’), daarna ‘releast’ men de software (de software op een productieomgeving zetten) en vervolgens ‘runt’ het bureau de software (nieuwe update uitvoeren en draaien).

Het is belangrijk dat de build stage het zware werk doet en dat developers dat managen. Het ‘runnen’ moet simpel en stabiel zijn, zodat het technisch team ’s nachts rustig slaapt. Stel, een serverpark valt uit (stroomstoring?), dan moet de applicatie automatisch herstarten, zonder menselijke inzet.

6. Processes

12 factor-apps moeten stateless zijn. Dat betekent dat de code die een applicatie uitvoert geen data mag ‘onthouden’. States moeten naar bijvoorbeeld een database gaan. Zo kun je bijvoorbeeld een applicatie over meerdere servers uitvoeren, en maakt het niet uit welke server welk gedeelte oppakt. De ‘state’ staat namelijk los van je applicatie.

Stel je een registratieproces voor waar een gebruiker in drie verschillende schermen informatie moet invullen om een profiel aan te maken. Een veelgebruikte manier is om de tussentijdse status in de code op te slaan, totdat het proces compleet is. Maar de juiste manier is om de data in bijvoorbeeld een database op te slaan, zodat – zelfs als de server down gaat – een andere server dit in het registratieproces over kan nemen.

7. Port binding

Een 12 factor-app draait zelfstandig en maakt zichzelf beschikbaar aan de buitenwereld via een adres/poort-combinatie. De software is dus niet afhankelijk van een webserver als nginx of apache. Dit geldt ook voor andere onderdelen van de applicatie, zoals databases en caching-lagen. Deze zijn allemaal benaderbaar via een adres/poort-combinatie. Zo kun je makkelijk services uitwisselen, zonder dat je je hele configuratie hoeft aan te passen.

8. Concurrency

Een 12 factor-app is opgesplitst in zoveel mogelijk geoptimaliseerde processen met elk hun eigen taak. Als dat zo is ingericht, kun je makkelijk nieuwe processen toevoegen, zonder de huidige aan te passen. En op die manier kun je een applicatie veel sneller opschalen.

9. Disposability

Als er wijzigingen aan de 12 factor-app zijn, moeten deze in een oogwenk afgehandeld zijn. De gebruiker moet geen last hebben van langdurende onderhoudsprocessen, waardoor een service tijdelijk niet beschikbaar kan zijn.

10. Dev of prod parity

Een 12 factor-app houdt de ontwikkel- en productieomgevingen zo veel mogelijk hetzelfde. Dit voorkomt rare situaties bij de uitrol van een applicatie, zoals het gebruik van verschillende versies van het besturingssysteem of server software ten opzichte van de ontwikkelomgeving.

11. Logs

Een 12 factor-app zorgt ervoor dat je altijd (real-time) kan zien wanneer er iets geks is gebeurd in je applicatie, zowel in development als op productie. Gebruik een tool als PaperTrail om je logs te verzamelen en te indexeren, zodat je makkelijk problemen kunt vinden en hun oorzaak kunt achterhalen.

12. Admin processes

Een 12 factor-app voert administratieve taken als datamigraties en onderhoud uit via one-time scripts die uitgerold worden over omgevingen. One-time scripts zijn scripts die éénmalig worden uitgevoerd. Ga niet handmatig database-aanpassingen aan meerdere servers uitvoeren. De kans dat je bij een handmatige aanpassing iets vergeet of iets net anders doet is erg groot, en kan ervoor zorgen dat de applicatie niet meer werkt.

Basisvoorwaarden voor een betrouwbare & schaalbare applicatie

Het netjes inrichten van deze standaarden heeft te maken met discipline en goed ingericht zijn als bureau. Deze basisvoorwaarden zijn belangrijk om uiteindelijk een betrouwbare en schaalbare applicatie te bouwen. Ook voor kleine projecten gaan deze standaarden gewoon op.

Door deze korte opsomming besef je je hopelijk beter dat technische kwaliteit niet vanzelf komt. Je mag als software-ontwikkelaar én als klant kritisch zijn op kwaliteit. Als je een bureauselectie gaat maken, neem dit lijstje dan mee en vraag het webbureau om te laten zien hoe ze haar processen heeft ingericht. Punt voor punt. Je ziet dan binnen de kortste keren of je te maken hebt met een geldgedreven club of een professioneel bureau. Veel succes!

Illustraties met dank aan Fotolia.