Zoia Baletska

Je weet dat je naar de cloud moet. Maar je ziet ertegenop: wat als we data kwijtraken? Hoe lang gaat dit duren? Wat als het duurder uitpakt dan on-premise blijven? Kiezen we wel de juiste provider?

De afgelopen jaren hebben we 8 productiesystemen gemigreerd naar AWS, Azure en Google Cloud. Wat we daarvan geleerd hebben: de meeste cloudmigraties slagen gewoon. De migraties die misgaan, gaan mis door slechte planning — niet door slechte uitvoering.

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.

De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.

Een klein SaaS-bedrijf van zo'n 50 medewerkers klopte bij ons aan met een zorg die in de budgetbesprekingen was komen bovendrijven. Hun product was stabiel, het gebruik groeide gestaag, maar de cloudkosten gedroegen zich niet langer voorspelbaar. De infrastructuur kostte ongeveer €10.000 per maand. Niet extreem, maar het kroop omhoog zonder duidelijke verklaring. Voor een bedrijf van die omvang wordt zelfs een paar duizend euro verspilling per maand merkbaar.

Veel SEO-advies klinkt nog altijd alsof het uit 2014 komt. Eindeloze keywordlijstjes, “content is king”, en gepieker over dichtheidsscores waar niemand meer naar omkijkt. Ondertussen komen genoeg technisch prima websites niet van hun plek, omdat ze precies datgene negeren waar zoekmachines stilletjes heel goed in zijn geworden: structuur, duidelijkheid, snelheid, en of een site het gevoel geeft dat er mensen achter zitten die weten wat ze doen.

Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeerd ingestelde storage buckets, misschien een server die open aan het internet hangt. Dat zijn de dingen waar mensen screenshots van maken, postmortems over schrijven en securitypresentaties mee vullen. Het is alleen niet waar de meeste interessante problemen vandaan komen.

Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten.

Aan de ene kant is er enthousiasme over het vervangen van juniorwerk. Boilerplate, simpele features, kleine bugfixes — precies het werk dat vroeger je instap was, wordt nu steeds vaker door AI gedaan. Dat scheelt tijd, drukt de kosten en laat teams sneller werken, zo gaat het argument. Daar valt weinig tegenin te brengen.

Het verschil tussen monitoring en observability merk je pas echt wanneer er iets misgaat en je gebruikelijke tools je niet helpen begrijpen waarom. Dan pas wordt het gat zichtbaar.

Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet risico.

Claude Mythos zit precies op die grens. Het is niet zomaar weer een coding assistant. Het leest omvangrijke codebases, vindt kwetsbaarheden, en gaat soms nog een stap verder — door uit te zoeken hoe die zwakke plekken daadwerkelijk misbruikt zouden kunnen worden.

De meeste teams bouwen hun systemen op kleine storingen.

Een container crasht. Een node verdwijnt. Misschien heeft een availability zone een tijdje last. Dat zijn de scenario's waar architectuurplaten je op voorbereiden, en de meeste platformen vangen ze goed genoeg op dat je het nauwelijks merkt.

Cloudsecurity wordt vaak gepresenteerd als een gedeelde verantwoordelijkheid. In de praktijk vertaalt zich dat meestal naar iets als: “het platform regelt het grootste deel wel”. Precies bij die aanname beginnen de problemen.

Moderne cloudproviders doen hun werk goed als het om infrastructuur gaat — fysieke hardware, netwerklagen en managed services. Maar zodra jij daarbovenop begint te bouwen, verschuift de verantwoordelijkheid razendsnel.

Werk je al een tijd met React, dan zit je stack waarschijnlijk prima in elkaar. Je zoekt niet nog een state-library of weer een nieuwe manier om knoppen te stylen. De meeste gangbare problemen zijn opgelost, en het ecosysteem heeft zich gesetteld rond een handvol betrouwbare keuzes.

Cloudplatformen zijn razendsnel geworden. Je zet in minuten infrastructuur neer, schaalt op aanvraag en rolt wereldwijd uit zonder al te veel moeite. En toch duurt het vaak veel langer dan verwacht om een simpele codewijziging in productie te krijgen.

Een cloudmigratie begint meestal vol vertrouwen. Het plan klinkt simpel: bestaande systemen naar de cloud, minder gedoe met infrastructuur, beter kunnen schalen en de stack moderniseren. In presentaties en strategiestukken oogt het pad meestal kaarsrecht.

De werkelijkheid ziet er doorgaans anders uit.

Bugs fixen is veranderd.

Niet omdat bugs anders zijn. Het zijn nog steeds null references, race conditions, aannames die niet kloppen en randgevallen die je niet zag aankomen. Het verschil is dat je nu, als er iets breekt, niet langer alleen bent met die stack trace.

Er zit een herkenbaar patroon in developers die een tijdje met AI-tools werken: eerst nieuwsgierigheid, dan een periode van dagelijks gebruik, en vervolgens — verrassend genoeg — vermoeidheid. Veel engineers melden uitputting, irritatie of zelfs lichte weerzin bij het idee dagelijks met AI te moeten werken. Voor teams die verwachtten dat AI tijd zou besparen, is dat een verwarrende ervaring.

In verspreide engineeringteams zijn merge conflicts een terugkerende hoofdpijn. Ze vertragen de ontwikkeling, frustreren engineers en introduceren subtiele bugs die soms pas bij de deploy opvallen. Voor kleine teams werken klassieke lokale ontwikkelomgevingen prima, maar zodra je opschaalt naar remote of over meerdere locaties, is er iets steviger nodig.

Heb je weleens het gevoel dat je CI/CD-pipeline eerder tégen je werkt dan vóór je? Je bent niet de enige. De belofte van continuous integration en continuous delivery was vrijheid: snellere feedback, geautomatiseerd testen, betrouwbare deployments en meer tijd om te coderen. In de praktijk is CI/CD voor veel teams een tweede fulltime baan geworden.

Naar de cloud gaan is bedrieglijk eenvoudig.

Je maakt een account aan, zet een paar services op, rolt je eerste workload uit, en alles werkt. In het begin dan. De problemen duiken meestal niet op terwijl je aan het experimenteren bent — ze komen zodra het platform groeit, zodra meer mensen eraan zitten, en zodra echte bedrijfsdata en compliance-eisen in beeld komen.

Als frontend-developers praten we graag in absolute termen: X heeft Y om zeep geholpen, dit is de toekomst, dat is dood. De opkomst van React Router Framework mode (v7+) — voortgekomen uit de samenvoeging met Remix — leverde precies dat soort discussie op, zeker toen developers begonnen te roepen dat het schoner en sneller voelde dan Next.js voor echte SPA's.

In moderne softwareontwikkeling kan security geen bijzaak meer zijn. Kwetsbaarheden die je na de release ontdekt, kosten bedrijven miljoenen en beschadigen hun reputatie. Een Secure SDLC verweeft securitypraktijken in elke fase van je ontwikkelproces, zodat je software vanaf het begin robuust, compliant en veerkrachtig is.

Januari is de maand waarin veel teams hun cloudfactuur openen, twee keer knipperen en zich afvragen wat er in december precies gebeurd is.

Feestdagenverkeer, stilgelegde projecten, tijdelijke experimenten en resources uit de categorie “dat ruimen we later wel op” komen aan het eind van het jaar allemaal samen.

Elke januari doen developers over de hele wereld dezelfde beloftes: “Dit jaar leer ik eindelijk Rust.” “Ik ga alles netjes herschrijven.” “Ik lever nooit meer rommelige code op.”

En in februari… wint de werkelijkheid.

Het probleem is niet je motivatie — het is dat de meeste voornemens te groot en te vaag zijn, of losstaan van je dagelijks werk.

In 2025 was cloud computing veel meer geworden dan hosting: het werd het fundament onder AI, hybride infrastructuur, edge-to-cloud-pijplijnen en duurzame digitale operaties op grote schaal. Voor veel teams en bedrijven betekent “cloud” inmiddels meer dan VM's en opslag.

De cloud is tegenwoordig geen keuze meer — het is een versneller. Maar de waarheid is: veel teams ontdekken op de harde manier dat de cloud zich alleen terugbetaalt als je hem goed gebruikt. Verkeerde instellingen, ontspoorde kosten, trage pipelines en architectonische flessenhalzen wijzen er meestal op dat een team hulp nodig heeft… en niet meer cloudtegoed.

LLM's en “AI-ondersteund programmeren” veranderen in hoog tempo hoe we software maken. Autocomplete, boilerplate genereren, refactoren — veel teams leunen er dagelijks op. Maar betekent dat ook dat we LLM's complexe taken uit de echte wereld kunnen toevertrouwen, zoals ervaren engineers dat doen?

De cloud is allang geen infrastructuur meer alleen — het is een kernvaardigheid voor moderne engineeringteams. Of je nu softwareontwikkelaar, DevOps-engineer, dataspecialist of tech lead bent: je Google Cloud-kennis versterken is een strategische investering geworden. Maar met tientallen diensten en snelle vernieuwing raak je het overzicht zo kwijt.

Bij ZEN houden we onderzoek in de gaten dat raakt aan hoe engineeringteams software bouwen, opleveren en onderhouden. Onlangs stuitten we op een nieuwe studie — “The Impact of Large Language Models (LLMs) on Code Review Process” — waarin meer dan 25.000 GitHub pull requests zijn geanalyseerd om te zien hoe GPT-achtige modellen de snelheid en samenwerking bij code reviews beïnvloeden.

Op 18 november 2025 kreeg Cloudflare — een grote leverancier van content delivery en internetinfrastructuur die ruwweg 1 op de 5 webverzoeken wereldwijd afhandelt — te maken met een omvangrijke netwerkstoring. Het gevolg: tientallen bekende diensten zoals ChatGPT en X waren urenlang geheel of gedeeltelijk onbereikbaar.

Als bedrijven naar de cloud verhuizen, gaan ze er vaak van uit dat de provider — AWS, Azure of Google Cloud — de security wel regelt. Het is tenslotte hun datacenter, hun servers, hun infrastructuur.

De werkelijkheid ligt genuanceerder. Cloudsecurity draait om een model van gedeelde verantwoordelijkheid.

Goede securitypraktijk zegt: “roteer je secrets regelmatig”. Maar draait je applicatie in productie, dan is dat makkelijker gezegd dan gedaan. API-keys, databasewachtwoorden en tokens zitten vaak diep in levende systemen — en ze vervangen voelt als een bom demonteren.

De manier waarop we werken is ingrijpend veranderd. Remote en hybride modellen hebben softwareontwikkeling en IT-beheer verplaatst van centrale kantoren naar teams over de hele wereld. Dat levert flexibiliteit en een grotere vijver aan talent op, maar het brengt ook nieuwe uitdagingen mee voor disaster recovery.

Code reviews horen ons betere developers te maken — niet gefrustreerde. Toch voelen ze in veel teams eerder als een poortwachter of een muggenzifterij dan als een kans om te groeien. Het verschil tussen een pijnlijke en een productieve review zit meestal in je cultuur en je proces, niet in je tooling.

Ruim tien jaar lang werd de wereldwijde cloudmarkt gedomineerd door Amerikaanse hyperscalers — AWS, Microsoft Azure en Google Cloud. Deze reuzen bepaalden wat “de cloud” voor de meeste organisaties betekent: schaalbare infrastructuur, wereldwijd bereik en een schier eindeloos aanbod aan diensten.

Frontend hosting is het afgelopen decennium ingrijpend veranderd. We zijn gegaan van statische HTML-bestanden naar een FTP-server slepen, naar full-stack applicaties aan de edge uitrollen met één commando. Met frameworks als Next.js, Remix, Gatsby en Vite die oprekken wat een “frontend” eigenlijk is, rennen hostingpartijen zich uit de naad om bij te blijven.

Dit artikel zet op een rij hoe je cloud back-up en disaster recovery aanpakt in een remote-first wereld — met de nadruk op wat er werkelijk werkt, welke tools je kunt inzetten en welke afwegingen erbij komen kijken.

Moderne applicaties combineren vaak een React-frontend (gebouwd met Vite, Next.js, Remix) en een backend-API (Node.js, Python, Java). In productie is het meestal het schoonst om frontend en backend als aparte diensten uit te rollen.

Maar soms wil je gewoon het gemak van allebei in één container.

Denk je dat naar de cloud gaan je bedrijf duurzaam maakt? Niet altijd. Ontdek de verborgen CO2-kosten van cloud computing en de eenvoudige optimalisaties waarmee je zowel uitstoot als kosten terugdringt.

Backstage is een open platform voor het bouwen van ontwikkelaarsportalen - locaties waar bedrijven technische ondersteuning en educatie kunnen bieden. Op deze portals kunnen softwaredocumentatie, voorbeeldcode, tools en kennisbanken worden aangeboden om de communicatie en functionele samenwerking te verbeteren. Vanuit het perspectief van een ontwikkelaar vereenvoudigt een ontwikkelaarsportaal het API-beheer.

Feature flags, ook bekend als feature toggles of feature switches, zijn een krachtig hulpmiddel bij softwareontwikkeling waarmee ontwikkelaars specifieke features of functionaliteiten in een applicatie kunnen in- of uitschakelen. In het dynamische landschap van front-end ontwikkeling is de integratie van feature flags een onmisbare strategie geworden, die een wereld aan mogelijkheden opent voor ontwikkelaars die op zoek zijn naar flexibiliteit en meer controle over hun projecten.

Een zoekfunctie op je website kan de gebruikservaring flink verbeteren. Een goed ontworpen zoekbalk is krachtig gereedschap om betrokkenheid en conversie te verhogen. In dit artikel voegen we een snelle, eenvoudig te implementeren zoekfunctie toe met de Custom Search API van Google.

Een goede SEO is cruciaal voor je website. Een steeds belangrijker onderdeel daarvan is het hebben van goede metatags voor pagina's en artikelen op je site. Bij ZEN Software hebben we een extreem schaalbare setup die gebruik maakt van een headless CMS, Cloud Platform en een content delivery network van wereldklasse. In 5 eenvoudige stappen goede SEO toevoegen aan een CaaS setup!