In Deel 1 schreef ik waarom we een AI-reisinterface vanaf nul bouwden, wat we leerden van onze eerste mislukte poging in 2019, en waarom een plugin je nooit een volledig geïntegreerde conversationele ervaring geeft. Dit deel gaat over het hoe. De architectuur, de zoekpipeline, het geheugenprobleem dat vier pogingen kostte om op te lossen, en het UI/UX-werk dat 25 seconden aanvoelt als 5.

De architectuur

Omdat dit een techblog is en geen marketingpagina, laat ik je zien wat er echt draait. Dit is geen weekendproject. Dit is productie-infrastructuur.

Frontend (React + TypeScript + Zustand)
    │
    │  WebSocket (real-time, bidirectional)
    │
FastAPI Backend
    ├── Query Orchestrator
    │     ├── LLM Client (multi-provider with automatic fallback)
    │     ├── Tool Registry (9 specialized tools)
    │     └── Observer System (async post-turn analysis)
    ├── RAG Pipeline
    │     ├── Vector Database (3 content collections)
    │     ├── Embedding Engine
    │     └── Reranker (dual provider, switchable)
    ├── Conversation Memory (dual storage)
    │     ├── SQL (message history)
    │     └── Vector DB (semantic search over past messages)
    ├── Security Layer
    │     ├── Input Guard (prompt injection defense)
    │     ├── Output Guard (credential leak prevention)
    │     └── Rate Limiting + IP Management
    ├── MCP Server (Model Context Protocol)
    │     └── External AI assistant access to our data
    └── Lead Management
          ├── Proposal Generation
          └── Specialist Handoff

De frontend is een React-applicatie met real-time WebSocket-communicatie. Geen polling. Geen request-response-cycli waarin je op een compleet antwoord wacht. Elke token streamt in real-time, gebufferd op 50ms-intervallen om flikkering in de UI te voorkomen. Productresultaten worden naar de interface gepusht zodra ze gevonden zijn, nog voordat de LLM aan zijn antwoord begint.

De backend is Python/FastAPI met een modulair toolsysteem. De LLM genereert niet alleen tekst. Hij heeft toegang tot 9 gespecialiseerde tools en beslist zelfstandig welke hij gebruikt. Reizen zoeken? Dan roept hij search_products aan. Informatie over een bestemming nodig? Dan roept hij search_knowledge aan. Terugroepen wat eerder besproken is? Dan doorzoekt hij het gespreksgeheugen semantisch.

De LLM genereert geen antwoorden. Hij orkestreert tools en stelt een antwoord samen op basis van echte data.

De LLM-laag draait met een multi-provider fallback-systeem. Valt de primaire provider uit, dan schakelt het systeem automatisch over naar de secundaire. Geen downtime. Geen foutmeldingen. De klant merkt er niets van.

Er draait al een MCP-server, het protocol dat ik beschreef in mijn Web 4.0-post. Externe AI-assistenten kunnen onze reisdata er al door bevragen. Het is nog vroeg, maar de infrastructuur voor AI-to-business-communicatie staat live. Als de AI-assistent van Lisa de producten van 333travel wil doorzoeken, bestaat het endpoint al.

De RAG-pipeline: waar het echte werk gebeurt

RAG, Retrieval-Augmented Generation, is de ruggengraat van het hele systeem. Het is wat “GPT met een kennisbank” scheidt van “een AI die je product echt kent.” Maar slecht uitgevoerde RAG is bijna erger dan geen RAG.

We onderhouden drie aparte vectorcollections:

Stelt een klant een vraag, dan wordt de query ge-embed en tegen de relevante collection gegooid. Maar hier komt het cruciale deel: we pakken niet gewoon de beste vector-matches en noemen dat een resultaat.

Vector similarity alleen is middelmatig. Het brengt je in de juiste richting, maar levert niet de beste resultaten. Daarom doen we een brede fetch, aanzienlijk meer resultaten dan nodig, en halen die door een reranker. De reranker beoordeelt elk query-documentpaar op werkelijke semantische relevantie, niet alleen op embedding-nabijheid.

Het verschil is enorm. Het is het verschil tussen “hier zijn reizen die een paar van je woorden bevatten” en “hier zijn reizen die daadwerkelijk matchen met wat je zoekt.”

Maar het gaat verder. Nog voordat de query de vectordatabase raakt, gaat hij door een fuzzy normalisatielaag. Elke land- en plaatsnaam in ons systeem wordt bij het opstarten gecachet. Typt een klant “Bali”, dan weten we dat Indonesië bedoeld wordt. Schrijft iemand “Tailand”, dan weten we wat er bedoeld wordt. Aliassen, spellingvarianten, taalverschillen: allemaal opgelost voordat de zoekopdracht begint. Zonder dit krijg je lege resultaten op queries die wel hadden moeten matchen. En daarbovenop combineert de zoekopdracht semantische similarity met metadatafilters. Land, duur, producttype: dat zijn geen velden in een database. Het zijn actieve filters die samen met de vectorsearch de resultaten verfijnen, nog voordat de reranker begint.

Na het reranken splitsen de resultaten zich in twee paden. De volledige set gererankte resultaten gaat meteen naar de frontend, maar geblurd. De klant ziet productkaarten verschijnen terwijl Joy nog aan het nadenken is. Het toont voortgang zonder te overweldigen. Ondertussen krijgt de LLM een uitgedunde versie van die resultaten, alleen de velden die hij nodig heeft om te redeneren. Deze projectie bespaart ruwweg een derde van de tokens, wat snellere antwoorden en lagere kosten betekent. Daarna stelt Joy haar antwoord samen en bespreekt ze de 4 of 5 reizen die echt passen bij de vraag. Alleen die besproken producten worden zichtbaar voor de klant. De rest verdwijnt. Wat de klant ziet is een gecureerde, doordachte selectie. Geen lijst met 10 zoekresultaten. Een aanbeveling van 5 die echt logisch zijn.

Brede fetch → Rerank → Project. Drie stappen die het verschil maken tussen een zoekresultaat en een aanbeveling.

Het geheugenprobleem

Dit is het onderdeel dat de meeste iteraties kostte om goed te krijgen.

Conversationele AI heeft een smerig geheimpje: het onthoudt niets. Elke LLM-call is stateless. Het model heeft geen idee wat er eerder gezegd is, tenzij je de context expliciet aanlevert. En er is een grens aan hoeveel context je kunt aanleveren.

Voor een simpele Q&A-chatbot maakt dat niet uit. Iemand stelt een vraag, krijgt een antwoord, klaar.

Maar voor een reisassistent? Geheugen is alles.

Een klant zegt: “Ik wil twee weken naar Thailand.” Drie beurten later: “Maak er eigenlijk drie weken van. En ik wil Laos erbij.” Vijf beurten later: “Wat was die reis die je eerder liet zien, met de kookles?”

Zonder geheugen is elke beurt een leeg blad. Het systeem weet niets van Thailand. Niets van de wijziging naar drie weken. Niets van Laos. En al helemaal niets van de reis met de kookles van zeven berichten geleden.

Zonder geheugen is elk bericht een eerste date. Je AI heeft geen idee wat er eerder gebeurd is.

Dit losten we niet in één poging op. Niet in twee. Zelfs niet in drie.

De eerste versie was simpel: de laatste 10 vraag-antwoordparen in de LLM-context stoppen. Dat werkte voor korte gesprekken. Maar onze gesprekken zijn niet kort. Klanten verkennen, vergelijken, komen terug op eerdere ideeën, bedenken zich. Tien beurten is niet genoeg als iemand twintig minuten over drie verschillende landen heeft gechat.

Dus probeerden we op de achtergrond samenvattingen te genereren. Het idee was goed: het gesprek samenvatten tot kernpunten, zodat de LLM altijd het volledige beeld heeft zonder de hele context window vol te gooien. De praktijk was anders. De LLM begon details te hallucineren in de samenvattingen. Landen door elkaar halen. Voorkeuren toedichten die de klant nooit had genoemd. De samenvatting zou de source of truth zijn, en hij verzon dingen.

Toen ontwierpen we een geheugensysteem in drie lagen: kortetermijn, tijdelijk en langetermijn. De tijdelijke laag moest bijhouden welke onderwerpen bij welke bestemming hoorden, welke voorkeuren op welk deel van de reis golden. Op papier elegant. In de praktijk een nachtmerrie. Het vereiste dat de AI complexe relationele context begreep, zoals “toen ze zeiden dat het budget flexibel was, bedoelden ze dat voor Thailand, niet voor Vietnam.” Dat kon hij niet. Te veel edge cases. Te fragiel.

Wat we uiteindelijk hadden, was simpeler en robuuster. Elk bericht wordt als vector geëmbed in een aparte memory collection in dezelfde database die we voor product search gebruiken. Als de klant zegt “die reis met de kookles”, draait het systeem een semantic search over alle eerdere berichten in die sessie. Het vindt het relevante bericht, ook als de exacte woorden niet overeenkomen. Misschien noemde Joy het drie beurten eerder een “culinaire ervaring”. Vector search geeft niets om woordmatching. Het matcht betekenis. Gecombineerd met de laatste 10 uitwisselingen in de prompt voor directe context, hoeft Joy niet voor elke vraag die tool call te doen. Ze heeft het recente gesprek direct bij de hand, en de volledige historie doorzoekbaar wanneer ze die nodig heeft.

Vier pogingen. Elke poging leerde ons iets over wat AI wel en niet kan doen met context. De definitieve versie werkt niet omdat het de slimste opzet is, maar omdat het het eerlijkst is over de beperkingen.

AI-geheugen is niet één probleem. Het zijn er twee: terugroepen wat er gezegd is, en begrijpen wat er bedoeld is. We hadden twee verschillende systemen nodig om dat op te lossen.

UI/UX: het onzichtbare werk

Hier sterven de meeste AI-projecten, zonder dat ze het zelf doorhebben.

Je kunt de meest geavanceerde RAG-pipeline ter wereld hebben. De slimste retrieval. De beste reranking. Maar als de interface traag, log of verwarrend aanvoelt, doet dat er allemaal niet toe. De klant geeft niets om je architectuur. Het gaat ze om hoe het voelt.

Als je AI slim is maar je interface traag, heb je een genie gebouwd dat opgesloten zit in een kast.

Hier zijn we diep op ingegaan. En “diep” betekent tientallen iteraties op dingen die de meeste mensen details zouden noemen. Maar de details zijn het product.

Streaming die natuurlijk voelt. LLM-antwoorden streamen token voor token over een WebSocket. Maar rauwe streaming geeft flikkerende tekst die schokkerig en onaangenaam is. We bufferen met intervallen van 50ms. Snel genoeg om real-time te voelen, langzaam genoeg om constante re-renders te voorkomen. Het verschil is subtiel, maar enorm voor de ervaren kwaliteit.

De afweging in snelheid. Laten we eerlijk zijn: een product search met volledig antwoord duurt 20 tot 30 seconden. Dat is lang. We weten dat het lang is. Maar we hebben een bewuste keuze gemaakt: kwaliteit boven snelheid. De brede fetch, de reranking, de semantic matching, elke stap in de pipeline bestaat omdat hij de resultaten beter maakt. Haal er één weg en je krijgt snellere antwoorden met slechtere aanbevelingen. Liever dat Joy 25 seconden werkt en 5 reizen aflevert die echt passen, dan 10 middelmatige matches in 8 seconden.

Dus de vraag werd: hoe zorgen we dat 25 seconden niet aanvoelen als 25 seconden? Daar kwam het UX-werk. Joy laat zien wat ze doet. Producten zoeken. Bestemmingsinformatie opzoeken. Gesprekshistorie checken. Elke tool call is zichtbaar terwijl hij gebeurt. Productkaarten schuiven vervaagd naar binnen terwijl zij nog haar antwoord opbouwt. Zodra het antwoord klaar is, worden alleen de reizen zichtbaar die Joy daadwerkelijk bespreekt. De rest vervaagt. De klant staart nooit naar een leeg scherm. Ze zien het proces ontvouwen. En het blijkt dat ergens naar kijken werken totaal anders voelt dan ergens op wachten.

Een deel van de latency is ook een taalprobleem. Nederlands is slecht vertegenwoordigd in de meeste embedding- en taalmodellen. Het semantische begrip dat in het Engels prachtig werkt, degradeert als je klanten en productdata Nederlands zijn. Dat betekent meer verwerking, zorgvuldiger matchen, meer moeite voor hetzelfde kwaliteitsniveau.

Wat is GPT-NL? GPT-NL is een Nederlands initiatief om een large language model te bouwen dat specifiek getraind en geoptimaliseerd is voor de Nederlandse taal.

GPT-NL: Een verantwoord taalmodel voor NederlandIn Nederland wordt gewerkt aan de ontwikkeling van een eigen open taalmodel genaamd GPT-NL. Wij gebruiken alleen data om het model te trainen als we die rechtmatig kunnen verkrijgen en bieden zo een verantwoord alternatief op bestaande LLMs. Dit model is essentieel voor het versterken en behouden van onze digitale soevereiniteit. GPT-NL

Waar huidige modellen zoals GPT en Claude Nederlands behandelen als een niet-bestaande taal, wil GPT-NL Nederlands een first-class citizen maken in AI. Voor toepassingen zoals de onze, waar zowel de klant als de productdata Nederlands zijn, kan een model dat de taal echt begrijpt de kwaliteit van semantisch zoeken aanzienlijk verbeteren en de extra verwerking verminderen die we nu nodig hebben om dat gat te compenseren. We volgen dit project op de voet.

En dan is er de keuze van het model. De kwaliteit van het gesprek hangt sterk af van welke LLM je gebruikt. We draaien op Sonnet 4.6 als primair model, en het verschil met kleinere of goedkopere modellen is niet subtiel. Het is het verschil tussen een gesprek dat natuurlijk voelt en een dat gerepeteerd aanvoelt. Haiku, de snellere en goedkopere optie, voelt als een downgrade zodra je overschakelt. GPT dient als onze automatische fallback, maar het is een stap terug in gesprekskwaliteit. Dit zijn geen inwisselbare commodity’s. Het model dat je kiest bepaalt de ervaring die je klant krijgt.

Directe paginaladingen. De hele conversatie blijft bewaard in local storage. Als je de pagina ververst of later terugkomt, staat je gesprek er al. Direct. Geen spinner. Geen “opnieuw verbinden…"-melding. De sync met de server gebeurt geruisloos op de achtergrond.

Markdown-normalisatie. LLM’s hebben meningen over opmaak. Claude is gek op vette koppen met emoji. GPT is gek op genummerde lijsten. Wij normaliseren alles server-side. Vet-met-emoji wordt omgezet naar schone koppen. Horizontale lijnen worden gestript. Font weights worden teruggeschroefd. Het resultaat oogt alsof het ontworpen is, niet gegenereerd. De klant moet nooit het gevoel hebben dat hij AI-output zit te lezen.

Sessiecontinuïteit. Je sessie overleeft paginaverversingen, gesloten browsers en herverbindingen. Kom een dag later terug, je gesprek staat er nog. Je opgeslagen reizen staan er nog. En als een sessie verloopt, krijg je een nette overlay die uitlegt wat er gebeurd is, geen kapotte pagina of een cryptische foutmelding.

De lead flow. Als een klant klaar is om met een specialist te praten, genereert het systeem een reisvoorstel dat al vooraf is ingevuld met wat het uit de conversatie weet. Besproken bestemmingen, reisvoorkeuren, bekeken producten. Minimale wrijving. Maximale context. De menselijke specialist pakt precies op waar Joy stopte. Dat is geen handoff. Dat is precies het punt. Joy bestaat om dat menselijke gesprek beter te maken, niet om het te vermijden.

Elk van deze details kostte meerdere iteraties. En geen enkele is zichtbaar voor de klant. Dat is de bedoeling.

Security: een eerlijke noot

Ik houd deze sectie kort en eerlijk. Security is niet iets wat je afmaakt. Het is iets waar je continu aan werkt.

We hebben een dubbel guardsysteem. Een input guard vóór de LLM die prompt-injection-pogingen onderschept, en een output guard ná de LLM die credential leaks of system prompt-fragmenten in antwoorden onderschept. Beide zijn deterministisch en voegen vrijwel geen latency toe.

De system prompt is verhard met anti-jailbreak-instructies. Er is rate limiting, botbescherming en IP-beheer voor hardnevig misbruik.

Is het bulletproof? Nee. Niets is dat. Maar het is gebouwd met defense in depth in gedachten, en we itereren erop naarmate nieuwe aanvalspatronen opduiken. Als je een AI-interface bouwt die met het publiek praat en je hebt nog niet nagedacht over input/output guards, dan ligt er een probleem op de loer.

Het grotere geheel: een extra kanaal, geen vervanging

Laat me heel duidelijk zijn over wat Joy is en wat ze niet is.

Joy is geen vervanging van onze website. Ze is geen vervanging van telefoon of e-mail. Ze is een extra kanaal. Een nieuwe manier voor klanten om onze producten te ontdekken, naast alles wat er al bestaat. Ze zal nooit een vervanging van menselijk contact zijn. Dat vinden we bij ons bedrijf het belangrijkst. Joy is een middel naar menselijk contact. Ze helpt klanten uitvinden wat ze willen, zodat het gesprek met een van onze specialisten op een compleet ander niveau begint.

Joy is niet de bestemming. Ze is de weg die leidt naar een echt gesprek met een echt persoon.

De MCP-server staat al live, wat betekent dat AI-assistenten onze data al programmatisch kunnen bevragen. Als de Web 4.0-visie werkelijkheid wordt en Lisa’s AI-assistent zelfstandig op zoek gaat naar haar perfecte Thailand-reis, dan bestaat het endpoint al. Niet omdat we er haastig mee aan de slag zijn gegaan. Omdat we al meer dan een jaar met deze infrastructuur aan het experimenteren zijn.

Joy is niet het eindproduct. Ze is het begin van een kanaalstrategie die zowel mens-tot-AI- als AI-tot-AI-interacties omvat. En ze is een test, een heel serieuze, heel grondige test, of conversationele AI vandaag de dag daadwerkelijk waarde kan toevoegen voor reisklanten.

De resultaten tot nu toe zijn beter dan ik verwachtte. Niet vlekkeloos, niets is dat, maar echt indrukwekkend in hoe natuurlijk de gesprekken voelen en hoe relevant de aanbevelingen zijn. Als je een klant een vaag idee ziet beschrijven en Joy komt met reizen die daadwerkelijk passen, dan besef je: dit is geen gimmick. Het werkt. En het werkt dankzij alles wat eronder ligt.

Dus, welk probleem lossen we ook alweer op?

Ik begon met deze vraag omdat dit de vraag was die alles heeft geleid wat we bouwden. Niet “hoe gebruiken we AI?” Niet “wat doen onze concurrenten?” Niet “hoe komen we innovatief over?”

Alleen: welk probleem lossen we op, en werkt deze oplossing daadwerkelijk?

We bouwden Joy om daarachter te komen. Met echte architectuur. Echte data. Echte klanten. En de bereidheid om “dit is nog niet klaar” te zeggen als dat zo zou blijken.

Als je nadenkt over het toevoegen van AI aan je product, begin daar. Niet met de tool. Niet met de pitch van een leverancier. Niet met de druk om bij te blijven.

Begin met de vraag. Bouw vanuit het antwoord.

Je klanten verdienen beter dan een FAQ met een gezicht. Ze verdienen een echt gesprek. En uiteindelijk een echt mens. Zorg dat je AI ze daar naartoe leidt, en niet ervandaan.

Als je Deel 1 nog niet gelezen hebt: daar begint het verhaal. Waarom we dit bouwden, wat we leerden van ons mislukken in 2019, en waarom je hier niet komt met een plugin.

Can a conversation be a travel channel? Part 1: We built one to find out.We built a full AI travel interface from scratch, not to say we do AI, but to test whether a conversation can actually be a meaningful channel for personalized travel. This is what it took, why a plugin will never get you there, and why most AI chatbots are just expensive search bars. All Subjects MatterRemco Loup.

We bouwden een AI-aangedreven reisinterface vanaf nul. Geen chatbot. Geen widget. Geen GPT-wrapper met een smiley op een website geplakt. Een volledige conversationele interface met een eigen vector database, een eigen retrieval pipeline, een eigen geheugensysteem en real-time streaming over WebSockets. Niet om iets te vervangen. Om te testen of conversationele AI er echt klaar voor is om een betekenisvol kanaal voor reizen te zijn. Dit is wat we ontdekten, wat het kostte, en waarom we denken dat het meeste van wat er nu is ruis is.

Dit is een verhaal in twee delen. Dit eerste deel gaat over het waarom: welk probleem we oplossen, wat we leerden van eerdere mislukkingen, en waarom een plugin je hier nooit zal brengen. Deel 2 gaat dieper in op de architectuur: de RAG pipeline, het geheugensysteem, de UI/UX-beslissingen en de technische afwegingen die we maakten.

Wat probeer je eigenlijk op te lossen?

Dat is de vraag waar ik steeds op terugkom. Elke keer als een bedrijf zijn nieuwe “AI-powered” feature aankondigt. Elke keer als iemand me vraagt wat wij met AI doen. Elke keer als een leverancier weer een plugin komt pitchen.

Het is op dit moment de belangrijkste vraag in tech. En bijna niemand stelt hem.

In plaats daarvan werkt de hele industrie achterstevoren: men begint met “we moeten iets met AI doen” en gaat dan op zoek naar een plek om het neer te zetten. Bedrijven horen “AI” en horen “innovatie” en denken dat ze achterlopen als ze niet nú iets doen.

De druk om “iets met AI te doen” is luider geworden dan de vraag wat je eigenlijk wilt bereiken.

En wat gebeurt er dan? Bedrijven grijpen de meest zichtbare, meest verkoopbare toepassing die ze kunnen vinden: een chatbot. Op de website plakken. Een naam en een vriendelijk gezichtje geven. Verbinden met een kennisbank. Klaar. “Wij doen nu AI.”

Het probleem: de integratie is altijd beperkt. Sommigen koppelen aan een productdatabase. Sommigen halen live beschikbaarheid op. Maar als plugin is er een plafond aan hoe diep die integratie gaat. Hij werkt altijd met de data die hij krijgt, in het formaat dat de API levert, met de context die de leverancier voldoende vond. Het resultaat is een interactie die aan de oppervlakte conversationeel oogt, maar fundamenteel beperkt blijft in wat hij kan.

En omdat het een plugin is, kan het nooit volledig naadloos zijn. Het blijft altijd een aparte laag bovenop je website, geen onderdeel ervan. Een andere designtaal. Een ander interactiemodel. Een andere ervaring. De klant voelt dat, ook al kan hij het niet onder woorden brengen. Het is het verschil tussen een kamer die als geheel is ontworpen en een kamer waar iemand een kiosk in de hoek heeft gezet.

Een slimmere poortwachter is nog steeds een poortwachter. Je klanten wilden een deur.

We zijn zelf deze weg gegaan. In 2019 bouwden we de eerste versie van Joy op Flow.ai. Een intent-gebaseerde chatbot die natuurlijke taal begreep, reisvoorkeuren uit één zin kon halen en leads genereerde voor onze specialisten. Het werkte. Technisch gezien. Maar de klantbetrokkenheid was te laag om hem in leven te houden. Begin 2022 hebben we Joy uit dienst genomen.

De les was niet dat de technologie slecht was. De les was dat mensen hebben geleerd chatbots te wantrouwen. En terecht. Jarenlang hebben bedrijven chatbots gebruikt als barrière om contact te maken, ook toen ze het tegendeel beweerden. Klanten weten dat. Ze hebben het meegemaakt. Na drie foute antwoorden denk je niet “even opnieuw proberen.” Je denkt “hoe kom ik bij een echt mens?” Sommige mensen doen niet eens de moeite. Ze zien een chatbelletje met een gezichtje en hun eerste reactie is: weg ermee. Niet omdat ze ongeduldig zijn, maar omdat de ervaring hun heeft geleerd dat het tijdverspilling is.

Dat is geen technologieprobleem. Dat is een vertrouwensprobleem. En dat los je niet op door hetzelfde formaat slimmer te maken.

Daar komt bij dat de interface van een chatbot-plugin simpelweg beperkend is. Een klein venster in de hoek van je scherm. Een paar regels tekst. Misschien een knop of twee. Daarin kun je geen rijke productkaarten tonen. Je kunt geen kaart van een reis laten zien. Je kunt iemand niet laten browsen, vergelijken, reizen bewaren voor later. Het formaat dicteert de ervaring, en het formaat is een doos.

Die ervaring is precies waarom we geen nieuwe chatbot hebben gebouwd. Geen slimmere. Geen betere. Iets fundamenteel anders. Een volledige conversationele interface, vanaf nul gebouwd, ontworpen om te inspireren. Waar iemand bestemmingen kan verkennen, reizen kan ontdekken waarvan hij het bestaan niet kende, en waar hij — als hij er klaar voor is — na een gesprek dat echt goed voelde in contact komt met een specialist. Niet na drie mislukte pogingen om langs een poortwachter te komen.

De echte vraag was nooit “hoe voegen we AI toe aan onze website?” De echte vraag is: waar creëert AI echt waarde die eerder niet mogelijk was? Dat zijn we gaan testen.

Waarom ik bouwde wat ik bouwde

Ik heb dit niet gebouwd omdat ik denk dat websites dood zijn, of omdat ik wilde kunnen zeggen dat we “iets met AI doen”. Ik heb eerder geschreven over hoeveel ik een hekel heb aan die mentaliteit.

Ik heb dit gebouwd vanwege een vraag die ik al meer dan een jaar toets: is conversationele AI er echt klaar voor om een echt kanaal te zijn?

In mijn Web 4.0-post schreef ik over het autonome web, een wereld waarin AI-assistenten niet alleen informatie ophalen, maar optreden als onafhankelijke digitale consumenten namens hun mensen. Waar Lisa tegen haar AI-assistent zegt “zoek een reis van twee weken naar Thailand” en de AI via MCP-interfaces contact opneemt met reisorganisaties, onderhandelt, verfijnt en opties presenteert. Zonder dat Lisa ook maar een browser opent.

Dat klinkt misschien alsof de mens uit het plaatje verdwijnt. Dat is niet zo. De techniek maakt volledige autonomie mogelijk. Maar dat betekent niet dat we de mens willen weghalen. Het betekent dat de klant mag kiezen. En onze default is en blijft: naar een mens leiden. Daar later meer over.

Die toekomst komt. Misschien niet morgen, maar hij komt. En als je een reisorganisatie bent die zichzelf serieus neemt, kun je er maar beter op voorbereid zijn.

Dus bouwde ik Joy, een AI-reisassistent voor 333travel. Niet als productlancering, niet als marketingstunt, maar als een serieuze test. Kunnen we een conversatie-interface bouwen die écht waarde toevoegt? Die onze producten begrijpt? Die minder hallucineert? Die een echt nuttige ervaring neerzet als extra kanaal naast onze website, telefoon en e-mail?

Ik heb dit niet gebouwd om onze website te vervangen. Ik heb dit gebouwd om een vraag te beantwoorden: kan een gesprek een betekenisvol kanaal zijn voor gepersonaliseerd reizen?

Wat het eigenlijk is

Laat me concreet zijn over wat Joy doet:

Joy zit bovenop onze volledige productdatabase. Elke rondreis, elk hotel, elke excursie, elke bestemming, allemaal als vectoren geëmbed in een eigen database. Als een klant zegt “ik wil iets avontuurlijks in Zuidoost-Azië, zo’n twee weken, niet te toeristisch,” dan gaat Joy niet keyword-matchen tegen een PDF. Ze doorzoekt semantisch honderden producten, rerankt de resultaten op werkelijke relevantie en komt met opties die echt aansluiten bij de intentie.

En ze onthoudt het gesprek. Niet alleen het laatste bericht, de hele thread. Ze weet welke reizen besproken zijn, wat bewaard is, wat verworpen. Als je zegt “die reis die je eerder noemde met de kookles,” snapt ze wat je bedoelt, ook al noemde ze het zelf een “culinaire ervaring.”

Maar hier zit het cruciale verschil met elke willekeurige chatbot: ze weet niet alleen iets van reizen in het algemeen. Ze kent ónze reizen. Onze specifieke producten. Onze specifieke reisschema’s. Onze bestemmingen die ons team zelf heeft bezocht. Dat kun je niet zomaar met een plugin erop plakken, hoe slim de LLM erachter ook is.

En op het moment dat je menselijk contact wilt? Dan geeft Joy de volledige context door aan een echte reisspecialist die precies weet wat je hebt verkend. Geen “kun je je vraag nog eens omschrijven.” Geen koude overdracht. Volledige continuïteit.

Joy vervangt gesprekken met specialisten niet. Ze maakt ze beter.

Wat ze (nog) niet doet: klantenservicevragen, luchtvaartinformatie of support na boeking afhandelen. Dit is puur een kanaal voor productontdekking en inspiratie. Daar komen we nog wel. Maar we gaan niet doen alsof ze dingen kan die ze niet kan. En eerlijk gezegd: als iemand bij de klantenservice terechtkomt, is er al een probleem. Dat is het slechtst denkbare moment om een machine tussen jou en je klant te zetten. Dan moet je er zelf zijn. Persoonlijk. Dus we zijn nog steeds aan het discussiëren over wat we haar daar laten doen. De nuance zit altijd in de details.

Waarom je hier niet komt met een plugin

Wat wij gebouwd hebben, bereik je niet door een plugin te installeren. Niet met ChatGPT. Niet met een of andere standaard “AI-widget.” Niet met een SaaS-tool die belooft “je website in minuten slimmer te maken.”

En dat komt niet doordat de AI-modellen niet goed genoeg zijn. De modellen zijn prima. Het probleem zit in alles eromheen.

Het hele systeem draait op data die wij zelf bezitten, structureren en beheersen. Elke reis in onze database is door ons eigen team bezocht. Elk reisschema is onze eigen creatie. Elk stuk bestemmingenkennis leeft in onze eigen systemen. Dit is geen data die we van een derde partij licentiëren of uit een brochurecatalogus trekken.

Dat betekent dat we het kunnen embedden. Dat we het precies zo kunnen structureren als we nodig hebben voor semantisch zoeken. Dat we het kunnen bijwerken op het moment dat er iets verandert. Wij beheersen de volledige pipeline, van ruwe productdata naar vector embedding naar retrieval naar antwoord.

Je kunt geen slimme interface bouwen bovenop bergen domme data.

Als je productdata in andermans systeem leeft, als je reizen uit een catalogus doorverkoopt, als je “database” een verzameling PDF’s van touroperators is, dan ben je afhankelijk van welke structuur iemand anders heeft bedacht. Je kunt geen intelligentie bouwen op data die je niet begrijpt of beheerst.

En veel bedrijven starten niet alleen vanaf nul, ze starten met een achterstand. Hun bestaande systemen zijn al onvoldoende. De booking engine is verouderd. De productdata ligt verspreid over spreadsheets en PDF’s. De customer journey heeft overal gaten. En in plaats van die fundamenten te fixen, vinden ze het slim om er een AI-chatbot bovenop te leggen. Alsof intelligentie bovenop disfunctie iets functioneels oplevert. Doet het niet. Het maakt de disfunctie alleen moeilijker te diagnosticeren.

Je lost geen probleem op. Je versiert het.

Wat wij gebouwd hebben, vereiste drie dingen:

Onze eigen data. Elke reis is van ons. Bezocht door ons team. Gestructureerd in onze database. Embedded in onze vector store. Je kunt geen semantic search bouwen over data die je niet zelf structureert.

Onze eigen systemen. Onze eigen backend, frontend, deployment pipeline. Toen we een dual reranker nodig hadden, bouwden we die. Toen we semantic conversation memory nodig hadden, bouwden we het. Toen we een MCP server nodig hadden voor Web 4.0-readiness, bouwden we die. Geen goedkeuring van een vendor nodig. Geen feature requests. Geen afhankelijkheid van andermans roadmap.

De hele keten in eigen hand. Van het moment dat een klant de chat opent tot het moment dat ze met een specialist praten, is elke stap van ons. De AI kent onze producten omdat we de producten zelf hebben gemaakt. De specialist kent het gesprek omdat ons systeem het aan hen doorgeeft.

De AI is de laatste 10% van het werk. De eerste 90% is een bedrijf bouwen dat het kan dragen.

In deel 2 laat ik zien hoe het onder de motorkap echt werkt. De architectuur, de search pipeline, het geheugensysteem dat vele pogingen kostte om goed te krijgen, en waarom 25 seconden wachten aanvoelt als 5 als je het goed ontwerpt.

Can a conversation be a travel channel? Part 2: The technical architectureThe technical deep-dive into how we built Joy: a RAG pipeline with vector search and reranking, a memory system that took four iterations, and the UI/UX decisions that make a 25-second response feel instant. All Subjects MatterRemco Loup.

Ik heb een “productie”-app gebouwd met vibecoding. 97.089 regels gegenereerd. Slechts 25.056 regels haalden productie. Vier complete refactors. De AI faalde niet door slechte prompts. Het faalde omdat AI dingen vergeet, context kwijtraakt en duplicaatlogica creëert, hoe goed je het ook stuurt. Vibecoding gaat er niet om AI voor je te laten bouwen. Het gaat erom dat je je systeem goed genoeg kent om de ruis te filteren. Zonder die kennis ship je alleen maar gissingen.

Wat vibecoding eigenlijk betekent

Mensen denken dat vibecoding betekent dat AI je app bouwt terwijl jij toekijkt. Reality check: dat is helemaal niet het geval als je een daadwerkelijk werkend product nodig hebt met elke keer het verwachte resultaat.

Vibecoding betekent nog steeds dat jij de controle hebt. Je prompt met precisie. Je experimenteert. Je stuurt. Je filtert. Het blijft handwerk, alleen met andere hefboomwerking.

“A fool with a tool is still a fool”

En als je niet weet wat je doet? Dan is het resultaat hetzelfde als altijd: een zooitje. Vibecoding zonder de juiste kennis is gewoon fout. En het grootste probleem met AI is dat het maar blijft produceren: code na code na code. Het doet gewoon wat je vraagt. Het is daar niet kritisch over. Dus als je niet weet wat je doet, spreek je jezelf de hele tijd tegen met geprogrammeerde functionaliteit die nooit samenwerkt binnen je app.

AI is koning in fallbacks. Ik had voor elke mislukte API-call 5 verschillende fallbacks gekregen. Zouden we niet gewoon de juiste manier aan de praat moeten krijgen in plaats van fallbacks bouwen? AI is ook lui: het onderdrukt liever notices dan dat het ze oplost. Zeker als het niet in één keer lukt.

Ik bouwde een productie-app met AI (maar niet dankzij AI)

Ik heb Windsurf gebruikt om een complete applicatie te bouwen. Geen menselijke developers. Geen code die ik direct heb geschreven. We gebruiken Sonnet 4.5 als onze kennisbron.

Het resultaat na veel frustratie: een volwaardig productiespel met backend-logica, login-flows, async data writes, mail queues, admin security, monitoring en cartesische algoritmes die updaten op basis van gebruikersinteractie.

De AI heeft alles geschreven. Ik heb geen enkele regel code aangeraakt. Zelfs de simpelste CSS-wijziging liet ik aan AI over.

Maar wat niemand je vertelt: ik heb het hele project vier keer compleet moeten refactoren. En niet omdat ik slecht promptte. Ik gebruikte KISS-principes, DRY-standaarden, PSR-richtlijnen. We schreven vooraf beslissingen uit en maakten implementatiedocumenten. We gebruikten richtlijnen voor de talen die we gebruikten.

Uiteindelijk maakte het niets uit.

AI vergeet. Het verliest context. Het begint duplicaatfuncties te maken zonder door te hebben dat het die logica al drie files terug schreef. Hoe complexer je project wordt, hoe meer het afdrijft. En hoe vaker het niet in één keer goed gaat, hoe meer AI denkt backwards compatibility te moeten handhaven, waardoor je code nog complexer wordt. Het maakt niet uit hoe je het de eerste keer prompt, of met project rules.

Na vier complete refactors leerde ik: AI vergeet de context niet. Het heeft die nooit gehad ;).

De enige reden dat de definitieve versie werkt, is dat ik precies wist wat ik aan het bouwen was. Ik had het systeem in mijn hoofd. Ik zag wanneer AI zichzelf herhaalde. Ik wist wanneer ik moest stoppen, bijsturen of opnieuw beginnen. Ik controleerde elke file op duplicaat fallback-data, duplicaten enzovoort. Ik gebruikte ook het zeer handige npm-package knip.

https://www.npmjs.com/package/knip

Je kunt niet iets de productie in vibecoden zonder je product te begrijpen. Punt. En je moet accepteren dat bugfixen betekent dat je op AI leunt om het op te lossen zonder iets anders te breken. Veel succes daarmee…

De data vertelt de rest van ons verhaal

Tijdens ons vibecoden produceerde Windsurf:

• 97.089 regels code gegenereerd
• 2.925 prompts verstuurd
• 5.693 credits gebruikt
• 15.734 tool calls (waaronder 7.000 code-edits)

Wat er daadwerkelijk in productie is gegaan:

• 25.056 regels code

Meer dan 70.000 regels zijn geschrapt, vervangen of gerefactord.

Nu denk je misschien: dan moet je AI dus gewoon “beter sturen” of “preciezer prompten”. Dat is niet het punt dat ik wilde maken.

Het punt is: je kunt AI-gebral op dit moment niet voorkomen. Hoe goed je ook prompt. Hoe gestructureerd je aanpak ook is. AI overproduceert. Het genereert redundante code. Het raakt de tel kwijt van wat het al gebouwd heeft. Het creëert ruis. AI is gebouwd om altijd een vorm van AI-verbaal diarree te produceren.

Die 70k+ regels verspilde output? Dat is geen bug. Dat is de huidige staat van vibecoding.

En als je je systeem niet goed genoeg kent om te herkennen wat troep is en wat niet, ship je alles en kun je zelfs met AI niet meer debuggen. Of erger: je besteedt persoonlijk weken aan het debuggen van een codebase die je niet snapt.

De kosten per 1000 credits liggen rond de 35 dollar. De ontwikkeling van dit spel kostte me 210 dollar. Elk bedrijf dat Large Language Models levert verliest geld. De code die ik produceerde had makkelijk 210 x 10 = 2.100 dollar moeten kosten, minimaal. Ik vraag me af of ze dan überhaupt geld verdiend hadden.

Los van het geld: is dit onze kostbare elektriciteit echt waard? Ik ben benieuwd hoe haalbaar dit is als je de echte prijs betaalt.

Wat mensen verkeerd begrijpen

AI is geen magie. Het is een “slimme”, snelle assistent. Maar hij begrijpt niet wat er voor jouw bedrijf telt. Hij heeft geen grip op edge cases, constraints, risico’s, performance-implicaties of security-kwetsbaarheden.

Dat is jouw werk!

In mijn geval hielp AI om iets echts te bouwen. Maar de AI beveiligde het adminpaneel niet. Die mail queue-logica ontwierp hij niet. Hij besliste niet wanneer async writes gedebounced moesten worden. Dat deed ik. Door kritisch te zijn en de juiste vragen te stellen dankzij bouwervaring van vroeger.

Zonder die richting was het hele ding in elkaar gestort.

En ik zie dit patroon overal. Teams die AI-producten bouwen zonder ownership of richting, alleen maar om te kunnen zeggen dat ze “iets met AI gedaan hebben”. Dat is oppervlakkig. Dat is broos. Het schaalt niet.

“You’re not building products. You’re laundering prompts into deployments”

Hoe vaak hoor je niet van bovenaf: we moeten iets met AI doen. We raken achter. Achter op wat?

De customer service-val

Dan is er nog de hype rond AI voor klantenservice. Bedrijven beweren dat het perfect is voor 24/7 support, snellere antwoorden, minder mensen nodig.

Maar als je een bot nodig hebt om met je klanten te praten, ligt je echte probleem waarschijnlijk ergens anders. AI repareert kapotte processen niet. Het verstopt ze. Tijdelijk.

Als je minder menselijk contact als winst ziet, heb je al verloren. Als het beantwoorden van vragen lang duurt, moet je misschien ergens anders kijken waarom mensen zoveel vragen hebben, en dat eerst verbeteren.

Het eigenlijke punt

Vibecoding is gewoon weer een tool. Meer niet. Wel een heel give tool in de juiste handen, maar toch een tool. En vooral goed voor prototyping. Maar met een flinke dosis kennis kun je er misschien standalone apps mee bouwen die écht werken, die je op z’n minst zelf kunt testen en waarvan het resultaat op een transparante manier te herleiden is naar de geschreven code.

Het vervangt geen denken. Het zou je denken moeten versterken, en het zou je niet minder moeten laten nadenken.

Goed gebruikt kan het krachtig zijn. Maar je moet nog steeds weten wat je wilt bouwen. Je moet de structuur ownen. Je moet de ruis filteren. Je moet AI-geklets herkennen als je het ziet. Je moet het proces leiden.

Anders bouw je geen prototype. Dan genereer je alleen gokken.

De toekomst is niet AI-first. De bedrijven die ertoe doen blijven human-first. Zij begrijpen het probleem voordat ze een tool kiezen. En ze blijven de enige vraag stellen die telt, voordat ze AI te hulp roepen:

Wat lossen we nu eigenlijk op?

Artificial Intelligence is er om te blijven, daar gaat het hier niet over.

Het probleem is dat iedereen over AI praat, maar dat weinig mensen nadenken over hoe je het écht goed inzet. Ergens onderweg is “wij gebruiken AI” een marketingterm geworden in plaats van een technische beslissing. Iedereen wil meedoen met de AI-golf, anders hoor je er niet bij. Als je de big tech moet geloven, die het iedereen door de strot probeert te duwen.

Maar als je een klein stapje terugneemt, valt iets vreemds op:

Bedrijven lossen met AI problemen op die ze eigenlijk nooit hadden mogen hebben.

Slecht ontworpen systemen, ontbrekend ownership en spaghetti-infrastructuur worden nu “opgelost” door er LLM’s bovenop te gooien. Met als gevolg dat systemen nog moeilijker te onderhouden zijn, duurder worden en lastiger te begrijpen.

Deze blog gaat niet over AI afkraken.
Het gaat over helder nadenken, technisch ownership en de juiste tools voor de klus gebruiken.

Onderzoeksrapport OpenAI

Recent onderzoek van OpenAI en Georgia Tech benadrukt een kernwaarheid die vaak genegeerd wordt: AI-hallucinaties, die momenten waarop modellen dingen verzinnen, zijn geen bugs. Ze zijn een wiskundig gevolg van hoe deze systemen gebouwd zijn.

Zelfs met perfecte trainingsdata beloont de huidige architectuur van generatieve AI zelfverzekerde antwoorden boven het toegeven van onzekerheid. Dat betekent dat hallucinaties niet alleen vaak voorkomen, ze zijn onvermijdelijk, tenzij we fundamenteel veranderen hoe we deze modellen trainen en evalueren.

Zoals de onderzoekers het formuleren: “Hallucinations are mathematically inevitable.” (bron)

Hoe mensen AI misbruiken om de verkeerde problemen op te lossen

Laten we een stap terugnemen.

Als je $1.200 per maand betaalt aan GPT-4 om e-mailtekst te parsen, telefoonnummers te extraheren, JSON te herformatteren en strings naar hoofdletters te zetten… dan innoveer je niet. Dan besteed je gezond verstand uit aan een dure black box.

Ja, iemand deed dit recentelijk, en besefte te laat wat het kostte. Die persoon stapte toen over op GPT-4o-mini en bracht de rekening terug naar $200… Maar ook dan is het nog steeds een kutoplossing:

Die taken hadden helemaal geen AI nodig. Gewoon basale softwarekennis.

Dit is geen uitzondering. Het gebeurt helaas vaak.

Mensen denken dat AI hun oplossing voor alles is, terwijl het alleen de incompetentie van de persoon blootlegt, want:

• Het verhoogt de kosten
• Het verbergt wat er werkelijk gebeurt
• Het introduceert verborgen afhankelijkheden
• Het maakt systemen vrijwel onmogelijk te debuggen en onderhouden

AI wordt gebruikt om een gebrek aan systeemontwerp te maskeren, niet om het te verbeteren.

AI als natural language interface, krachtig maar verkeerd gebruikt

Maar laten we eerlijk zijn: LLM’s zijn écht krachtig als je ze goed inzet.
Ze laten je in natuurlijke taal beschrijven wat je wilt, en geven dan een resultaat, zonder dat je de onderliggende logica hoeft te begrijpen.

Dat maakt AI een fantastische tool voor:

• Prototyping
• Werken met grote kennisbanken
• Het samenvatten van ongestructureerde data
• Fuzzy matching op grote schaal

LLM’s zijn in wezen een nieuw soort interface, net zoals de command line, de GUI of API’s dat eerder waren.

Maar ze zijn geen magie. En zeker niet gratis. En bijna altijd is het niet de beste manier om een probleem op te lossen.

Hoe kritischer de functie, hoe belangrijker het wordt om te snappen:

• Wat wordt er uitgevoerd?
• Waar stroomt de data naartoe?
• Wie is eigenaar van de output?
• Wat zijn de werkelijke kosten?

Conversational AI, de moderne chatbot, maar nog steeds een chatbot

Er is een weg vooruit voor conversational AI. Alleen is dat niet de revolutionaire sprong die mensen ervan verwachten, met zelfdenkende systemen die niet hallucineren en altijd het juiste antwoord geven.

Ja, LLM’s kunnen slimmere, menselijkere antwoorden geven dan vóórdat LLM’s mainstream werden.
Ja, ze kunnen supportflows automatiseren die voorheen veel complexer waren om te scripten.

Maar laten we onszelf niets wijsmaken:

Mensen willen nog steeds echt, menselijk contact met je bedrijf, zeker als er iets misgaat.

Als je je volledige klantenservice uitbesteedt aan een AI-assistent, stuur je een duidelijke boodschap (in mijn ogen de verkeerde):

• “Het kan ons niet genoeg schelen om zelf met je te praten.”
• “Jij bent de tijd van een echt persoon niet waard.”
• “Wij verkopen alleen ons product. Kom alsjeblieft niet bij ons zeuren.”

Op korte termijn bespaart dat misschien kosten.
Maar op lange termijn? Dan vernietig je het vertrouwen in je merk. Zeker omdat mensen doorgaans contact opnemen met de klantenservice als:

• Ze gefrustreerd zijn
• Ze iets niet begrijpen
• Ze een klacht hebben

Dat is niet het moment om ze een chatbot voor te schotelen, hoe “slim” die ook klinkt.

Goede klantenservice is een relatie, geen kostenpost.

Dus ja, gebruik conversational AI om je teams te ondersteunen. Maar laat het menselijk contact niet vervangen waar empathie nodig is. Maak AI niet de interface waarmee klanten met je bedrijf praten, als je om je product geeft.

Waar je AI wél voor zou moeten gebruiken

Laten we het omdraaien. Wat is dan een goede use case voor AI?

Je zou AI moeten gebruiken als:

• Het je helpt dingen te doen die voorheen te duur, te traag of technisch te complex waren
• Je je architectuur al geoptimaliseerd hebt, maar nog edge cases hebt die automatisering waard zijn
• Je processen verrijkt, in plaats van technische schuld verbergt

Bijvoorbeeld:

• Prototypen van lastige functionaliteiten, zodat je sneller uitkomsten kunt testen
• Productzoek verbeteren met semantisch begrip
• Als je hallucinaties zichtbaar kunt maken in data, zijn ze perfect voor BI (business intelligence)
• Gepersonaliseerde samenvattingen genereren van grote interne rapporten
• Telefoongesprekken transcriberen en samenvattingen maken
• Image to text, zodat je beter semantisch kunt zoeken in grote beelddatabases.

Dit zijn taken waar AI echt uitblinkt, omdat ze in traditionele systemen nog duurder, lastiger of onmogelijk op te lossen waren.

Maar nogmaals: weeg altijd de kosten af. Niet alleen in euro’s, maar ook in duidelijkheid, controle en klantbeleving. Probeer het altijd eerst op te lossen zonder AI.

Technische volwassenheid bepaalt wie er wint

Dit is de kern:

Bedrijven met moderne, begrijpelijke en goed gedocumenteerde infrastructuur en data winnen. Wie AI blijft stapelen bovenop zijn chaos… verliest.

Het gaat er niet om hoe vroeg je met AI begon. Het gaat om:

• Of je stack onderhoudbaar is
• Of je teams die echt begrijpen
• Of je kunt redeneren over kosten, performance en falen
• Of je eigenaar bent van je data, je architectuur en je roadmap

De bedrijven die AI zien als een nieuw algoritme/interface om problemen op te lossen die ze eerder niet konden oplossen, halen volgens mij op de lange termijn de meeste waarde eruit. Gebruik AI niet voor de marketingwaarde die big tech je wil aanpraten.

Data-eigendom uitbesteden is een strategisch risico

Ik eindig met nog een praktijkvoorbeeld dat ik recent tegenkwam.

Een bedrijf in de reisbranche bouwde een app waarmee eindgebruikers hun reisgegevens kunnen inzien. Die verkopen ze weer aan andere reisorganisaties en touroperators. Haalbaar, als je ziet hoe slecht de IT in travel er meestal voor staat.

De reisorganisatie kan de app dus aanbieden met alle vouchers en reisschema’s van de reis van hun klant. Tot zover niets raars, behalve dat je al je documenten uitbesteedt aan een derde partij.

Die app-aanbieder heeft nu toegang tot veel van je cruciale bedrijfsinformatie. En dan koopt de klant extra services in de app (verzekeringen, transfers, upgrades). Je zou denken: dat is upsell voor de reisorganisatie die de klant heeft.

En dan komt de knuppel in het hoenderhok. Het platform geeft opeens commissie aan de touroperator… Biedt de app-aanbieder nu ook extra services aan jouw klant?

Wie is er nu eigenaar van de klant?

Dat is een grote verschuiving, en een gevaarlijke. Hoe meer infrastructuur je uitbesteedt, hoe meer controle je verliest over je klantrelaties en je first-party data.

Blijf zelf de klantjourney van je eigen klant regelen. Bescherm je toegevoegde waarde. Word geen commodity. En houd het persoonlijk.

Dit wordt een enorm probleem! En AI versnelt het proces als reisbedrijven niet opletten.

Conclusie: AI is een tool, geen strategie voor de meeste bedrijven

AI is indrukwekkend. Maar het vervangt de fundamenten niet.

Gebruik het niet om slechte architectuur te verbergen. Gebruik het niet als excuus om technische beslissingen te vermijden. Laat het niet verhullen wat je systemen doen, of wie je klant eigenlijk is.

In plaats daarvan:

• Wees eigenaar van je stack
• Begrijp je eigen logica
• Gebruik AI waar het echte, meetbare waarde creëert
• En blijf altijd zelf nadenken

De echte innovatie zit niet in de tool. Die zit in hoe helder je nadenkt over de problemen die je moet oplossen.

Al decennia passen bedrijven zich aan aan de evolutie van ons internet. Eerst was er Web 1.0, een read-only internet waar bedrijven statische websites bouwden. Daarna brak met Web 2.0 het interactieve tijdperk aan: social media, user-generated content en API’s waarmee apps met diensten konden verbinden. Nu leven we in het tijdperk van Web 3.0, waar AI personalisatie verbetert, taken automatiseert en context begrijpt.

Maar dit is nog maar het begin.

De volgende fase, Web 4.0, brengt iets nog ingrijpenders: AI als autonome digitale agent. In plaats van mensen alleen te assisteren, gaat AI actief zaken doen met bedrijven—beslissingen nemen, deals onderhandelen en transacties uitvoeren, allemaal met minimale menselijke tussenkomst.

Ik noem dit het autonome web: een wereld waarin AI-assistenten niet alleen informatie ophalen, maar optreden als onafhankelijke digitale consumenten in dienst van hun mensen. En bedrijven die zich niet op deze verschuiving voorbereiden, lopen het risico onzichtbaar te worden in deze generatie digitale handel.

De verschuiving naar AI-gedreven interacties

Jarenlang hebben bedrijven hun content geoptimaliseerd voor menselijke gebruikers. Websites, apps en API’s waren allemaal ontworpen met de aanname dat een persoon de uiteindelijke beslissing nam. Die aanname valt nu uiteen.

De evolutie van digitale interactie:

• Web 1.0: statische websites (bedrijven bieden informatie, gebruikers consumeren die).
• Web 2.0: het interactieve web (social media, API’s, mobiele apps).
• Web 3.0: het intelligente web (AI-gedreven personalisatie, automatisering en semantisch zoeken).
• Web 4.0: het autonome web (AI-agenten die optreden als klanten, onderhandelen, transacties uitvoeren en zelfstandig beslissingen nemen).

We zijn nu in de overgang naar Web 4.0, waar AI-agenten complexe, real-time interacties gaan afhandelen—zoals reizen boeken, prijzen onderhandelen en zelfs diensten dynamisch aanpassen op basis van gebruikersgedrag. Bedrijven die zich niet aanpassen aan dit AI-first interactiemodel worden simpelweg buitengesloten van AI-gedreven besluitvorming.

Waarom API’s alleen niet genoeg zijn

Veel bedrijven denken misschien dat ze klaar zijn voor AI-gedreven interacties omdat ze API’s hebben. Maar traditionele API’s zijn gebouwd voor gestructureerde, vooraf gedefinieerde verzoeken—ontworpen voor apps, niet voor AI-agenten die contextbewuste interacties in meerdere stappen nodig hebben.

Hier komen ontwikkelingen zoals het Model Context Protocol (MCP) om de hoek kijken.

MCP wordt een van de ontbrekende schakels waarmee AI-assistenten met bedrijven kunnen interacteren alsof ze menselijke klanten zijn. In tegenstelling tot traditionele API’s die statische antwoorden teruggeven, maakt MCP het volgende mogelijk:

• Dynamische serviceverzoeken (AI kan om specifieke aanpassingen vragen).
• Onderhandeling en refinement (AI kan criteria bijstellen op basis van voorkeuren en beperkingen).
• Autonome besluitvorming (AI kan een transactie afronden zonder menselijke bevestiging).

De bedrijven die AI-native interfaces omarmen, domineren de Web 4.0-economie. De rest wordt genegeerd—niet door mensen, maar door AI-gedreven agenten die aankoopbeslissingen nemen voor hun mensen.

Een volledig AI-gedreven transactie bij 333Travel

Bij 333Travel verkopen we geen kant-en-klare vakanties. Elke reis is tailor-made en vraagt heen-en-weer-interactie om je perfecte reis samen te stellen. Vandaag gebeurt dat via webformulieren, e-mail en telefoongesprekken. In Web 4.0 ziet dat er heel anders uit, en al die kanalen worden gecombineerd met een gesprek met een AI-assistent als optie.

Een nieuw soort reisinteracties

Stel je een reiziger voor, Lisa, die een op maat gemaakte reis naar Thailand wil. In plaats van een website te bezoeken, een formulier in te vullen of een agent te bellen, zegt ze het gewoon tegen haar AI-assistent:

“Ik heb vakantie nodig. Zoek voor mij een tailor-made reis van twee weken naar Thailand met een mix van luxe en boutique hotels, wat avontuurlijke activiteiten en tijd om te ontspannen. Ergens half juni.”

Lisa opent nooit een website. Haar AI-assistent doet het werk voor haar.

Stap 1: De AI stuurt een intelligent verzoek

Lisa’s AI benadert de MCP-interface van 333Travel via een zoekopdracht en stuurt een gestructureerd verzoek mee met haar voorkeuren, eerdere reisgeschiedenis en budgetbeperkingen.

Stap 2: AI en het systeem van 333Travel onderhandelen en verfijnen de reis {#step-2-ai-and-333travel%E2%80%99s-system-negotiate-and-refine-the-trip}

Omdat 333Travel gespecialiseerd is in tailor-made ervaringen, begint er een realtime onderhandelingsproces tussen Lisa’s AI en de MCP-integratie van 333Travel:

1. AI stuurt het initiële verzoek
   • “Gebruiker wil naar Thailand, mix van luxe en boutique hotels, wat avontuur, wat ontspanning.”
2. De MCP van 333Travel antwoordt dynamisch
   • “Aanbevolen route: Bangkok, Chiang Mai, Koh Samui.”
   • “Luxe opties: The Siam Bangkok, Anantara Chiang Mai, Four Seasons Koh Samui.”
   • “Boutique opties: Sala Rattanakosin, Tamarind Village, The Library Koh Samui.”
3. Lisa’s AI verfijnt het verzoek
   • “Ze heeft eerder in een Four Seasons gelogeerd en die hoog gewaardeerd—geef die prioriteit.”
   • “Ze houdt van culturele ervaringen—voeg een foodtour in Bangkok en een tempelbezoek in Chiang Mai toe.”
   • “Budgetplafond: €5.000—pas dat aan.”
4. 333Travel maakt vervolgens een gepersonaliseerd voorstel op basis van alle informatie die normaal in een telefoongesprek binnenkomt.
   • Er worden drie route-opties met Lisa’s AI besproken, gerangschikt op prijs, luxeniveau en balans in activiteiten.

Stap 3: De AI bevestigt de boeking en maakt die definitief

Lisa zelf bekijkt de samenvatting en zegt:

“Boek de tweede optie en voeg een luchthaventransfer toe.”

Haar AI-assistent: ✔️ Rondt de boeking met 333Travel af ✔️ Regelt de betaling automatisch ✔️ Stuurt een bevestiging naar haar e-mail en agenda

Lisa heeft nooit een website bezocht. Nooit een e-mail gestuurd. Nooit een reisagent gebeld.

Het autonome web kan alles afhandelen, maar Lisa kan op elk moment instappen en alsnog dat telefoongesprek aangaan.

De verschuiving naar Web 4.0 verandert volledig hoe bedrijven met klanten omgaan.

Wat dit betekent voor bedrijven

De belangrijkste punten:

1. AI-gedreven transacties kunnen de nieuwe norm worden

Wie niet is geoptimaliseerd voor AI-first interacties, maakt geen deel uit van AI-gedreven aankoopbeslissingen.

2. AI-optimalisatie vervangt traditionele SEO

Net zoals bedrijven zich eerder optimaliseerden voor hun positie in Google-zoekresultaten, moeten ze zich nu optimaliseren voor AI-gedreven ontdekking—ervoor zorgen dat hun diensten zo zijn gestructureerd dat AI-agents ze begrijpen en ermee kunnen werken.

3. AI-native interfaces worden het volgende concurrentievoordeel

Bedrijven die AI-ready endpoints bouwen met MCP-achtige protocollen, domineren waarschijnlijk het vroege Web 4.0-landschap.

4. Klanten verwachten wrijvingsloze ervaringen

Als een AI binnen enkele seconden een complete reisroute kan aanvragen met gedetailleerde informatie, waarom zou je daar dan geen gebruik van maken en het combineren met de normale menselijke interactie? Je hebt zojuist een extra verkoopkanaal gecreëerd, naast mail, een appje, een website of een telefoongesprek.

Het autonome web is er al. Ben je er klaar voor?

Web 4.0 is geen toekomstmuziek—het gebeurt nu. AI helpt klanten niet meer alleen; het handelt namens hen.

Bedrijven die zich er vandaag op voorbereiden, staan klaar aan het begin van de Web 4.0-economie. Wie het negeert, wordt simpelweg overgeslagen—niet door menselijke klanten, maar door hun AI-gedreven agents.

De vraag is niet meer óf AI-gedreven klanten het bedrijfsleven gaan veranderen, maar of je er klaar voor bent om ze te bedienen wanneer het zover is.

Waarom 333travel de standaard zet in een door AI gedreven wereld

De wereld verandert in hoog tempo. Met de opkomst van AI-modellen zoals ChatGPT, ClaudeAI en Gemini is toegang tot data en inzichten makkelijker dan ooit. Zelfs bedrijven zonder echte reisexpertise proberen de markt te betreden door andermans product te gebruiken met alleen technologie. Maar wat onderscheidt 333travel van deze “digital dropshippers”? Simpel: onze eigen technische kennis, onze passie en VOLLEDIGE controle over ons EIGEN product, zoals je hieronder kunt lezen.

We zijn niet zomaar een reisorganisatie; we zijn ook een IT-bedrijf, gebouwd op expertise en betrouwbaarheid.

Bij 333travel combineren we mensen en technologie, innovatie en authenticiteit, en blijven we de onbetwiste keuze—ook in een wereld waar AI elke dag zichtbaarder wordt.

Generieke AI vs. zelf getrainde AI

Niet alle AI is hetzelfde. Publieke AI-modellen, zoals de bovengenoemde, bieden standaardoplossingen die getraind zijn op publiek beschikbare data. Daardoor zijn ze toegankelijk en kunnen ze functioneren als een nieuw verkoopkanaal. Wij zorgen ervoor dat deze generieke AI-oplossingen uiteindelijk bij ons terechtkomen voor hun reisbehoeften—vanwege onze bewezen expertise.

Maar we zijn al een flink aantal stappen verder. We onderzoeken al geruime tijd hoe zelf getrainde AI, gevoed met onze unieke bedrijfsdata, onze interne processen kan optimaliseren en versnellen. Eén ding is voor ons duidelijk: AI vervangt ons DNA, onze persoonlijke touch en onze klantenzorg niet. Het is een fantastisch hulpmiddel, een “slim notitieboekje” dat onze specialisten ondersteunt. Of het nu gaat om het stroomlijnen van administratieve taken, snellere analyses of hulp bij complexe vragen—het stelt onze reisexperts in staat zich te richten op wat er echt toe doet: persoonlijke service en klanttevredenheid.

Omdat de balans tussen AI en menselijke interactie voor ons cruciaal is, zorgen we er altijd voor dat de menselijke touch het hart van onze klantrelaties blijft. Reizen gaat over emoties, passie en echte verbinding—iets wat geen AI voor ons ooit volledig zal vervangen.

AI als katalysator, geen vervanging

AI is een krachtig hulpmiddel, maar het zal onze expertise en ervaring niet vervangen. Waar sommige bedrijven AI inzetten om generieke reisaanbiedingen te maken op basis van andermans data, blijven wij het vertrouwde aanspreekpunt waar zowel mensen als AI-assistenten hun reizen boeken. Waarom? Omdat zelfs AI, als het het beste resultaat voor zijn gebruiker nastreeft, herkent dat 333travel de standaard zet voor complete, zorgeloze reiservaringen en unieke, actuele informatie.

Wat ons onderscheidt:

Actuele kennis: Onze specialisten hebben de bestemmingen zelf bezocht en weten meer dan wat er online te vinden is.

Lokale partnerschappen: In elk land dat we aanbieden, staan we met onze voeten op de grond. We werken nauw samen met onze lokale partners om op de hoogte te blijven. Het maakt niet uit naar welk land je met ons reist. Wij weten altijd het beste hoe we je kunnen helpen, omdat de hele reis ook door ons wordt verzorgd.

Volledige controle: Onze eigen IT-capaciteiten stellen ons in staat onafhankelijk te opereren. We beheren onze eigen data, ontwikkelen onze eigen systemen en kunnen zelfs onze eigen AI-modellen trainen met onze unieke expertise. IT zit diep verankerd in ons DNA—in tegenstelling tot veel andere reisorganisaties die afhankelijk zijn van derden.

Passie voor reizen: Onze reizen zijn niet alleen logisch in elkaar gezet; ze zijn ontworpen om dromen waar te maken.

Wij zorgen ervoor dat je zorgeloos van je reis kunt genieten

De risico’s van “digital dropshipping” {#the-risks-of-%E2%80%9Cdigital-dropshipping%E2%80%9D}

In deze door AI gedreven wereld bieden sommige bedrijven reisproducten aan zonder ze echt te begrijpen, puur door data slim te combineren. Deze aanpak lijkt op dropshipping—producten van derden verkopen zonder echte kennis of controle. Maar hoe creëer je echte waarde zonder diepgaande expertise in je product?

Stel je voor dat je een keuken samenstelt door elk onderdeel bij een andere leverancier te bestellen. Dat klinkt misschien goedkoop en efficiënt, maar wat gebeurt er als de onderdelen niet passen? Wie is verantwoordelijk als er iets misgaat? Bij 333travel zorgen we ervoor dat dit soort problemen nooit ontstaan. Wij leveren een naadloos, compleet product met volledige verantwoordelijkheid en gemoedsrust, zodat je zorgeloos van je reis kunt genieten.

Waarom 333travel de beste keuze is—zelfs voor AI {#why-333travel-is-the-best-choice%E2%80%94even-for-ai}

In de toekomst zullen AI-assistenten steeds vaker reizen aanbevelen op basis van data. Maar zelfs AI zal al snel inzien dat een geslaagde reis afhangt van meer dan alleen rauwe data. Bij 333travel leveren we een ervaring die AI kan herkennen—maar niet zelf kan creëren. AI heeft ons nodig om het voor hen te regelen en te boeken.

Unieke bestemmingenkennis: Wij begrijpen de nuances en details die in geen enkele database staan.
End-to-end service: Van de eerste vraag tot ondersteuning na de reis staan we altijd voor onze klanten klaar.
Betrouwbare data en systemen: Onze eigen geavanceerde IT-oplossingen en data zorgen ervoor dat alles accuraat, actueel en uitvoerbaar is.

AI boekt geen reis bij een bedrijf dat risico’s vormt of generieke oplossingen biedt.

Ook in de toekomst kiest AI voor zekerheid, kwaliteit en betrouwbaarheid—dus kiezen voor 333travel.

Hoe AI ons versterkt

Wij zien AI niet als concurrent, maar als hulpmiddel. Bij 333travel gebruiken we technologie om onze processen te stroomlijnen en onze service te verbeteren, terwijl de focus op menselijke expertise blijft. Een paar voorbeelden:

Efficiënte processen: AI helpt ons sneller patronen en trends te herkennen, waardoor we slimmer werken en onze klanten beter antwoord kunnen geven.
Betere reisvoorstellen: Onze eigen data en kennis zorgen ervoor dat elk voorstel persoonlijk en uniek is—AI versnelt het proces, maar baseert zich altijd op onze zelfgeschreven content.
Betere communicatie: Chatbots en AI-assistenten ondersteunen ons team op de achtergrond, waardoor we meer tijd hebben voor direct, persoonlijk contact met reizigers.

Wat ons uniek maakt, is onze passie, authenticiteit en menselijke aanpak—gecombineerd met onze volledig eigen IT-backbone, die ons nu meer dan ooit onderscheidt van de rest.

Om echt innovatief te zijn, moet je volledige controle hebben over je eigen bedrijfskritische processen.

De toekomst van reizen: 333travel als de onbetwiste keuze

De reisbranche verandert. Technologie krijgt een steeds grotere rol, maar de kern blijft hetzelfde: het verlangen naar unieke, onvergetelijke ervaringen. Bij 333travel combineren we het beste van twee werelden—de kracht van technologie met de warmte van menselijke expertise.

De grootste uitdaging in de reissector ligt bij bedrijven die voor AI-implementaties afhankelijk zijn van derden, of bij bedrijven die beweren data te “bezitten” terwijl ze slechts generieke AI-resultaten herverpakken.

Wij positioneren ons als het centrale aanspreekpunt—voor zowel mensen als AI-assistenten—door consequent de hoogste kwaliteit te leveren. Of je nu droomt van een tropisch strand of een cultureel avontuur, bij ons ben je in goede handen. Wij beheren de hele keten, van data-analyse tot persoonlijke service, zodat je reis niet alleen perfect is, maar ook zorgeloos en onvergetelijk.

Conclusie

AI verandert het spel, maar bij 333travel blijven we ons onderscheiden. Onze unieke combinatie van actuele kennis, passie en volledige controle over ons product maakt ons dé keuze voor elke reiziger. Of je ons nu bereikt via persoonlijk contact of via een AI-assistent, één ding is zeker: bij 333travel boek je niet zomaar een reis—je krijgt een complete ervaring.

Hoe blijf je uniek in een wereld die steeds meer door technologie wordt gedreven? Wij doen het door onze data continu te verbeteren, AI op slimme manier in te zetten en ervoor te zorgen dat reizigers nog steeds bij ons komen om hun reis werkelijkheid te maken—net als vroeger.

In een wereld vol DHCP-adressen is externe toegang tot je pc of server thuis een gedoe. Heb je een provider die je een dynamisch publiek IP-adres toewijst, dan heb je een probleem: je IP verandert regelmatig, en daarmee breekt de verbinding met je apparaat thuis via een statisch domein.

Dit gratis Dynamic DNS (DDNS) updater script voor TransIP lost dat op. Het actualiseert je DNS-records zodra je externe IP verandert, zodat je domein (bijv. vpn.example.com) altijd naar het juiste IP wijst. Dit script is een must voor iedereen die TransIP’s DNS-diensten gebruikt.

Belangrijkste features van het script

1. Geautomatiseerde DNS-updates:
   • Controleert automatisch je huidige externe IP en vergelijkt dat met het DNS A-record van je domein.
   • Maakt het A-record aan of werkt het bij zodat het overeenkomt met je nieuwste externe IP.
2. Dynamic DNS voor dynamische IP’s:
   • Ideaal voor situaties waarin je publieke IP regelmatig verandert, zoals een internetverbinding thuis met dynamische DHCP-toewijzing.
3. Veilige authenticatie:
   • Gebruikt TransIP’s API met een private key voor veilige communicatie.
   • Genereert kort geldige tokens voor extra veiligheid (maximaal 10 minuten per sessie).
4. Aanpasbare instellingen:
   • Configureer eenvoudig domein, subdomein, TTL (time-to-live) en logging.
   • Pas het script aan naar je eigen wensen.
5. Logging en foutafhandeling:
   • Uitgebreide logging houdt elke stap van het updateproces bij.
   • Ingebouwde foutafhandeling voor een soepelere uitvoering en makkelijker debuggen.

Hoe het werkt

1. Initiële setup:
   • Maak een TransIP-account aan en genereer een private key voor API-toegang op https://www.transip.nl/cp/account/api/
   • Configureer het script met je domeinnaam, subdomein en het pad naar je private key.
2. Extern IP ophalen:
   • Het script haalt je huidige externe IP op via een publieke API zoals ipinfo.io.
3. Token genereren:
   • Genereert een kort geldig access token via TransIP’s authenticatie-endpoint.
4. DNS-record controleren:
   • Controleert of het huidige DNS A-record overeenkomt met je externe IP.
   • Verschilt het, dan werkt het script het record bij; ontbreekt het, dan maakt het een nieuw aan.
5. DNS updaten:
   • Gebruikt TransIP’s beveiligde API om het DNS A-record bij te werken of aan te maken met je huidige externe IP.
6. Logging en meldingen:
   • Logt elke stap en geeft duidelijke meldingen als er iets misgaat.

Vereisten

Voordat je het script gebruikt, zorg dat je het volgende hebt:

1. Een TransIP-account met API-toegang ingeschakeld.
2. Een geregistreerd domein in je TransIP-account.
3. Een statische private key voor veilige API-authenticatie.
4. De benodigde dependencies op je systeem:
   • curl, openssl en jq.

sudo apt update
sudo apt install -y curl openssl jq

Waarom deze oplossing?

In tegenstelling tot betaalde externe DDNS-providers geeft dit script je gratis controle over je eigen DNS-beheer, met privacy en zonder vendor lock-in. Het is op maat gemaakt.

#!/bin/bash

# Configuration settings
LOGIN_NAME="your-login-name"  # Fill in your TransIP login name
PRIVATE_KEY_PATH="/path/transip_private_key.pem"  # Path to your private key file
AUTH_URL="https://api.transip.nl/v6/auth"
TOKEN_FILE="/var/tmp/transip_token.json"  # File to store token and expiration date
DOMAIN="example.com"  # Your main or test domain
SUBDOMAIN="vpn"  # The subdomain you want to update (e.g., test.example.com)
RECORD_TYPE="A"
TTL=60  # Time-to-live for DNS records
LOG_FILE="/var/log/transip_dyndns.log"

# Function to update a log file
log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" > $LOG_FILE
}

# Function to log an error and stop the script
handle_error() {
    log_message "ERROR: $1"
    echo "ERROR: $1" >&2
    exit 1
}

# Function to obtain a new access token with a short validity period (10 minutes)
generate_new_token() {
    log_message "Generating a new token with a validity period of 10 minutes."
    NONCE=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 16)
    TIMESTAMP=$(date +%s)
    LABEL="Set DNS to external DHCP $TIMESTAMP"
    REQUEST_BODY=$(printf '{"login":"%s","nonce":"%s","read_only":false,"expiration_time":"10 minutes","label":"%s","global_key":true}' "$LOGIN_NAME" "$NONCE" "$LABEL")
    log_message "Request Body: $REQUEST_BODY"
    SIGNATURE=$(echo -n "$REQUEST_BODY" | openssl dgst -sha512 -sign "$PRIVATE_KEY_PATH" | base64 | tr -d '\n')
    log_message "Generated signature: $SIGNATURE"
    RESPONSE=$(curl -s -X POST "$AUTH_URL" \
        -H "Signature: $SIGNATURE" \
        -H "Content-Type: application/json" \
        -d "$REQUEST_BODY") || handle_error "Failed to connect to TransIP API"
    log_message "API-response received: $RESPONSE"
    ACCESS_TOKEN=$(echo "$RESPONSE" | jq -r '.token // empty')
    if [ -z "$ACCESS_TOKEN" ]; then
        handle_error "The received access token is empty or invalid. Check the API-response: $RESPONSE"
    fi
    log_message "Received token: $ACCESS_TOKEN"
}

# Function to get the current DNS A-record from TransIP
get_dns_record() {
    # Get API response and store status code
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Check if response contains JSON and no errors
    if echo "$RESPONSE" | jq empty 2>/dev/null; then
        RECORD_CONTENT=$(echo $RESPONSE | jq -r '.dnsEntries[] | select(.name=="'$SUBDOMAIN'" and .type=="'$RECORD_TYPE'") | .content')
    else
        handle_error "API response does not contain valid JSON or contains an error: $RESPONSE"
    fi

    # Check if we found a valid record
    if [ -z "$RECORD_CONTENT" ]; then
        log_message "No valid DNS record found for $SUBDOMAIN.$DOMAIN. Record may need to be created."
        return 1
    fi

    echo "$RECORD_CONTENT"
    return 0
}

# Function to update or create DNS record
update_or_create_dns_record() {
    # Check if record exists
    CURRENT_DNS_IP=$(get_dns_record)

    if [ -z "$CURRENT_DNS_IP" ]; then
        log_message "No DNS A-record found for $SUBDOMAIN.$DOMAIN. Creating record."
        # Create request body for new record (TTL set to 60 seconds)
        DNS_ENTRY=$(jq -n \
        --arg name "$SUBDOMAIN" \
        --arg expire "60" \
        --arg type "$RECORD_TYPE" \
        --arg content "$CURRENT_IP" \
        '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

        log_message "DNS entry (create): $DNS_ENTRY"

        # Execute POST request to create new DNS entry with better status code handling
        RESPONSE=$(curl -s -w "%{http_code}" -X POST \
            -H "Authorization: Bearer $ACCESS_TOKEN" \
            -H "Content-Type: application/json" \
            -d "$DNS_ENTRY" \
            "https://api.transip.nl/v6/domains/$DOMAIN/dns")

        HTTP_STATUS_UPDATE=$(echo "$RESPONSE" | tail -n1)
        RESPONSE_BODY=$(echo "$RESPONSE" | head -n -1)

        log_message "API response for creating DNS entry: $RESPONSE_BODY"
        log_message "HTTP status code received for creation: $HTTP_STATUS_UPDATE"

        if [ "$HTTP_STATUS_UPDATE" -ne 201 ]; then
            handle_error "API call for creating DNS entry failed with status code $HTTP_STATUS_UPDATE."
        fi

        log_message "New DNS A-record successfully created."
    else
        log_message "Updating DNS A-record for $SUBDOMAIN.$DOMAIN to IP $CURRENT_IP"
        # Create request body for updating the record
        DNS_ENTRY=$(jq -n \
        --arg name "$SUBDOMAIN" \
        --arg expire "$TTL" \
        --arg type "$RECORD_TYPE" \
        --arg content "$CURRENT_IP" \
        '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

        log_message "DNS entry (update): $DNS_ENTRY"

        # Execute PATCH request to update the existing DNS record
        RESPONSE=$(curl -s -w "%{http_code}" -X PATCH \
            -H "Authorization: Bearer $ACCESS_TOKEN" \
            -H "Content-Type: application/json" \
            -d "$DNS_ENTRY" \
            "https://api.transip.nl/v6/domains/$DOMAIN/dns")

        HTTP_STATUS_UPDATE=$(echo "$RESPONSE" | tail -n1)
        RESPONSE_UPDATE_BODY=$(echo "$RESPONSE" | head -n -1)

        log_message "API update response received: $RESPONSE_UPDATE_BODY"
        log_message "HTTP status code received for update: $HTTP_STATUS_UPDATE"

        # Accept both 200 and 204 as successful updates
        if [ "$HTTP_STATUS_UPDATE" -ne 200 ] && [ "$HTTP_STATUS_UPDATE" -ne 204 ]; then
            handle_error "API call for DNS update failed with status code $HTTP_STATUS_UPDATE."
        else
            log_message "DNS A-record successfully updated to $CURRENT_IP"
        fi
    fi
}

# Get the current external IP
CURRENT_IP=$(curl -s http://ipinfo.io/ip) || handle_error "Failed to get external IP"

# Log the start
log_message "---- Start new run ----"
log_message "Current external IP: $CURRENT_IP"

# Always generate a short lived new token.
generate_new_token


# Try to update or create the DNS record
update_or_create_dns_record

log_message "---- End of run ----"

SSL-certificaten beheren voor domeinen die bij TransIP gehost worden, kan zonder automatisering een gedoe zijn. TransIP biedt gelukkig een degelijke API voor DNS-beheer, maar om die naadloos te integreren met Certbot voor dns-01-validatie is een eigen oplossing nodig. Omdat ik daar geen kant-en-klaar script voor kon vinden, heb ik er zelf één gemaakt dat veilig de authenticatie, DNS-updates en het aanmaken van certificaten regelt.

De volledige API-documentatie vind je hier:

TransIP API

Deze handleiding legt de complete setup met Docker uit, inclusief hoe je het API-keypair genereert in de webinterface van TransIP en gebruikt voor geautomatiseerd certificaatbeheer.

Hoe de authenticatie bij TransIP werkt

TransIP gebruikt een RSA-keypair voor API-authenticatie. Zo stel je dat in:

1. Genereer het keypair in TransIP:
   • Log in op je TransIP-controlepaneel.
   • Ga naar API-instellingen onder je account en schakel API-toegang in.
   • Genereer een nieuw API-keypair.
   • Download/sla de private key (transip_private_key.pem) veilig op en maak er een secret van voor gebruik in je Docker-setup.

docker secret create transip_private_key transip_private_key.pem

1. Houd de private key veilig:
   • Bewaar de private key op een veilige plek nadat je er een secret van hebt gemaakt.
   • Deze private key is nodig om requests naar de API van TransIP te signen.
2. Hoe het werkt:
   • Het script gebruikt de private key om een authenticatie-request te signen.
   • De API van TransIP antwoordt met een token met korte geldigheid (standaard 10 minuten), die vervolgens gebruikt wordt om de DNS-records te beheren.
   • Voor het gemak maakt het script bij elke run een nieuwe token aan. Dat maakte het robuuster dan controleren op een actieve token en die hergebruiken, wat het hele script minder betrouwbaar en omslachtiger maakte.

Wat deze setup gaat doen

1. Automatiseert SSL-certificaten:
   • Automatiseert het aanmaken en vernieuwen van wildcard- en domeinspecifieke certificaten.
2. Verwerkt DNS-challenges:
   • Beheert dns-01-challenges door DNS TXT-records aan te maken en te verwijderen via de TransIP API.
3. Naadloze integratie:
   • Alles zit in een Docker container voor draagbaarheid en eenvoud.
   • Je kunt in dit script domeinen verwijderen of toevoegen bij het -d-gedeelte. Ik heb de voorbeelden erin laten staan voor een betere uitleg.

We pipen een add- of clean-commando naar het bash-script om de acties uit te voeren die in het script staan. We gebruiken hier dus de –manual-auth-hook en de manual-cleanup-hook. Zo wordt bijvoorbeeld gegarandeerd dat een fout in het add-gedeelte alsnog netjes wordt opgeruimd.

Je kunt ook een –force aan dit script toevoegen, maar dan ben je snel door je pogingen bij Letsencrypt heen, want ze staan maar een paar calls per 24 uur toe. Wel zorgt dit ervoor dat de certificaten altijd vernieuwd worden als je iets wilt testen of verifiëren.

version: "3.8"

services:
  certbot:
    image: certbot/certbot:latest
    container_name: certbot-transip
    secrets:
      - transip_private_key  # Reference the secret you created earlier
    # adjust these volumes to point to the right .pem and script. right now this dockerfile expects the files to be in the same folder as the docker-certbot-transip.yml
    volumes:
      - "./certbot-transip.sh:/usr/local/bin/certbot-transip.sh:ro"
      - "./letsencrypt:/etc/letsencrypt"
    environment:
    #These Variables are going to be piped in our bash script.
      LOGIN_NAME: "your-transip-login"        # Replace with your TransIP login name
      PRIVATE_KEY_PATH: "/etc/transip_private_key.pem"
      DOMAIN: "example.com"                  # Replace with your domain
      TTL: "60"                              # Optional: Time-to-live for DNS challenge
      CERTBOT_EMAIL: "you@example.com"       # Replace with your valid email as requested by letsencrypt.
    entrypoint:
      - sh
      - -c
      - |
        apk update && apk add --no-cache bash curl jq bind-tools && \
        chmod +x /usr/local/bin/certbot-transip.sh && \
        certbot certonly --manual --preferred-challenges dns \
          --manual-auth-hook "/usr/local/bin/certbot-transip.sh add" \
          --manual-cleanup-hook "/usr/local/bin/certbot-transip.sh clean" \
          --cert-name "$DOMAIN" \
          -d "*.$DOMAIN" \
          -d "example2.$DOMAIN" \
          -d "example3.$DOMAIN" \
          --expand \
          --non-interactive --agree-tos \
          --email "$CERTBOT_EMAIL"

secrets:
  transip_private_key:
    external: true  # Secret must already exist in Docker

Het Bash-script

Dit is het “geavanceerde” deel dat zijn magie doet en alles met TransIP laat werken. Ik heb het ook een stuk robuuster gemaakt dan standaard. Dit zou dus hopelijk helpen om een stabiele en goed werkende omgeving op te zetten.

Je kunt dit TransIP-script ook lokaal draaien om certificaten aan te maken, of in een Kubectl- of Helm chart.

#!/bin/bash

# Configuration settings
LOGIN_NAME=${LOGIN_NAME}
TTL=${TTL:-60}  # Default value 60 if TTL is not set
PRIVATE_KEY_PATH=${PRIVATE_KEY_PATH}
DOMAIN=${DOMAIN}

AUTH_URL="https://api.transip.nl/v6/auth"
LOG_FILE="/var/log/transip_dyndns.log"

# Function to update a log file
#log_message() {
#    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> $LOG_FILE
#}

# Function to log messages to stdout
log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1"
}

# Function to log an error and stop the script
handle_error() {
    log_message "ERROR: $1"
    echo "ERROR: $1" >&2
    exit 1
}

# Function to obtain a new access token with a short validity period (10 minutes)
generate_new_token() {
    log_message "Generating a new token with a validity period of 10 minutes."

    NONCE=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 16)
    TIMESTAMP=$(date +%s)
    LABEL="Certbot DNS update $TIMESTAMP"

    REQUEST_BODY=$(printf '{"login":"%s","nonce":"%s","read_only":false,"expiration_time":"10 minutes","label":"%s","global_key":true}' "$LOGIN_NAME" "$NONCE" "$LABEL")

    log_message "Request Body: $REQUEST_BODY"

    SIGNATURE=$(echo -n "$REQUEST_BODY" | openssl dgst -sha512 -sign "$PRIVATE_KEY_PATH" | base64 | tr -d '\n')

    log_message "Generated signature: $SIGNATURE"

    RESPONSE=$(curl -s -X POST "$AUTH_URL" \
        -H "Signature: $SIGNATURE" \
        -H "Content-Type: application/json" \
        -d "$REQUEST_BODY") || handle_error "Failed to connect to TransIP API"

    log_message "API-response received: $RESPONSE"

    ACCESS_TOKEN=$(echo "$RESPONSE" | jq -r '.token // empty')
    if [ -z "$ACCESS_TOKEN" ]; then
        handle_error "The received access token is empty or invalid. Check the API-response: $RESPONSE"
    fi

    log_message "Received token: $ACCESS_TOKEN"
}

# Function to add or update a TXT record
add_or_update_txt_record() {
    local full_domain="$1"
    local value="$2"

    # Extract the subdomain part from the full domain
    local name="_acme-challenge.${full_domain%%.*}"

    if [ -z "$name" ] || [ -z "$value" ]; then
        log_message "ERROR: Name or value for TXT record is missing."
        exit 1
    fi

    # Check if the DNS record already exists
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Search for all existing records with the same name and type TXT
    MATCHING_RECORDS=$(echo "$RESPONSE" | jq -r --arg name "$name" '[.dnsEntries[] | select(.name==$name and .type=="TXT")]')

    # Check if there are multiple or no matching records
    MATCHING_COUNT=$(echo "$MATCHING_RECORDS" | jq 'length')

    # Ensure MATCHING_COUNT is always an integer
    if ! [[ "$MATCHING_COUNT" =~ ^[0-9]+$ ]]; then
        MATCHING_COUNT=0
    fi

    if [ "$MATCHING_COUNT" -eq 0 ]; then
        log_message "No existing TXT record found for $name. Creating a new record."
    elif [ "$MATCHING_COUNT" -ge 1 ]; then
        log_message "Multiple or one existing TXT record found for $name. Removing all existing records."

        # Remove all existing records using the full details of each record
        echo "$MATCHING_RECORDS" | jq -c '.[]' | while read -r record; do
            existing_name=$(echo "$record" | jq -r '.name')
            existing_expire=$(echo "$record" | jq -r '.expire')
            existing_content=$(echo "$record" | jq -r '.content')

            # Log the details of the record to be removed
            log_message "Remove record: name=$existing_name, expire=$existing_expire, content=$existing_content"

            # Make the DELETE call using the full DNS-entry details
            DELETE_ENTRY=$(jq -n \
            --arg name "$existing_name" \
            --arg expire "$existing_expire" \
            --arg type "TXT" \
            --arg content "$existing_content" \
            '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

            DELETE_RESPONSE=$(curl -s -X DELETE \
                -H "Authorization: Bearer $ACCESS_TOKEN" \
                -H "Content-Type: application/json" \
                -d "$DELETE_ENTRY" \
                "https://api.transip.nl/v6/domains/$DOMAIN/dns")

            # Log the response of the DELETE call
            log_message "Response after removing $existing_name: $DELETE_RESPONSE"

            # Check if the removal was successful
            if [[ "$DELETE_RESPONSE" == *"error"* ]]; then
                log_message "ERROR: The record $existing_name could not be removed."
            else
                log_message "Record $existing_name successfully removed."
            fi
        done
    fi

    # Create a new record
    DNS_ENTRY=$(jq -n \
    --arg name "$name" \
    --arg expire "$TTL" \
    --arg type "TXT" \
    --arg content "$value" \
    '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

    RESPONSE=$(curl -s -X POST \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "Content-Type: application/json" \
        -d "$DNS_ENTRY" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    log_message "API-response for TXT record creation: $RESPONSE"

    if [[ "$RESPONSE" == *"error"* ]]; then
        handle_error "The TXT record could not be created. Check the API-response: $RESPONSE"
    else
        log_message "TXT record successfully added for $name with value $value"
    fi
}

# Function to update an existing TXT record
update_txt_record() {
    local name="$1"
    local value="$2"

    DNS_ENTRY=$(jq -n \
    --arg name "$name" \
    --arg expire "$TTL" \
    --arg type "TXT" \
    --arg content "$value" \
    '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

    RESPONSE=$(curl -s -X PATCH \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "Content-Type: application/json" \
        -d "$DNS_ENTRY" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    log_message "API-response for TXT record update: $RESPONSE"

    if [[ "$RESPONSE" == *"error"* ]]; then
        handle_error "The TXT record could not be updated. Check the API-response: $RESPONSE"
    else
        log_message "TXT record successfully updated for $name with value $value"
    fi
}

# Function to remove a TXT record for `dns-01` validation
remove_txt_record() {
    local full_domain="$1"

    # Extract the subdomain part from the full domain
    local name="_acme-challenge.${full_domain%%.*}"

    # Check if the DNS record exists
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Search for all records with the same name and type TXT
    MATCHING_RECORDS=$(echo "$RESPONSE" | jq -r --arg name "$name" '[.dnsEntries[] | select(.name==$name and .type=="TXT")]')

    # Check if there are existing records that need to be removed
    MATCHING_COUNT=$(echo "$MATCHING_RECORDS" | jq 'length')

    if [ "$MATCHING_COUNT" -eq 0 ]; then
        log_message "No existing TXT record found for $name to remove."
    else
        log_message "Removing all existing TXT records for $name."

        # Loop through all found records and remove them
        echo "$MATCHING_RECORDS" | jq -c '.[]' | while read -r record; do
            existing_name=$(echo "$record" | jq -r '.name')
            existing_expire=$(echo "$record" | jq -r '.expire')
            existing_content=$(echo "$record" | jq -r '.content')

            # Make the DELETE call using the full details
            DELETE_ENTRY=$(jq -n \
            --arg name "$existing_name" \
            --arg expire "$existing_expire" \
            --arg type "TXT" \
            --arg content "$existing_content" \
            '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

            DELETE_RESPONSE=$(curl -s -X DELETE \
                -H "Authorization: Bearer $ACCESS_TOKEN" \
                -H "Content-Type: application/json" \
                -d "$DELETE_ENTRY" \
                "https://api.transip.nl/v6/domains/$DOMAIN/dns")

            # Check if the removal was successful
            if [[ "$DELETE_RESPONSE" == *"error"* ]]; then
                log_message "ERROR: The TXT record $existing_name could not be removed."
            else
                log_message "TXT record $existing_name successfully removed."
            fi
        done
    fi
}

# Always generate a new token for each run
generate_new_token

# Certbot passes these values when adding and removing the record
if [ "$1" == "add" ]; then
    add_or_update_txt_record "$CERTBOT_DOMAIN" "$CERTBOT_VALIDATION"
    sleep 25  # Wait for DNS update to propagate
elif [ "$1" == "clean" ]; then
    remove_txt_record "$CERTBOT_DOMAIN"
fi

Stappen om te draaien

1. Download de private key: Sla het bestand met de private key (transip_private_key.pem) uit de API-instellingen van TransIP op op het apparaat waar je dit gaat draaien.
2. Stel Docker Compose in: Zet de bestanden docker-compose.yml en certbot-transip.sh in dezelfde map. (of pas het script aan)
3. Start de container: Start de container (cd naar het pad waar je yml staat)

docker-compose up --build

Houd de logoutput in de gaten: de logoutput van de Docker container laat de voortgang van de DNS-challenges en het aanmaken van het certificaat zien.

Meer is het niet!

Binnenkort post ik ook een versie met een werkende Helm chart. Die was wat lastiger om alles correct te laten werken en alle certificaten te laten updaten via verschillende namespaces, waar ik de certificaten op verschillende domeinen beschikbaar moest hebben.

De API: https://api.protonvpn.ch/vpn/logicals is volgens Proton Support officieel stopgezet. Het enige wat hij nog teruggeeft is:

{"Code":0,"Error":"Invalid access token","Details":{}}

Dit artikel is daarmee helaas achterhaald. Iemand is een petitie begonnen om deze functionaliteit terug te krijgen.

De achterhaalde handleiding die niet meer werkt sinds 06/2025. Voor de historie bewaard.

Toen ProtonVPN zijn command-line interface (CLI)-tool stopzette, bleven gebruikers van headless systemen zoals de Raspberry Pi zonder een eenvoudige manier om VPN-verbindingen te beheren. Zonder grafische interface is het handmatig wisselen van VPN-servers een gedoe geworden. Ook het selecteren van de snelste VPN uit een pool van servers is onmogelijk geworden.

Om dit probleem op te lossen, heb ik een Python-script ontwikkeld dat automatisch de snelste ProtonVPN-server selecteert op basis van latency en load, en daarna je WireGuard-configuratie voor je bijwerkt. Deze handleiding neemt je mee door het instellen van WireGuard voor ProtonVPN, het installeren van het script en het automatiseren van je VPN-verbinding, zodat je Raspberry Pi altijd verbonden is met de beste server.

Waarom heb ik dit Protonss-script nodig?

Dit Python-script automatiseert het verbinden van je Raspberry Pi met de snelst beschikbare ProtonVPN-server, met WireGuard als VPN-protocol. Het controleert de latency en load van meerdere VPN-servers via de API van ProtonVPN, kiest de server met de beste prestaties, werkt je WireGuard-configuratie bij met de nieuwe servergegevens en maakt alleen opnieuw verbinding als er een duidelijk snellere server is gevonden (niemand zit eigenlijk te wachten op reconnects). Het script logt het hele proces, wat het debuggen een stuk makkelijker maakt.

1. Geen handmatig VPN-wisselen meer: Zonder de CLI van ProtonVPN zou het wisselen naar de snelste server handwerk betekenen. Dit script automatiseert dat proces door regelmatig de beschikbare servers te controleren en de verbinding bij te werken op basis van realtime prestaties.
2. Optimaliseert de verbindingssnelheid: Het script zorgt dat je altijd verbonden bent met de VPN-server met de laagste latency en load. Dit is vooral handig om snelle verbindingen te behouden in landen met snelle ProtonVPN-servers of servers met weinig verkeer.
3. Vermindert downtime: Door het herverbinden te automatiseren, minimaliseert het script mogelijke downtime door slechte serverprestaties of trage verbindingen.
4. Gemaakt voor de Raspberry Pi: Als je een headless Raspberry Pi draait (zonder monitor), is dit script ideaal om VPN-taken te automatiseren zonder constante supervisie.
5. Beveiliging & privacy: Door ervoor te zorgen dat je Raspberry Pi altijd via een VPN verbinding maakt, beschermt het je data en online activiteit, zeker als je de Pi gebruikt voor torrenting of als netwerkapparaat.

Dit script automatiseert dus het vinden van de optimale ProtonVPN-server, met hogere snelheden, meer betrouwbaarheid en gemak voor headless systemen zoals een Raspberry Pi.

Aan de slag!

Eerst moet je WireGuard installeren, een snel en lichtgewicht VPN-protocol dat we gebruiken om verbinding te maken met onze ProtonVPN-server.

# First, update your package list and install WireGuard:
sudo apt update
sudo apt install wireguard curl resolvconf

Genereer een WireGuard-configuratie via ProtonVPN

• Log in op je ProtonVPN-account op hun website.
• Ga naar het gedeelte “Downloads” in je dashboard.
• Genereer een nieuw configuratiebestand onder “WireGuard Configurations”.
• Gebruik je torrents, schakel dan NAT-PMP in.

Sla dit configuratiebestand op je Raspberry Pi op:

# Save the configuration file to your Raspberry Pi:
# Place it in the WireGuard directory and rename it for simplicity:
sudo nano /etc/wireguard/protonvpn.conf

Zodra je het configuratiebestand in de juiste map hebt geplaatst, controleer je de verbinding.

# Verify connection to ProtonVPN:
sudo wg-quick up protonvpn

# This should give an ip address different to the one frome your isp
curl ifconfig.me 

# Verify connection to ProtonVPN:
sudo wg-quick down protonvpn

curl ifconfig.me 

Als deze twee ip-adressen van ifconfig.me verschillen, ben je verbonden via een VPN. Ook als je je eigen ip-adres niet kent omdat het een DHCP-adres of iets dergelijks is.

Onze Python-omgeving installeren voor Protonss.

Bij het ontwikkelen en draaien van Python-scripts op je Raspberry Pi is het verstandig om een Python virtual environment te gebruiken. Zo’n virtuele omgeving laat je Python-packages geïsoleerd installeren en beheren, zodat de standaard Python-configuratie van je systeem onaangeroerd blijft.

Veranderingen in je omgeving beïnvloeden dan alleen het project waaraan je werkt — zoals het installeren van specifieke packages zoals requests — zonder conflicten te veroorzaken met andere Python-projecten of systeemafhankelijkheden.

Zo stel je een virtuele omgeving in voor ons script:

1. Installeer de virtuele omgeving: Installeer eerst het package python3-venv, waarmee je virtuele omgevingen kunt aanmaken en beheren.

sudo apt install -y python3-venv python3-full

2. Maak een virtuele omgeving: Na installatie kun je een virtuele omgeving aanmaken. Dit genereert een geïsoleerde omgeving in de door jou opgegeven map (in dit geval ~/protonss).

python3 -m venv ~/protonss

3. Activeer de virtuele omgeving: Na het aanmaken moet je de omgeving activeren. Dit zorgt dat je systeem de Python-versie en packages uit de virtuele omgeving gebruikt in plaats van de systeembrede Python-installatie.

source ~/protonss/bin/activate

• Nu de omgeving actief is, wordt elke Python-package die je installeert (zoals requests) in deze geïsoleerde omgeving geïnstalleerd.

pip install requests

Deze virtuele omgeving in de toekomst gebruiken: Elke keer dat je Python-scripts wilt draaien die van deze virtuele omgeving afhankelijk zijn, moet je hem opnieuw activeren met het commando source ~/venv/bin/activate. Eenmaal actief draaien alle Python-commando’s en packages in deze omgeving.

Ons ProtonSS-script installeren om automatisch met de snelste VPN te verbinden.

We maken een configuratiebestand aan met alle variabelen die het Python-script gebruikt. Daarin definieer je bijvoorbeeld het pad naar je WireGuard-configuratie, het logbestand en het aantal pings om latency te testen.

cd ~/protonss

Voorbeeld config.ini:

nano config.ini

[Settings]
# Path to your WireGuard configuration file
wg_config_path = /etc/wireguard/protonvpn.conf

# Path to your log file
log_file = /var/log/wireguard_updater.log

# Number of pings to measure latency
ping_count = 3

# Maximum score difference before reconnection 0 - 100
# Average score of servers is between 10-40 it seems. so setting this to high results in no switches from servers
score_threshold = 5.0

# Comma-separated list of preferred countries
preferred_countries = US

# Comma-separated list of preferred cities
# If specified, servers must be in these cities (unless they're in a country without any specified city)
# Preferred cities to connect to. If specified, servers must be in these cities
# (unless they're in a country without any specified city).
# Example: preferred_cities = Phoenix, Los Angeles, Seattle
# This allows you to target specific cities within your preferred countries.
# If left empty, any city within the preferred countries will be considered.
# Note: City names are case sensitive and must match ProtonVPN's naming exactly.
# Multiple cities should be comma-separated.
preferred_cities =Phoenix

# Weight for latency in the server score
# latency is subjective since this is probably measured through the vpn and only counts as server latency.
# Checking the latency without a vpn isnt recommended since the proton servers wont reply back without vpn.
# Value cant be higher then 1. 0.3 translates to 30% of the score_treshold.
latency_weight = 0.3

# Weight for server load in the server score
# Load is the best factor 0.7 translates to 70% of the weight of the score_threshold. this cant be higher then 1.
load_weight = 0.7

# Enable or disable pinging servers (True or False)
# Since ping might not be reliable enough for you to keep on switching servers this can be disabled here.
ping_enabled = True

# Specify the interface to use for ping tests. By setting this option you can ping to the fastest vpn server
# this will ensure the lowest latency VPN from your location.
ping_interface = eth0

[Features]
# Choose which type of servers you want to use
# Options: p2p, plus, secure_core, tor
# Default is p2p if not specified
feature_type = p2p

# Feature explanation:
# Each server has exactly ONE feature number:
# 1, 17 = Secure Core servers
# 2 = TOR servers
# 0, 8, 16, 24 = Plus-only servers
# 4, 12, 20, 28 = P2P servers (these are also Plus servers)

Je kunt de variabelen naar behoefte aanpassen. Laat je preferred_countries leeg, dan controleert het script een HELEBOEL! servers, waardoor het script erg lang gaat draaien!

Maak het Python-script aan

Nu gaan we het Python-script maken dat je VPN-verbinding automatiseert. Eerst moeten we een paar stappen voorbereiden.

De eerste regel van het script moet een shebang zijn, die er altijd voor zorgt dat het script in de juiste Python-omgeving draait:

source ~/protonss/bin/activate
which python

Dit geeft je het pad dat je op de eerste regel van het script moet zetten.

/home/pi/venv/bin/python

Pas het script aan door een shebang toe te voegen: zet de volgende regel helemaal bovenaan je Python-script. Vervang /home/{user}/venv/bin/python door het daadwerkelijke pad dat je kreeg toen je eerder het commando which python uitvoerde. Laat de #! aan het begin van de regel staan—daaruit maakt het systeem op welke interpreter het script moet draaien. We hebben het absolute pad nodig, dus ~/ werkt niet.

nano protonvpn_auto_connect.py

#!/home/{user}/protonss/bin/python

import requests
import subprocess
import os
import sys
import configparser
import logging
import re
from datetime import datetime
import math
import shutil

# Get the directory of the current script
script_dir = os.path.dirname(os.path.abspath(__file__))

# Load the config file from the same directory as the script
config = configparser.ConfigParser()
config.read(os.path.join(script_dir, 'config.ini'))

WG_CONFIG_PATH = config.get('Settings', 'wg_config_path')
LOG_FILE = config.get('Settings', 'log_file')
PING_COUNT = config.getint('Settings', 'ping_count')
SCORE_THRESHOLD = config.getfloat('Settings', 'score_threshold', fallback=5.0)
PREFERRED_COUNTRIES = config.get('Settings', 'preferred_countries', fallback='').split(',')
PREFERRED_CITIES = config.get('Settings', 'preferred_cities', fallback='').split(',')
PING_INTERFACE = config.get('Settings', 'ping_interface', fallback=None)

# Weighting factors for latency and load from the config
LATENCY_WEIGHT = config.getfloat('Settings', 'latency_weight', fallback=0.3)
LOAD_WEIGHT = config.getfloat('Settings', 'load_weight', fallback=0.7)

# Ping option from config
PING_ENABLED = config.getboolean('Settings', 'ping_enabled', fallback=True)

# Clean up country codes (remove spaces and convert to uppercase)
PREFERRED_COUNTRIES = [country.strip().upper() for country in PREFERRED_COUNTRIES if country.strip()]

# Clean up city names (remove spaces)
PREFERRED_CITIES = [city.strip() for city in PREFERRED_CITIES if city.strip()]

# Set up logging
logging.basicConfig(
    filename=LOG_FILE,
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)

logging.info('--- ProtonVPN Auto Connect Script Start ---')

# Feature definitions
FEATURE_SECURE_CORE = [1, 17]  # Secure Core servers
FEATURE_TOR = [2]         # TOR servers
FEATURE_PLUS = [0, 8, 16, 24]  # Plus-only servers
FEATURE_P2P = [4, 12, 20, 28]    # P2P servers (these are also Plus servers)
# check https://api.protonmail.ch/vpn/logicals for more info. 
# be aware that the secure core and tor server are very limited so check if one is available for your country as stated in the config.ini file.
# FREE servers are not included in the api response. so they are already left out.

def get_feature_description(features):
    # If no feature type is specified in config.ini, default to P2P
    # Features is a number representing server capabilities
    if not features:  # If features is 0 or None
        return "P2P"  # Default to P2P
    elif features in FEATURE_SECURE_CORE:
        return "Secure Core"
    elif features in FEATURE_TOR:
        return "TOR" 
    elif features in FEATURE_P2P:
        return "P2P"
    elif features in FEATURE_PLUS:
        return "Plus"
    else:
        return "P2P"  # Default to P2P for any unrecognized feature

def get_wanted_features():
    """Get the wanted feature type based on config priorities"""
    feature_type = config.get('Features', 'feature_type', fallback='p2p').lower()
    
    if feature_type == 'secure_core':
        return FEATURE_SECURE_CORE
    elif feature_type == 'tor':
        return FEATURE_TOR
    elif feature_type == 'plus':
        return FEATURE_PLUS
    else:  # Default to P2P
        return FEATURE_P2P

# Function to fetch the list of servers from the ProtonVPN API
def get_servers(full_list=False):
    try:
        url = 'https://api.protonmail.ch/vpn/logicals'
        response = requests.get(url)
        response.raise_for_status()
        data = response.json()
        logging.info("API response data received.")
        return data['LogicalServers']
    except requests.RequestException as e:
        logging.error(f'Error fetching server list: {e}')
        sys.exit(1)
    except ValueError as e:
        logging.error(f'Error parsing JSON: {e}')
        sys.exit(1)

# Function to filter P2P servers and servers in preferred countries
def filter_servers(servers):
    filtered_servers = []
    
    # Get feature preferences from config (nu maar één type)
    wanted_features = get_wanted_features()
    
    logging.info(f"Filtering servers with preferences - Countries: {PREFERRED_COUNTRIES or 'Any'}, "
                f"Cities: {PREFERRED_CITIES or 'Any'}, Features: {[get_feature_description(f) for f in wanted_features]}")
    
    for server in servers:
        if not isinstance(server, dict):
            logging.error(f"Unexpected type for server: {type(server)} - Value: {server}")
            continue
            
        features = server.get('Features', 0)
        country = server['ExitCountry']
        city = server.get('City', '')

        # Check if server features match our wanted features
        if features in wanted_features:
            # Check country and city preferences
            if country in PREFERRED_COUNTRIES:
                if not PREFERRED_CITIES or city in PREFERRED_CITIES:
                    filtered_servers.append(server)
                    logging.info(f"Server matched - Country: {country}, City: {city}, "
                              f"Features: {get_feature_description(features)}")
            
    if not filtered_servers:
        logging.warning(f"No servers found matching filters. Countries: {PREFERRED_COUNTRIES}, "
                      f"Cities: {PREFERRED_CITIES}, Features: {[get_feature_description(f) for f in wanted_features]}")
    else:
        logging.info(f"Found {len(filtered_servers)} matching servers")
        
    return filtered_servers

# Function to measure latency by pinging the server (optional)
def get_latency(hostname):
    if not PING_ENABLED:
        logging.info(f"Ping disabled, skipping latency check for {hostname}.")
        return 0  # Return 0 latency if ping is disabled

    latencies = []
    for i in range(PING_COUNT):
        try:
            # Add the interface option if it's specified
            ping_command = ['ping', '-c', '1', '-W', '1', hostname]
            if PING_INTERFACE:
                ping_command.insert(1, '-I')
                ping_command.insert(2, PING_INTERFACE)

            result = subprocess.run(ping_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
            if result.returncode == 0:
                output = result.stdout.decode()
                latency_line = [line for line in output.split('\n') if 'time=' in line][0]
                latency = float(latency_line.split('time=')[1].split(' ms')[0])
                latencies.append(latency)
            else:
                latencies.append(float('inf'))
        except Exception as e:
            latencies.append(float('inf'))
            logging.error(f'Ping error for {hostname}: {e}')

    # Return the lowest (best) latency value
    best_latency = min(latencies)
    
    # Handle inf latency
    if math.isinf(best_latency):
        logging.warning(f"Latency for {hostname} is inf. Assigning high latency value.")
        best_latency = 1000  # Assign a high latency value

    return best_latency

# Function to select the best server based on a weighted combination of latency and load
def select_best_server(servers):
    best_server = None
    best_score = float('inf')
    
    for server in servers:
        server_load = server.get('Load')
        
        # Handle inf load
        if server_load is None or math.isinf(server_load):
            logging.warning(f"Server {server['Name']} has inf load. Assigning high load value.")
            server_load = 100  # Assign a high load value if it's inf or None
        else:
            server_load = int(server_load)
        
        for srv in server['Servers']:
            exit_ip = srv.get('ExitIP')
            hostname = exit_ip

            # Get latency, only if ping is enabled
            latency = get_latency(hostname)

            # Combine latency and load using the configured weights
            score = (latency * LATENCY_WEIGHT) + (server_load * LOAD_WEIGHT)
            
            logging.info(f"Server {server['Name']} - Latency: {latency:.2f} ms, Load: {server_load}%, Score: {score:.2f}")
            
            if score < best_score:
                best_score = score
                best_server = server
                best_server_instance = srv

    return best_server, best_server_instance, best_score

# Function to read the current server IP from the WireGuard configuration
def get_current_server_ip():
    try:
        with open(WG_CONFIG_PATH, 'r') as f:
            config_text = f.read()
        # Extract the current Endpoint IP
        match = re.search(r'Endpoint\s*=\s*([\d\.]+):\d+', config_text)
        if match:
            logging.info(f"Current server IP found in WireGuard configuration: {match.group(1)}")
            return match.group(1)
        else:
            logging.warning('No current Endpoint IP found in WireGuard configuration.')
            return None
    except Exception as e:
        logging.error(f'Error reading the WireGuard configuration: {e}')
        return None

# Function to find the current server's performance in the live server data
def get_current_server_performance(servers, current_ip):
    if current_ip is None:
        logging.warning('Current server IP is None, skipping performance check.')
        return None, None, float('inf')
    
    for server in servers:
        for srv in server['Servers']:
            if srv['ExitIP'] == current_ip:
                server_load = server.get('Load')
                if server_load is None or math.isinf(server_load):
                    logging.warning(f"Server {server['Name']} (IP: {current_ip}) has inf load. Assigning high load value.")
                    server_load = 100  # Assign a high load value
                else:
                    server_load = int(server_load)

                latency = get_latency(current_ip) if PING_ENABLED else 0
                score = (latency * LATENCY_WEIGHT) + (server_load * LOAD_WEIGHT)

                logging.info(f"Current server {server['Name']} - Latency: {latency:.2f} ms, Load: {server_load}%, Score: {score:.2f}")
                return server, srv, score
    logging.warning(f"Current server with IP {current_ip} not found in live data.")
    return None, None, float('inf')

# Function to find the current server in the full ProtonVPN list if not found in filtered data
def find_current_server_full_list(current_ip):
    servers = get_servers(full_list=True)
    return get_current_server_performance(servers, current_ip)

# Function to update the WireGuard configuration file
def update_wg_config(server, server_instance, best_score):
    try:
        endpoint_ip = server_instance['EntryIP']
        endpoint_port = 51820  # Default WireGuard port
        endpoint = f"{endpoint_ip}:{endpoint_port}"
        public_key = server_instance['X25519PublicKey']
        server_name = server['Name']

        # Read the current WireGuard configuration
        with open(WG_CONFIG_PATH, 'r') as f:
            config_text = f.read()

        # Strip comments that start with # under [Peer] before PublicKey
        config_text = re.sub(r'#.*\n', '', config_text, flags=re.M)

        # Update the Endpoint in the configuration
        config_text = re.sub(r'Endpoint\s*=.*', f'Endpoint = {endpoint}', config_text)

        # Update the PublicKey in the configuration
        config_text = re.sub(r'PublicKey\s*=.*', f'PublicKey = {public_key}', config_text)

        # Add the new comment indicating the chosen server and score
        config_text = re.sub(r'\[Peer\]\n', f'[Peer]\n# {server_name} - Auto-generated by ProtonVPN Auto Connect - Score: {best_score:.2f}\n', config_text)

        # Write the updated configuration back to the file
        with open(WG_CONFIG_PATH, 'w') as f:
            f.write(config_text)
        os.chmod(WG_CONFIG_PATH, 0o600)

        logging.info(f"WireGuard configuration updated with server: {server_name} ({server['ExitCountry']}), Endpoint: {endpoint}, PublicKey: {public_key}, Score: {best_score:.2f}")
    except Exception as e:
        logging.error(f'Error updating the WireGuard configuration: {e}')
        sys.exit(1)

# Function to restart the WireGuard interface
def is_resolvconf_available():
    """Check if resolvconf is available on the system."""
    return shutil.which("resolvconf") is not None

def is_wg_quick_available():
    """Check if wg-quick is available on the system."""
    return shutil.which("wg-quick") is not None

def restart_wg():
    interface_name = os.path.basename(WG_CONFIG_PATH).split('.')[0]
    
    # Check if wg-quick is available before proceeding
    if not is_wg_quick_available():
        logging.error("wg-quick not found. Ensure WireGuard is installed correctly.")
        sys.exit(1)

    try:
        # Check if resolvconf is available before proceeding
        if not is_resolvconf_available():
            logging.warning("resolvconf not found, DNS settings may not be updated correctly.")

        # Bring down the interface
        subprocess.run(['wg-quick', 'down', interface_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)

        # Bring up the interface
        subprocess.run(['wg-quick', 'up', interface_name], check=True)
        logging.info(f'WireGuard interface {interface_name} started.')

    except subprocess.CalledProcessError as e:
        logging.error(f'Error starting the WireGuard interface: {e}')
        sys.exit(1)

# Main function
def main():
    logging.info('--- Starting server selection process ---')
    
    # Fetch the list of servers
    servers = get_servers()
    if not isinstance(servers, list):
        logging.error(f'Unexpected type for servers: {type(servers)}')
        sys.exit(1)

    # Filter the servers
    filtered_servers = filter_servers(servers)
    if not filtered_servers:
        logging.error('No suitable servers available after filtering.')
        sys.exit(1)

    # Get the current server's IP address from the WireGuard configuration
    current_ip = get_current_server_ip()

    # Get the current server's performance if it exists
    current_server, current_server_instance, current_score = get_current_server_performance(filtered_servers, current_ip)

    # If the current server is not found, check the full list of servers
    if current_server is None:
        logging.info(f"Current server not found in filtered list, checking full server list...")
        current_server, current_server_instance, current_score = find_current_server_full_list(current_ip)

    # Select the best server based on weighted latency and load
    best_server, best_server_instance, best_score = select_best_server(filtered_servers)
    if not best_server:
        logging.error('No suitable server found.')
        sys.exit(1)

    if current_server:
        logging.info(f"Current server {current_server['Name']} (IP: {current_ip}) - Score: {current_score:.2f}")
    
    logging.info(f"Selected best server {best_server['Name']} - Score: {best_score:.2f}")
    
    if current_server and current_score <= best_score + SCORE_THRESHOLD:
        logging.info(f"Current server {current_server['Name']} is within threshold. No switch necessary.")
    else:
        logging.info(f"Switching to server {best_server['Name']} due to better performance.")
        update_wg_config(best_server, best_server_instance, best_score)
        restart_wg()

    logging.info('--- ProtonVPN Auto Connect Script End ---')

if __name__ == '__main__':
    main()

Het script testen

chmod +x protonvpn_auto_connect.py

Zodra het script is opgeslagen, geef je het uitvoerrechten en draai je het.

sudo ./protonvpn_auto_connect.py

cat /var/log/wireguard_updater.log
tail -f /var/log/wireguard_updater.log

Je kunt het logbestand tailen of catten om de output te controleren. Tail heeft de voorkeur, want dan kun je het blijven volgen terwijl je script draait. Open gewoon een tweede ssh-sessie met de tail om het in de gaten te houden.

2024-09-25 22:19:10 [INFO] --- ProtonVPN Auto Connect Script Start ---
2024-09-25 22:19:10 [INFO] --- Starting server selection process ---
2024-09-25 22:19:11 [INFO] API response data received.
2024-09-25 22:19:11 [INFO] Current server IP found in WireGuard configuration: 79.135.105.20
2024-09-25 22:19:11 [WARNING] Current server with IP 79.135.105.20 not found in filtered data.
2024-09-25 22:19:11 [INFO] Current server not found in filtered list, checking full server list...
2024-09-25 22:19:12 [INFO] API response data received.
2024-09-25 22:19:13 [INFO] Current server BH#1 - Latency: 26.90 ms, Load: 10%, Score: 15.07
2024-09-25 22:19:14 [INFO] Server AO#1 - Latency: 27.10 ms, Load: 7%, Score: 13.03
2024-09-25 22:19:15 [INFO] Server AO#2 - Latency: 26.60 ms, Load: 14%, Score: 17.78
2024-09-25 22:19:16 [INFO] Server AO#3 - Latency: 27.10 ms, Load: 9%, Score: 14.43
2024-09-25 22:19:17 [INFO] Server AO#4 - Latency: 26.60 ms, Load: 16%, Score: 19.18
2024-09-25 22:19:17 [INFO] Current server BH#1 (IP: 79.135.105.20) - Score: 15.07
2024-09-25 22:19:17 [INFO] Selected best server AO#1 - Score: 13.03
2024-09-25 22:19:17 [INFO] Current server BH#1 is within threshold. No switch necessary.
2024-09-25 22:19:17 [INFO] --- ProtonVPN Auto Connect Script End ---

sudo cat /etc/wireguard/protonvpn.conf

Je kunt ook controleren of alles werkt door het bestand protonvpn.conf te bekijken of door je externe ip-adres na te gaan.

[Peer]
# BH#3 - Auto-generated by ProtonVPN Auto Connect - Score: 7.74

Je ziet dan iets zoals hierboven. Deze comment wordt bijgewerkt zodra er verbinding wordt gemaakt met een andere VPN, en het ip-adres binnen de peer verandert dan uiteraard mee.

curl ifconfig.me #this wil give the external ip in the cli.

Als extra stap kun je ook je externe ip controleren. Die moet anders zijn dan het ip-adres dat je provider je geeft.

Dit script elk uur draaien

sudo crontab -e

0 * * * * cd /home/{user}/protonss && /home/{user}/protonss/protonvpn_auto_connect.py >> /home/{user}/protonss/protonvpn_cron.log 2>&1

Hier hebben we ingesteld dat het elk uur draait, maar je kunt het plannen zoals je wilt.

sudo crontab -l

Sla de crontab op en controleer dat cron is geïnstalleerd.

Optioneel: specifiek verkeer blokkeren als je VPN uitvalt

Als je er zeker van wilt zijn dat er geen verkeer je device verlaat als de VPN-verbinding uitvalt, kun je iptables gebruiken om verkeer te blokkeren wanneer de WireGuard-interface down is.

sudo apt-get install iptables

Controleer dat je iptables hebt geïnstalleerd, of installeer het met het bovenstaande commando.

ifconfig -a

protonvpn: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 10.2.1.3  netmask 255.255.255.255  destination 10.2.1.3
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 612  bytes 101768 (99.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 765  bytes 101144 (98.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Bepaal eerst de naam van je netwerkinterface. Als je je bestand protonvpn.conf hebt genoemd, heet de interface protonvpn.

sudo iptables -A OUTPUT -p tcp --dport 51413 ! -o protonvpn -j REJECT --reject-with icmp-port-unreachable
sudo iptables -A OUTPUT -p udp --dport 51413 ! -o protonvpn -j REJECT --reject-with icmp-port-unreachable

Je kunt elke regel aan je iptables toevoegen. De 2 regels hieronder zorgen ervoor dat poort 51413 wordt geweigerd zodra de netwerkinterface met de naam protonvpn niet beschikbaar is. Er is een regel voor UDP- en voor TCP-verkeer.

sudo iptables -L OUTPUT -v -n

Nadat je alle benodigde regels hebt toegevoegd, kun je ze met dit commando controleren.

sudo apt-get install iptables-persistent

En maak de regels persistent, zodat je ze niet bij elke reboot opnieuw hoeft toe te voegen.

sudo netfilter-persistent save

Conclusie

Met dit Python-script is je Raspberry Pi altijd verbonden met de snelste beschikbare ProtonVPN-server, zodat je de best mogelijke VPN-prestaties hebt zonder handmatig ingrijpen. Of je je Pi nu gebruikt voor netwerken, torrenten of algemene online beveiliging: deze automatisering zorgt voor optimale prestaties en betrouwbare privacybescherming.

Update - 20-12-2024

Preferred_cities toegevoegd als optie om de selectie voor de VS te verkleinen. Dat land bevat anders ruim 2000 servers om te controleren. De performance-check kan zo in elk geval wat korter worden :-).

En ik heb uitgevonden wat de Feature-sectie van elke server in de API betekent. Hieronder leg ik het uit. Ik heb mijn code daarnaar aangepast om er correct mee te werken. Let op: de configuratie die je eerder hebt gemaakt moet overeenkomen met het type server waarmee je verbindt. Als je configuratie niet is ingesteld om met een Secure Core te verbinden, selecteer dan ook geen Secure Core in dit script. Sluit aan bij de ProtonVPN-configuratie die je hebt aangemaakt.

Uitleg van de features:

Elke server heeft precies één feature-nummer:

• 1, 17 = Secure Core-servers
• 2 = TOR-servers
• 0, 8, 16, 24 = Plus-only servers
• 4, 12, 20, 28 = P2P-servers (dat lijken ook Plus-servers te zijn)

        {
            "Name": "US-AZ#105",
            "EntryCountry": "US",
            "ExitCountry": "US",
            "Domain": "node-us-260.protonvpn.net",
            "Tier": 2,
            "Features": 12,

Na wat meer onderzoek naar vragen over de gratis servers van ProtonVPN blijkt dat ProtonVPN de publieke API-toegang tot hun free server-endpoints heeft verwijderd. Het /vpn/servers-endpoint dat eerder informatie over gratis servers had moeten leveren, geeft nu een 404-error:

{    "Code": 404,    "Error": "Path not found",    "Details": {}}

Op dit moment is alleen het Plus-server-endpoint via de publieke

API bereikbaar: url = ‘https://api.protonmail.ch/vpn/logicals’

Dit is waarschijnlijk een bewuste keuze van ProtonVPN. Helaas kan dit script daardoor de gratis servers niet ondersteunen.

Er wordt al veel geschreven over Scrum. Scrum is dood, enzovoort. Nou, als je een vacature hebt voor een “Manager”, een “conciërge” of een andere duidelijk niet-Scrum functietitel, maar besluit het een vacature voor een Product Owner of Scrum Master te noemen, dan ben jij degene die het verkloot. Alleen het beest een andere naam geven zorgt er niet voor dat het ineens als magie werkt.

We hebben het allemaal weleens gehoord: “We doen Scrum, en hupsakee! We leveren in een mum van tijd waarde!” (Spoiler alert) zo werkt het niet. Scrum is geen toverdrank die chaos in orde verandert door er wat ceremonies overheen te strooien. Het kost veel meer dan de stappen in de Scrum guide volgen om tot echte resultaten te komen. Het draait om teamwork, discipline en de juiste mensen op de juiste plek — en geloof het of niet, het verschilt niet zoveel van hoe dingen in het leger getraind worden ;-).

Sprint is een missie

Beginnen we nog eens met de olifant in de kamer: het woord “sprint”. We zijn toch niet echt aan het hardlopen? Voor mij suggereert die term nog steeds haast, maar in werkelijkheid mikken we op een doordachte, goed geplande missie. Net als in het leger gaat het niet om snelheid, maar om precisie en succes. Een goed uitgevoerde missie gooi je niet zomaar in elkaar, die wordt strategisch gepland en vereist dat iedereen zijn rol speelt en zijn steentje bijdraagt tot de finish.

Een missie uitvoeren vraagt om aanpassing onderweg. Je gaat onbekenden tegenkomen en je moet erop voorbereid zijn om daarmee om te gaan in plaats van ze te vermijden of negeren en je missie te verkloten.

Onbekenden oplossen als een TEAM is wat een Agile/Scrum-aanpak laat werken.

Gespecialiseerd, maar allround

In zowel Scrum-teams als militaire eenheden heeft iedereen z’n eigen specialiteiten en sterke kanten. Maar hier komt de kicker: we leveren waarde als team. Net als in het leger, waar soldaten cross-trained worden om gaten te vullen, zijn wij ook allrounders. Als er iets misgaat, steken we niet onze handen in de lucht en noemen we het een dag. We passen ons aan en klaren de klus, samen (als team!).

Scrum werkt niet zonder de juiste mindset {#scrum-doesn%E2%80%99t-work-without-the-right-mindset}

Scrum draait niet vanzelf. Alleen Scrum aannemen zorgt niet ineens voor waarde. Ik heb het zien gebeuren. Mensen denken dat als ze de ceremonies draaien en wat Scrum-gerelateerde stappen volgen, de magie vanzelf gebeurt. Maar zonder dat je team zelf het proces managet, is het als een militaire missie draaien zonder kapitein, zonder briefing, en iedereen die maar wat aanmoddert. Misschien kom je wel tot het einde, maar wat heb je dan eigenlijk gedaan?

Het leger weet dit goed. Er is structuur, leiders die sturen, maar ook het vertrouwen dat elk teamlid proactief is. In Scrum heb je de juiste mix nodig: een Product Owner met een mandaat en een daadwerkelijke visie die het bedrijf ondersteunt, een Scrum Master die de flow erin houdt, en een team dat niet alleen taken uitvoert maar nadenkt over het grotere geheel. Die mindset bereik je alleen door samen te werken en als één team met elkaar te blijven praten.

Een team dat over de moeilijke dingen praat

Als team moeten we samenwerken, open met elkaar praten en de moeilijke dingen aanpakken. Ik heb het niet over makkelijke gesprekken waarin iedereen het met elkaar eens is. Ik bedoel moeilijke, ongemakkelijke discussies over wat niet werkt of niet duidelijk is, wat beter moet en hoe je daar komt. Pas dan komt de juiste geleverde waarde bovendrijven.

Bespreek onbekenden tijdens je missie en pak ze aan. Een “daily scrum” aanhouden leert dat niet vanzelf.

Hoe denk je dat Apple de iPhone heeft gemaakt? Jobs en Ive zaten niet samen elkaar op de schouder te kloppen. Ze discussieerden, itereerden en duwden elkaar voort tot het product goed was. En zo zouden Scrum-teams moeten werken. Je doet niet gewoon wat makkelijk of snel is. Je werkt de problemen door, daagt elkaar uit en itereert tot je het hebt. Je stelt ook veel (WAAROM-)vragen, zodat je begrijpt waar ieder vandaan komt.

Briefings en debriefings zijn cruciaal, maar alleen als je er iets voor doet

In Scrum hebben we onze Planning (briefing) en onze Review en Retrospective (debriefing). Klinkt bekend? Je kunt niet zomaar aan een missie beginnen zonder plan, en je kunt al helemaal niet verbeteren zonder terug te kijken naar wat er mis of goed ging. Maar, en hier zit de kneep: je moet deze sessies ook echt gebruiken waarvoor ze bedoeld zijn. Te vaak worden ze overhaast gedaan of afgevinkt. In het leger kan een mislukte briefing of debrief levens kosten, in Scrum kost het je de mogelijkheid om bij de volgende missie te itereren en dingen te testen en te verbeteren. Neem ze serieus, anders zijn het gewoon lege meetings die geen waarde leveren.

Teamwork is alles

Uiteindelijk slagen zowel Scrum als militaire missies door teamwork. Je hebt mensen nodig die betrokken zijn, die communiceren en die voor elkaar klaarstaan. Zonder dat ben je gewoon een stel mensen die roept dat ze Scrum doen, en dat levert helemaal geen waarde op. Scrum draait niet om helden, maar om het collectieve doel. Je wint samen, je verliest samen.

Scrum is geen heilige hamer die alles oplost

Oké, even dit: Scrum is een framework. Een door mensen bedachte structuur, bedoeld om teams efficiënt samen te laten werken. Maar Scrum doen levert niet automatisch waarde op voor je bedrijf. Je hebt de juiste mensen nodig, de juiste mindset en een duidelijke missie waar iedereen naartoe werkt. Anders ben je gewoon taken aan het afvinken zonder erover na te denken — en dat gaat mis.

Nog iets: pas je manier van werken aan aan wat je bedrijf nodig heeft. Scrum geeft een structuur waar je je aan kunt aanpassen. Maar wees niet bang om dingen te veranderen als dat beter werkt voor je organisatie. Het doel is een team dat graag werkt binnen de structuur en waarde levert in plaats van features.

Je als team, of zelfs als organisatie, moet het laten werken door de juiste mensen (met visie en mandaat) en processen op zijn plek te zetten. Doe je dat niet, dan eindig je met een noodlanding: niets opgeleverd, alleen frustratie.

Laat solo managers die vooral zichzelf er goed uit willen laten komen je drive naar waarde en het écht helpen van de business niet overnemen. Niet de business schaden.

Inleiding

In deze post wil ik databaseperformance binnen Azure belichten, met een directe vergelijking tussen MySQL, MariaDB en PostgreSQL. Er is veel literatuur over het onderwerp, maar praktische tests die de performance in de praktijk meten, zijn schaars.

Veel discussies draaien om de verschillen tussen deze databases in plaats van om hun daadwerkelijke performance. Toen ik dit onderzoek begon, stonden niet de verschillen voorop, maar de zoektocht naar een performante database die een goed Azure-alternatief kon zijn voor onze MariaDB-monolith. Aanvankelijk dachten we dat de overstap van MariaDB naar MySQL een simpele vervanging was, met nauwelijks impact op de performance. Daar hadden we het mis!

“There are many opinions about performance, But we needed facts”

We zagen een enorme performance-regressie bij elke query. Performance is cruciaal voor ons, en het was verwarrend om te zien dat MySQL zo ver achterbleef bij MariaDB. Toen we dit ontdekten, hebben we zelf een MariaDB-VM in Azure opgezet. Die was weer wel performant, maar bracht veel extra onderhoud en beheer met zich mee: uptime garanderen, hot standby, backups.

Daarom ging ik PostgreSQL onderzoeken, in de hoop op betere performance dan MySQL bood. Met deze introductie: de tests die we hebben gedaan, met een complexe query en een set kleine queries, om de performanceverschillen tussen de drie databases en hun implementaties binnen Azure te meten. We hebben ook Docker-tests toegevoegd om te kunnen vaststellen of de performanceverschillen aan de databases liggen of dat Azure de oorzaak is.

Onze complexe query testen

Om de databases te beoordelen draaiden we een complexe query die data uit meerdere tabellen aggregeerde, een realistische workload voor ons systeem. Om vertrouwelijkheidsredenen hebben we de tabel- en kolomnamen in deze beschrijving aangepast. Deze query moest laten zien hoe elke database omgaat met data-aggregatie en complexe joins.

WITH AggregatedSkateData AS (
SELECT
    e.id AS eventID,
    e.theme_cid AS themeCID,
    s.id AS skateID,
    p.firstName || ' ' || p.lastName AS participantName,
    l.label AS locationLabel,
    s.priceOffered,
    s.inspectionCompleted,
    s.registrationDate,
    s.eventStartDate,
    org.name AS organizerName,
    'https://skateeventimages.net/' || im.path AS organizerImageURL,
    s.registrationCode,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 0 OR pa_last.id IS NULL THEN sp.id END) AS partsPending,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 1 THEN sp.id END) AS partsRequested,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 2 THEN sp.id END) AS partsConfirmed,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 8 THEN sp.id END) AS partsDenied,
    MAX(CASE WHEN ti_unscanned.id IS NOT NULL THEN 1 ELSE 0 END) AS hasUnscannedTickets,
    s.isPublic
FROM
    skateEvents s
    INNER JOIN events e ON s.eventID = e.id
    INNER JOIN participants p ON p.id = e.participantID
    LEFT JOIN organizers org ON org.id = e.organizerID
    LEFT JOIN images im ON im.id = org.profileImageID
    LEFT JOIN locations l ON l.id = s.locationID
    LEFT JOIN skateParts sp ON sp.eventID = s.id
    LEFT JOIN partApprovals pa ON pa.id = sp.partApprovalID
    LEFT JOIN ticketsUnscanned ti_unscanned ON ti_unscanned.id = sp.ticketID AND ti_unscanned.scannedAt IS NULL
    LEFT JOIN partApprovalActions pa_last ON pa_last.id = (
        SELECT pa2.id
        FROM partApprovalActions pa2
        WHERE pa2.partID = pa.id
        ORDER BY pa2.id DESC
        LIMIT 1
    )
WHERE
    s.registrationDate IS NOT NULL
    AND e.cancelledAt IS NULL
    AND e.deletedAt IS NULL
    AND s.isArchived = false
    AND s.deletedAt IS NULL
GROUP BY
    e.id, e.theme_cid, s.id, p.id, p.firstName, p.lastName, org.id, im.id, l.id, l.label, s.priceOffered, s.inspectionCompleted, s.registrationDate, s.eventStartDate, org.name, im.path, s.registrationCode, s.isPublic
)
SELECT * FROM AggregatedSkateData
WHERE
    TO_CHAR(s.registrationDate, 'YYYY-MM') = '2024-03'
    OR partsDenied + partsRequested + partsPending > 0
ORDER BY s.registrationDate DESC

Azure, complexe query

We hebben deze tests binnen dezelfde Azure-zone gedraaid voor containers en databases, om interzone-latency te vermijden. Hieronder de specificaties en resultaten, voor de transparantie. Opvallend: bij MariaDB en MySQL hadden de performancespecificaties nauwelijks invloed op de resultaten, mits we de eerste (burstable) tier vermeden. PostgreSQL was de uitzondering, met duidelijke verbeteringen bij de runtime van grote queries.

Met HeidiSQL via de Azure VPN hebben we onze beste resultaten van vijf runs bepaald.

MySQL Flexible, Zone 2 (Standard_E4ds_v5, 450 iops)
Found rows: 130
Duration for 1 query: 13,875 sec

MariaDB VM, Zone 2 (Standard B4s v2 (4 vcpus, 16 GiB memory))
Found rows: 130
Duration for 1 query: 10,625 sec
23,4% beter dan MySQL

Postgres Flexible, Zone 3 (Standard_E4ds_v50 p10, 500 iops)
Found rows: 130
Duration for 1 query: 3,953 sec
71,5% beter dan MySQL

Lokale Docker, complexe query

De hardware waarop we lokaal hebben getest:

12th Gen Intel(R) Core(TM) i9-12900H, 2900 Mhz, 14 Core(s), 20 Logical Processor(s)
Installed Physical Memory (RAM) 32,0 GB

MySQL 8.3 Docker
Found rows: 130
Duration for 1 query: 12,437 sec

MariaDB 11.4 Docker
Found rows: 130
Duration for 1 query: 9,484 sec

Postgres 16.2 Docker
Found rows: 130
Duration for 1 query: 3,969 sec

Daarmee zijn de tests met de complexe query afgerond. Geweldig om te zien dat Postgres hier zo goed presteert! Voor onze overstap naar Azure draaiden we op MariaDB. Het was behoorlijk vervelend om zo’n slechte performance in MySQL te zien zodra we met de nieuwe setup gingen testen.

Onze set kleine queries testen

De volgende test vuurt meer dan 20.000 transacties per seconde af op elke database, waarmee we een feed in JSON bouwen die een bepaalde tijd nodig heeft om af te ronden. Met veel queries belasten we de database beter, wat ons een gemiddelde runtime per database geeft. Er zit ook wat PHP-logica in, want dit is een PHP-script dat we draaien om de feed te genereren. Maar dat draait altijd op dezelfde hardware en hetzelfde docker-image, dus het verschil in runtime komt van de database. Hiervoor hebben we onze containers naar dezelfde zone verplaatst als waar de database draait, om ook mogelijke problemen met zone-latency uit te sluiten.

We draaien dit script binnen ons Laravel-framework. Onze PHP draait tegen Swoole voor de best mogelijke performance binnen PHP 8.

Azure, kleine queries

In deze test komen ook aspecten van containerperformance kijken. We draaien onze containers en database weer in dezelfde zone in Azure (West-Europa). Binnen Azure draaien we met een stuk minder performance dan we lokaal in onze docker-omgeving tot onze beschikking hebben.

Daarom kunnen we deze resultaten alleen gebruiken om de verschillen binnen docker en binnen Azure zelf te vergelijken, niet tussen die twee. Die met elkaar vergelijken zegt niets door dit hardwareverschil. We willen alleen het verschil in runtime tussen de databases zien, en Docker is de baseline om te checken of de verschillen overeenkomen met wat we in Azure zien.

Onze node size in Azure is een standard_b2s, 2 vCPU’s met 4 GiB RAM.

API, Zone 2 -> MariaDB VM, Zone 2
24,59s runtime (spot nodes)

API, Zone 2 -> MySQL Flexible, Zone 2
27,87s runtime (spot nodes)

API, Zone 3 -> Postgres Flexible, Zone 3
24,92s runtime (spot nodes)

Lokale Docker, kleine queries

Voor de kleine query-tests binnen lokale Docker gebruiken we een systeem met een 12th Gen Intel(R) Core(TM) i9-12900H CPU, draaiend op 2900 MHz met 14 cores en 20 logical processors, aangevuld met 32 GB RAM.

Deze Docker images zijn zo geconfigureerd dat ze memory-bound zijn, wat betekent dat de prestaties vooral afhankelijk waren van het beschikbare geheugen en niet beperkt werden door de CPU. De CPU-instellingen stonden op onbeperkte prestaties, zodat Docker zoveel CPU-bronnen kon gebruiken als nodig.

Voor elke testrun tegen een database herstartte ik de Docker container om de verbinding te verversen. Na de herstart hield ik een pauze van 30 seconden aan om er zeker van te zijn dat de container volledig gestabiliseerd en idle was. Die pauze is belangrijk voor consistentere testomstandigheden. Zodra de container klaar was, startte ik het feed generator script om de feed op te bouwen, om zo te beoordelen hoe goed onze verschillende database-setups kleine queries aankunnen onder deze gecontroleerde omstandigheden.

API -> MariaDB 11.4 Docker
22.88s runtime

API -> MySQL 8.3 Docker
23.74s runtime

API -> Postgres 16.2 Docker
20.77s runtime

MariaDB query cache

In ons eerdere gebruik van MariaDB binnen onze monolithische setup maakten we veelvuldig gebruik van de query cache. Deze functionaliteit speelde een cruciale rol bij het leveren van prestaties voor herhaalde queries. Die efficiëntie houdt stand totdat de cache herbouwd moet worden, meestal getriggerd door updates of inserts op de tabellen van de gecachte query. We doen een tweede run op onze complexe query met de query cache ingeschakeld.

Local MariaDB Docker
Found rows: 130
Duration for 1 query: 0,000 sec

De prestatiewinst van de query cache is echter niet overal even groot. Bij bijvoorbeeld gemiddeld 20.000 transacties per seconde met kleine queries zakte de runtime enigszins in. Deze variatie laat zien dat de query cache niet altijd hetzelfde niveau van optimalisatie oplevert, zeker onder hoge belasting. Maar daar later meer over.

API -> Local MariaDB Docker (query cache enabled)
17.30s runtime

API, Zone 2 -> MariaDB VM, Zone 2 (query cache enabled)
22.72s runtime (spot nodes)

De query cache in MariaDB werkt door de result set van SELECT queries op te slaan, samen met de querytekst. Wanneer een identieke query opnieuw wordt uitgevoerd (met dezelfde tekst en onder dezelfde database-userrechten), kan MariaDB de query-uitvoerfase overslaan en het resultaat direct uit de cache halen. Dit kan de uitvoertijd van vaak gedraaide queries die geen data wijzigen drastisch verlagen.

Wees voorzichtig met het gebruik van de query cache van MariaDB. Ondanks de voordelen is de query cache deprecated en standaard uitgezet in nieuwere versies van MariaDB 10.1.7 (en in MySQL vanaf versie 5.7.20), vanwege zorgen over de impact op prestaties in omgevingen met veel gelijktijdige transacties. Voor specifieke scenario’s, met name met een overwegend read-workload, kan de query cache nog steeds aanzienlijk betere prestaties opleveren. In MySQL 8 en hoger is hij volledig verwijderd.

Observatie over de Flexible Servers van Azure

Deze tests laten zien dat de prestaties van databases op de flexible servers van Azure aanzienlijk zijn verbeterd en dicht bij de prestaties van lokale Docker-omgevingen liggen. Dat is een flinke verbetering ten opzichte van de eerdere Azure database single servers, die doorgaans minder prestaties leverden door een vorm van overhead die voortkwam uit de manier waarop ze in de Azure-cloud draaiden.

Azure latency-anomalie

Als bonus hebben we nog wat extra tests gedaan om de interzone-latency te meten bij het verbinden van Zone 1 of 2 met een PostgreSQL-database in Zone 3 binnen Azure.

API, Zone 2 -> Azure PostgreSQL Flexible, Zone 3
De runtime was 44.23 seconden.

Interessant: de runtime verdubbelde opnieuw, een fenomeen dat we uitsluitend zien bij communicatie tussen Zone 1-2 en Zone 3, of andersom. Dit patroon suggereert dat elke container die een databaseverbinding nodig heeft onder deze omstandigheden aanzienlijke latency ondervindt, terwijl de latency vrijwel verwaarloosbaar is bij interactie tussen Zone 1 en Zone 2.

Voor wie het gemist heeft: ik heb eerder een latency-anomalie in Zone 3 besproken. De gangbare wijsheid is dat je de databaseverbinding binnen dezelfde zone houdt om latency te minimaliseren. Onze tests laten echter zien dat de latency-impact minimaal is tussen Zone 1 en 2, maar aanzienlijk wordt zodra je van Zone 1 of 2 naar Zone 3 gaat.

Deze tests bevestigen opnieuw dat het latency-probleem niet exclusief is voor MySQL Flexible services, maar ook PostgreSQL Flexible services binnen Azure raakt, wat wijst op een breder patroon in het database-aanbod van Azure.

Latency Anomaly: An attempt to untangle Azure Performance issues in Western EuropeUnveiling a significant Azure performance issue: Zone 3’s unexpected latency anomaly in the Western Europe region challenges cloud deployment strategies All Subjects MatterRemco Loup.

Conclusie

Vanuit prestatieoogpunt is het duidelijk dat de keuze voor de juiste database cruciaal is en moet aansluiten bij de specifieke snelheids- en efficiëntiebehoeften van je app. De resultaten laten zien dat MySQL vaak trager is. MariaDB presteert goed en heeft een handige query cache, maar Azure ondersteunt MariaDB niet meer. Daarmee is PostgreSQL de meest logische keuze voor prestatiegerichte gebruikers in Azure, want het blinkt uit in het verwerken van zowel complexe queries als grote aantallen simpele queries, zoals de tests hierboven laten zien.

Hopelijk helpt deze analyse bij het kiezen van de juiste databasetechnologie en onderstreept ze hoe belangrijk zorgvuldige planning is voor het verbeteren van je app-prestaties. Voor wie Azure gebruikt en topprestaties zoekt, is PostgreSQL in mijn testresultaten de beste optie.

Er zijn genoeg andere redenen om je database te kiezen. Maar in deze post wilde ik me alleen richten op performance. Dat was onze grootste zorg, want we zijn bezig met de overstap van een monolithische server naar Azure. Bij een database-switch komt nog meer kijken. Het voordeel hier is dat alle drie de databases zich redelijk makkelijk laten integreren, welke je ook kiest.

Postgres is hier het best compatibel dankzij zijn strikte routines. De gecompliceerde query hierboven is geschreven voor Postgres en draait in MariaDB zonder één wijziging. Voor MySQL hoef je alleen de TO_CHAR in de laatste regel te vervangen door DATE_FORMAT.

Introductie

We zijn begonnen aan een overstap van een traditionele VM-setup bij TransIP naar de schaalbare cloudinfrastructuur van Microsoft Azure. Die reis draait net zo goed om ontdekking als om prestaties. Met de expertise van Pionative als leidraad verhuizen we onze omgeving niet alleen; we proberen haar in Azure opnieuw op te bouwen, waarbij we elke stap zorgvuldig testen en analyseren. Ons doel? Optimale prestaties in deze nieuwe architectuur, en eventuele bottlenecks of verborgen problemen in onze nieuwe cloudarchitectuur zo vroeg mogelijk op het spoor komen.

Azure-regions en zones

De infrastructuur van Azure beslaat de hele wereld, georganiseerd in regions voor gelokaliseerde diensten, en verder onderverdeeld in zones voor hoge beschikbaarheid. Regions zijn specifieke geografische gebieden waar Azure-diensten draaien, terwijl zones fysieke locaties binnen die regions zijn, elk met eigen voorzieningen om storingen te isoleren.

De region Western Europe

De region Western Europe in Azure is opgebouwd uit drie aparte availability zones. Deze zones bieden een extra laag redundantie en fouttolerantie door datacenters binnen de region fysiek van elkaar te scheiden. Deze opzet moet garanderen dat zelfs bij een volledige uitval van één zone de diensten in de andere zones gewoon doordraaien — een stevige disaster recovery-oplossing voor bedrijven die in Europa actief zijn. Waar Zone 1, 2 en 3 geografisch precies liggen, is mij niet bekend.

Prestatie-anomalie in de region Western Europe

Ons testprogramma bracht ons bij een anomalie die het middelpunt van onze Azure-verkenning in deze post vormt: een duidelijk latency-probleem in Zone 3 van de region Western Europe. Deze ontdekking kwam niet meteen; ze kwam uit dagen prestatietesten en scherpe observatie van patronen die afweken van wat we verwachtten. Dat komt vooral doordat we Azure nog maar net aan het leren zijn, en door het prestatieverschil met onze huidige setup.

Eerst hebben we onze eigen pods, code en prestatie-instellingen binnen de node pool uitgesloten. Database-prestatie-instellingen en dat soort zaken.

Methodiek en bevindingen

Onze uiteindelijke aanpak was behoorlijk grondig om dit resultaat te verifiëren. We deployden twee node pools in elk van de drie zones van Microsoft Azure binnen de region Western Europe, om nodespecifieke verschillen uit te sluiten. Al die pools hadden exact dezelfde prestatie-instellingen.

Uit uitgebreide tests — waaronder een hele reeks database-aanroepen en de cron jobs die essentieel zijn voor de functionaliteit van onze applicatie — zagen we een consistent en verrassend patroon. Ongeacht de gerapporteerde capaciteit of drukte van de zone.

Interacties met de database waren aanzienlijk trager zodra de database óf de verbindende pods in Zone 3 stonden.

Prestatieresultaten

Hieronder onze situatie met een cronjob die lokaal in Docker tegen onze huidige setup zo’n 32 seconden nodig heeft. Die setup is niet vergelijkbaar met MS Azure, maar gaf ons wel een prestatiematrix en een doel. Het script (de cronjob) dat we draaiden vuurt zo’n 32.000 queries af om een feed te bouwen van alle producten op onze website. Ja, dat is veel, maar daar gaat het hier niet om. We wilden het prestatieprobleem blootleggen. We weten dat dit script geoptimaliseerd kan worden om beter te presteren.

MySQL-database in Zone 2
Zone 1 – pool 1: 33 seconden
Zone 1 – pool 2: 32 seconden

Zone 2 – pool 1: 32 seconden
Zone 2 – pool 2: 32 seconden

Zone 3 – pool 1: 115 seconden
Zone 3 – pool 2: 117 seconden

En toen, als klap op de vuurpijl, hebben we de setup omgedraaid met een database in Zone 3. Zie hieronder de resultaten die we hoopten te zien om dit onderzoek af te sluiten.

MySQL-database in Zone 3
Zone 1: 120 seconden
Zone 2: 122 seconden
Zone 3: 33 seconden

We zagen dezelfde consistentie terugkomen, elke keer opnieuw, ook toen we minder maar grotere database-aanroepen draaiden.

MySQL-database in Zone 2
16 DB-queries, single threaded.

Zone 1: Totale tijd voor queries uit log: 9,57 ms
Zone 2: Totale tijd voor queries uit log: 9 ms
Zone 3: Totale tijd voor queries uit log: 49,96 ms

Websiteprestaties in Azure

Als we onze database in Zone 2 draaien met de API-pod in Zone 1, daalt de initiële laadtijd van onze website met minstens 400 milliseconden bij de eerste page load, vergeleken met de configuratie waarin de API-pod in Zone 3 staat.

Dat betekent dat de setup met de database in Zone 2 en de API-pod in Zone 1 een veel snellere initiële responstijd voor de website oplevert dan wanneer de API-pod in Zone 3 staat en de database in Zone 2.

Er zit hier een foutmarge, maar uit deze resultaten kunnen we concluderen dat je, als je je API geografisch over twee zones wilt verdelen, nooit consistent kunt presteren met Zone 3. Zones 1 en 2 zijn de juiste keuze.

We moeten eerlijk zijn: deze prestatie-anomalie doet zich alleen voor bij een pod met een databaseverbinding. Onze website (die geen databaseverbinding heeft) in Zone 3 draaien had vrijwel geen meetbaar effect, zolang de API-pod in Zone 1 draaide en de database in Zone 2 stond.

Dieper duiken in de latency-problemen van Zone 3

Dit prestatieverschil in Zone 3 was voor ons verbijsterend. Volgens de best practices van Microsoft zou de fysieke nabijheid van applicatieservers bij hun databases binnen dezelfde regio de latency moeten minimaliseren. Onze bevindingen schetsten echter een ander beeld: de keuze van een zone binnen een regio kan flink invloed hebben op de performance van je applicatie.

Ons onderzoek was behoorlijk grondig. We hebben mogelijke variabelen uitgesloten, zoals onze eigen codebase, PHP-configuratie, MySQL-performance en meer. De aanhoudende latencyproblemen, vooral bij single-threaded cron jobs in PHP, wezen uiteindelijk richting een structureel probleem in de netwerkarchitectuur van Zone 3, of ergens in de deployment.

Samenwerking en leren

Ons traject, gedragen door de samenwerking met Pionative, onderstreept hoe waardevol het is om samen te werken als je door de complexiteit van de cloud moet navigeren. Hoe dieper we in deze latency-anomalie doken, hoe duidelijker werd dat we niet alleen onze eigen deployment wilden optimaliseren, maar onze bevindingen ook wilden teruggeven aan de bredere Azure-community.

Deze latency-impact is te groot om te negeren in onze productieomgeving.

Implicaties en vervolgstappen

Deze anomalie in Zone 3 roept discussies op over de optimale zonekeuze en deploymentstrategieën binnen de regio West-Europa van Azure. Is dit de reden dat Zone 3 de dunstbevolkte zone is? Online is er hier zo te zien weinig over te vinden. Daarom heb ik deze post geschreven: het kostte ons letterlijk dagen om dit prestatieverschil op te sporen.

Dit gaat invloed hebben op onze productieomgeving. We draaien onze DB in Zone 1 of 2, en de API moet in een van deze zones staan. Zone 3 kan gebruikt worden voor pods die met de API praten.

Deze latency-anomalie in Zone 3 was voor ons meer dan een uitdaging. We zagen het als een kans om te leren, aan te passen en onze kennis te verbreden. Terwijl we blijven samenwerken, testen en onze aanpak verfijnen, groeit ons Azure-traject uit tot een zeer interessante technische verkenning die onze toolkit voor de toekomst verruimt.

Deze post is een vervolg op GIT deployment-strategieën binnen Kubernetes-omgevingen. Lees eerst deze post:

CI/CD pipeline with Docker and Git branching strategyExplore advanced CI/CD with Docker & Git. Master deploying Docker artifacts via Git branching. Dive into strategies for DEV, STAGING, LIVE environments. Perfect your pipeline now! All Subjects MatterRemco Loup.

In een CI/CD-pipeline die draait om Docker artifacts, met de focus op één enkele branch, vraagt een efficiënte hotfix-strategie om een kleine afwijking van de standaardaanpak. Zo zorgen we dat kritieke fixes snel gedeployd worden. Laten we onze aanpak voor hotfixes in deze Docker-gerichte omgeving uitwerken, op basis van de branch-architectuur uit de post hierboven.

Wanneer is een hotfix nodig?

Hotfixes zijn cruciaal voor de stabiliteit en betrouwbaarheid van elke software in productie. Ze zijn meestal nodig in situaties die directe actie vragen. Weten wanneer je een hotfix inzet, is essentieel om je CI/CD-pipeline goed te beheren, zeker als je werkt met Docker artifacts en een gestroomlijnde branch-strategie met één hoofdbranch. Dit zijn onze scenario’s waarin een hotfix nodig kan zijn:

1. Beveiligingslekken: Een van de meest urgente redenen voor een hotfix is het ontdekken van een beveiligingslek in je applicatie. Of het nu gaat om blootgestelde data, risico op ongeautoriseerde toegang of een andere kwetsbaarheid die kwaadwillenden kunnen misbruiken: je moet snel handelen om het lek te dichten en je gebruikers en data te beschermen.
2. Kritieke bugs die de gebruikerservaring raken: Als een serieuze bug door je testproces heen glipt en in productie belandt, kan dat de gebruikerservaring flink raken. Dat kan van alles zijn: een kapotte kernfunctionaliteit waardoor gebruikers de applicatie niet meer kunnen gebruiken, of ernstige performanceproblemen die leiden tot timeouts of crashes. Raakt het probleem een groot deel van je gebruikers? Dan is een hotfix op zijn plaats.
3. Compliance-problemen: Sommige applicaties hebben te maken met wettelijke of regelgevende eisen. Als er een compliance-probleem wordt geconstateerd dat je juridische positie of de privacy van gebruikers kan raken, moet dat snel met een hotfix worden opgelost om boetes of verlies van vertrouwen te voorkomen.
4. Risico op dataverlies: Situaties waarin gebruikersdata verloren kan raken of corrupt kan worden, vragen om directe actie. Of het nu een fout is in hoe data wordt opgeslagen, bijgewerkt of opgehaald: deploy dan een hotfix om verlies of corruptie van gebruikersdata te beperken.
5. Falende betalingen of transacties: Voor applicaties die betalingen of andere transacties verwerken, zijn problemen die transacties blokkeren of tot financiële discrepanties leiden kritiek. Zulke problemen schaden niet alleen het vertrouwen van gebruikers, maar kunnen ook financiële gevolgen hebben voor zowel gebruikers als de dienstverlener. Een hotfix is dan noodzakelijk.

Een hotfix deployen

Als er een kritiek probleem in de productieomgeving wordt geconstateerd, is het doel om zo snel mogelijk een hotfix te ontwikkelen, testen en deployen. Omdat MAIN onze hoofdbranch voor development is en we Docker artifacts genereren voor deployment, hebben we een proces nodig dat snelle interventie mogelijk maakt zonder het lopende werk te verstoren.

1. Een hotfix-branch aanmaken: In plaats van te branchen vanaf je Production branch (LIVE bestaat in deze strategie immers niet meer in de Git-repository), maak je de hotfix-branch vanaf de commit die op dat moment in productie draait. Zo is de hotfix gebaseerd op exact de versie die in de productieomgeving draait. De specifieke commit vind je via tags of Docker image-labels die gekoppeld zijn aan de productie-deployment.
2. De hotfix ontwikkelen en testen: De kritieke fix wordt ontwikkeld binnen deze hotfix-branch. De urgentie vraagt om een gerichte aanpak: pak het probleem aan met minimale wijzigingen om testen en deployen te versnellen. Ook onder tijdsdruk is het naleven van de Definition of Done (DoD) cruciaal voor de stabiliteit en betrouwbaarheid van de hotfix. Dat kan een compactere versie van de DoD zijn, met prioriteit voor de kritieke tests en checks die garanderen dat de fix geen nieuwe problemen introduceert.
3. Een Docker artifact voor de hotfix maken: Zodra de hotfix aan de afgesproken DoD-criteria voldoet, bouwt een geautomatiseerd proces een Docker image van de hotfix-branch. Dit Docker artifact krijgt een passende tag, zodat duidelijk is waar het voor dient en hoe urgent het is.
4. De hotfix deployen: Het nieuwe Docker artifact wordt direct in de productieomgeving gedeployd, waarbij de gebruikelijke route via DEV en STAGING naar PRODUCTION wordt overgeslagen. Deze deployment is alleen te rechtvaardigen door de kritieke aard van de fix en de tests die erop zijn uitgevoerd.
5. Terugmergen en consistentie bewaken: Als de hotfix succesvol in productie draait, is het essentieel om de wijzigingen terug te mergen naar de MAIN branch en eventuele andere relevante branches of tags. Pas deze stap zorgt ervoor dat de fix wordt opgenomen in het lopende developmentwerk en toekomstige releases, en dat je geen regressie krijgt!!

Snel deployen en zo min mogelijk storing

• Geautomatiseerde processen: Automatisering speelt een sleutelrol in deze strategie, van het maken van het Docker artifact tot de deployment. Geautomatiseerde tests, builds en deployments zorgen dat het hotfix-proces zo snel en efficiënt mogelijk verloopt.
• Communicatie en monitoring: Snelle deployment van hotfixes vraagt om heldere communicatie binnen het team en nauwe monitoring van de productieomgeving na de deployment, om te verifiëren dat de fix werkt en geen nieuwe problemen introduceert.
• Documentatie en review: Het documenteren van het hotfix-proces en het doen van post-mortem-reviews helpt om de hotfix-strategie te verfijnen, zodat het team bij toekomstige problemen nog effectiever kan reageren.

Conclusie

In een CI/CD-pipeline met Docker en Git Flow als hoofdstrategie vraagt een hotfix om een strakke aanpak: gebruik de automatisering die er al is en focus op snelle, gerichte fixes. Door hotfix-branches te baseren op de commit die in productie staat, fixes te bouwen en testen volgens een goed gedefinieerde Definition of Done, en de Docker-artifacts direct naar productie te deployen, lost een team kritische problemen snel op zonder de stabiliteit en integriteit van de applicatie in gevaar te brengen.

In deze post ga ik in op het beheren van een CI/CD-pipeline met Docker, met de nadruk op een Git branching-strategie met een development- (DEV), staging- (STAGING) en production-branch (LIVE). Het doel is duidelijk maken welke rol elke branch speelt in het proces, en vooral hoe Docker-artifacts binnen dat stramien worden aangemaakt en beheerd.

Docker-deployments met Git Flow en meerdere branches

De kern van onze branching-strategie bestond uit drie branches:

1. DEV: Hier gebeurt alle ontwikkeling. Elke nieuwe feature, bugfix of verbetering start in een feature branch, afgesplitst van DEV. Is het werk af, gereviewd en voldoet het aan de Definition of Done (DoD), dan wordt het gemerged naar DEV.
2. STAGING: Deze branch spiegelt een pre-productieomgeving. Hier worden geïntegreerde features uit DEV als geheel getest en door stakeholders geaccepteerd, zodat we zeker weten dat alles samenwerkt.
3. MASTER: De branch die de huidige staat van onze live-omgeving weerspiegelt. Alleen grondig geteste en door stakeholders goedgekeurde wijzigingen uit STAGING halen het tot Productie.

Git Branching and Branching StrategyIn this post, we will go over why branching is required, the difference between development, staging… DEV CommunityPreetham

Dit was onze variant op een Git Flow-strategie, die we tot nu toe gebruikten. Zodra je met artifacts gaat werken, verandert dat allemaal terug naar een normale Git Flow-structuur. We hebben nog steeds omgevingen die draaien (Dev, Staging en Prod). Het echte verschil is dat code nu één keer gecommit wordt, in plaats van gemerged te worden naar een branch die op Staging of in Productie draait.

In plaats daarvan hebben we nu één branch, die we Main noemen. Daar wordt na een geslaagde code merge met Docker images een runnable artifact aangemaakt. Alles wat we op Staging of in Productie deployen is een specifieke versie van een eerder aangemaakt artifact.

Het grootste verschil: STAGING en PROD zijn geen branches meer waar je code in merged. Het zijn omgevingen geworden die een specifieke versie van een Docker image draaien. Dat brengt eigen uitdagingen met zich mee, zeker bij een hotfix. Hotfixen krijgt een eigen post, die je na deze kunt lezen. Ik loop het nu eerst stap voor stap door, zonder de hotfix erbij. Het is al omvangrijk genoeg zo.

Wat is een artifact?

Een Docker-artifact, vaak door elkaar gehaald met een Docker image, is een lichtgewicht, zelfstandig uitvoerbaar package dat alles bevat wat nodig is om een stuk software te draaien: de code, een runtime, libraries, omgevingsvariabelen en configuratiebestanden. Simpel gezegd: een snapshot van je applicatie én de omgeving eromheen, samen verpakt, klaar om overal gedeployed en gedraaid te worden waar Docker is geïnstalleerd. Zo weet je dat alles in verschillende omgevingen consistent werkt.

Het belang van de DoD bij het mergen van code

Een volledige en heldere Definition of Done (DoD) speelt in dit nieuwe proces een sleutelrol, zeker nu alle wijzigingen in één enkele branch gemerged worden die een Docker image moet opleveren die runnable en deployable is:

• Kwaliteitsborging: De DoD zorgt dat alle wijzigingen — nieuwe features, verbeteringen en hotfixes — die terug in MAIN gemerged worden aan een consistent kwaliteitsniveau voldoen. Denk aan code quality checks, succesvol doorlopen geautomatiseerde tests en het volgen van security best practices.
• Regressie voorkomen: Door de DoD toe te passen op alle merges naar MAIN voorkomt het team regressies en zorgt het dat nieuwe wijzigingen bestaande functionaliteit niet breken. Cruciaal voor de integriteit en stabiliteit van de codebase.
• Deployments soepeler laten verlopen: Een duidelijke en volledige DoD maakt deployments makkelijker, omdat alleen volledig gecontroleerde, deploy-klare wijzigingen in MAIN gemerged worden. Zo verspil je geen resources aan het bouwen van Docker images met bugs of die helemaal niet werken, en dat levert efficiëntere en betrouwbaardere artifacts op.

Artifacts aanmaken en beheren

De eerste voorwaarde om dit proces te laten werken: zodra een afgesplitste branch terug in MAIN gemerged wordt, start dat een geautomatiseerd proces in onze CI/CD-pipeline. Dit gebeurt er:

1. Geautomatiseerde tests: Eerst draaien de geautomatiseerde tests om te checken of de nieuwe wijzigingen aan onze kwaliteitsnormen voldoen. Cruciaal voor een stabiele branch.
2. Docker-artifact aanmaken: Zijn alle tests geslaagd, dan wordt er een Docker image (ons artifact) van de MAIN-branch gebouwd. MAIN is immers de enige branch die de laatste staat van alle afgeronde ontwikkeling vertegenwoordigt. Van daaruit genereren we artifacts die “shippable” producten kunnen worden.
3. Waarom MAIN voor Docker-artifacts?: Door artifacts op dit moment aan te maken vangen we integratieproblemen vroeg op. Omdat elke feature die in MAIN gemerged wordt als release-klaar wordt beschouwd, heb je door hier een artifact te genereren altijd een geteste en potentieel deploybare versie van je product bij de hand.

Van branches naar omgevingen

In traditionele Git-workflows staan branches als STAGING en PROD voor verschillende fasen in het ontwikkelproces, van testen tot productie. In een Docker-gecentreerde CI/CD-pipeline verschuift de focus: deze branches dienen niet langer voor code-integratie, maar als referentie voor deployment-omgevingen.

Deployen naar STAGING

• Docker-artifacts aanmaken: zodra de ontwikkeling klaar is en gemerged is naar de MAIN-branch, wordt er automatisch een Docker-artifact aangemaakt. Dat artifact is een snapshot van je applicatie op dat moment, met alle wijzigingen die gemerged zijn.
• Deployen in plaats van mergen: de rol van de STAGING-omgeving is om dit Docker-artifact te testen onder omstandigheden die sterk lijken op productie. In plaats van code van MAIN naar een STAGING-branch te mergen, deploy je het Docker-artifact naar een STAGING-omgeving. De code zelf beweegt dus niet tussen branches; het is de gecompileerde en gecontaineriseerde versie van je applicatie die getest wordt.
• Het doel van STAGING: de STAGING-omgeving is essentieel voor uitgebreide tests, waaronder performance- en security-assessments. Het is een laatste check om te verifiëren dat alles werkt zoals verwacht in een productie-achtige omgeving, zonder je echte gebruikers direct te raken.

Naar productie

• Goedkeuring van stakeholders: zodra je Docker-artifact grondig getest is in STAGING en goedgekeurd is door de stakeholders, is het klaar voor productie. Deze stap is cruciaal om te garanderen dat alle features, fixes en updates aan de nodige standaarden en verwachtingen voldoen.
• Deployen naar productie: de overgang van STAGING naar PROD betekent dat je het geteste Docker-artifact deployt naar je productieomgeving. Dit deploymentproces garandeert consistentie: het exacte artifact dat in STAGING getest is, wordt naar PROD gedeployd. Zo zijn er geen verschillen tussen geteste en gedeployde code.

Belangrijkste punten

• Geen branch-merges meer voor deployment: in deze gestroomlijnde workflow worden STAGING- en PROD-branches niet meer gebruikt om code te mergen. In plaats daarvan verwijzen ze naar specifieke deployment-omgevingen waar Docker-artifacts voor tests en productie gedeployd worden.
• Focus op artifacts: de nadruk ligt op het aanmaken, testen en deployen van Docker-artifacts. Deze artifacts vertegenwoordigen stabiele versies van je applicatie, klaar voor STAGING en uiteindelijk voor PROD.
• Consistentie en betrouwbaarheid: door hetzelfde Docker-artifact van STAGING naar PROD te deployen, weet je zeker dat wat getest is exact is wat er uitgebracht wordt. Dat vergroot de betrouwbaarheid en voorspelbaarheid van je deployments.

Deze aanpak vereenvoudigt het deploymentproces, verkleint het risico op fouten en zorgt ervoor dat elke release grondig getest wordt in een omgeving die productie zo nauw mogelijk benadert.

Zijn meerdere branches nog nodig?

In deze nieuwe workflow hebben de STAGING- en PROD-branches in de Git branching strategy geen actieve functie meer en zijn ze dus overbodig geworden. Ze hielpen om bij te houden welke versies van de code naar welke omgeving gedeployd waren. Dat probleem hebben we nu opgelost door een specifieke versie van een artifact te draaien.

Conclusie

Door Docker op te nemen in onze Git branching strategy stroomlijnen we het hele traject van development tot deployment: elke merge naar MAIN triggert een Docker-image met de potentie om naar productie te gaan. De sleutel van deze strategie is het vroeg in de developmentcyclus aanmaken van Docker-artifacts, zodat continuous integration en delivery mogelijk blijven zonder in te leveren op kwaliteit en stabiliteit.

Door de veranderingen aan de Git-branches te begrijpen en het proces van het aanmaken en deployen van Docker-artifacts, kunnen we met vertrouwen omgaan met de complexiteit van CI/CD. Zo leveren we alle nieuwe features en fixes zo efficiënt en betrouwbaar mogelijk af bij de gebruikers.

Hotfixes

We hebben het nog niet gehad over hotfixes. Zoals ik al zei, verdient dit een eigen post. Je leest hier alles over hotfixes en de valkuilen die daarbij komen kijken.

Hotfixing with Docker Artifacts in a Single Branch StrategyMaster hotfixes in Kubernetes with Docker. Learn to rapidly deploy critical fixes in a CI/CD pipeline focusing on streamlined branching. Perfect for tackling urgent issues without disrupting flow. Dive in now. All Subjects MatterRemco Loup.

Als techliefhebber heb ik veel ontwikkelingen in AI zien langskomen, vooral op het gebied van taalverwerking en interactie met gebruikers. Als ik daarop terugkijk, wil ik al een tijdje delen waarom de recente sprongen in AI volgens mij minder verrassend zijn dan je misschien denkt.

Ik gebruik door elkaar heen verschillende termen voor hetzelfde. Ik spreek over AI en over LLM (Large Language Model) voor de huidige generatie systemen zoals ChatGPT.

Mijn eerste kennismaking met “AI”

Mijn reis met LLM’s begon eerder dan veel mensen beseffen. Mijn eerste ervaringen met Flow.ai had ik rond 2018/2019. Toen was mij al duidelijk dat er iets stond te gebeuren. Het grote publiek had echter nauwelijks door wat er in de AI-ontwikkeling broeide. Feit is dat bedrijven als Flow.ai (inmiddels onderdeel van Khoros) de fundering legden voor de AI-systemen van nu, zoals ChatGPT.

Lees anders het stuk dat ik in 2019 schreef over onze ervaringen met Flow.AI, samen met Stefan Samba.

2019 - Blast from the past: How 333travel is revolutionizing the Travel industryDiscover how 333travel’s AI ‘Joy’ redefines customer interaction, blending AI’s intent understanding with personal touch. A game-changing journey in AI-led travel solutions! All Subjects MatterRemco Loup.

Flow.ai: een gemiste kans voor 333travel

Flow.ai was voor mij toen een eyeopener. Het liet me zien wat neural network-gebaseerde conversationele AI in huis had. Als ik er nu op terugkijk, waren we met de integratie van deze technologie bij 333travel in 2018 misschien onze tijd te ver vooruit. Onze natuurlijke manier van mensen helpen met het aanvragen van een voorstel kreeg met een LLM niet de grip die we hoopten. Onze klanten (gelukkig?) wilden liever met menselijke specialisten praten dan met bots. Dat maakte duidelijk dat de technologie veelbelovend was, maar dat de markt er nog niet klaar voor was.

Mensen vonden het vreselijk om met “ouderwetse” chatbots te praten die je niet begrepen, door het gebrek aan intent-understanding.

Het voorbeeld van Siri

Laten we het even over Siri hebben, de virtuele assistent van Apple. Sinds de lancering in 2011 heeft Siri wel wat stappen gezet. Maar naar mijn mening zijn die verbeteringen op het gebied van intent learning op z’n best bescheiden. Siri, net als tools als Cortana en Google Assistant, had nog steeds hele specifieke commando’s nodig en begreep intenties vaak niet. Er is wel wat vooruitgang geboekt, maar de leercurve in het begrijpen van menselijke taal — en vooral intentie — was veel te traag.

• 2010-2011: In de eerste jaren werd Siri geïntegreerd in de iPhone 4S, met basale spraakherkenning en commando-uitvoering.
• 2012-2013: Uitbreiding naar nieuwe talen en dialecten, waardoor de gebruikersbasis groeide.
• 2014-2015: Toetreding tot nieuwe markten en de lancering van SiriKit, waarmee apps van derden konden integreren.
• 2016-2018: Introductie op macOS en de release van Shortcuts voor gepersonaliseerde spraakcommando’s.
• 2020-2021: matige verbeteringen in taalvertaling, integratie met het ecosysteem van Apple en betere spraakherkenning.

AI en klantinteractie

Als techliefhebber vind ik ChatGPT op veel vlakken indrukwekkend, maar het is geen vervanging voor de gedetailleerde kennis die menselijke specialisten bieden. Neem nou een touroperator. Een goed reisplan opstellen is een heel ander verhaal. Het laatste wat je wilt, is dat daar fouten in sluipen.

Waarom zou je een AI met de klant laten praten en die daarna vervangen door een mens? Is het omgekeerde niet veel logischer? Laat onze specialisten een AI gebruiken om een persoonlijk reisplan te maken en dat sneller versturen met AI. Je klant bind je in de verkoop nog altijd het beste met echte menselijke interactie.

Als je niet weet waar je het over hebt, kun je fouten in de antwoorden van een AI ook niet herkennen. Dat blijft altijd een grote zorg. Kennis uit de eerste hand blijft verplicht. Daarom is iets als ChatGPT een tool die gebruikt moet worden door mensen die het onderwerp beheersen, om hun werk te versnellen.

Ik geloof niet in losse integraties op websites die ruimte innemen en doen alsof ze een slimme AI zijn. De zoekfunctie die al op websites aanwezig is, lost dit probleem op. En mensen die een AI (LLM) gaan gebruiken, willen niet elke keer met een andere LLM praten. Ze zetten hun eigen PA in om die vragen te beantwoorden, als dat nodig is.

De eerste stap die bedrijven moeten zetten, is een zoekmachine op hun website implementeren die intentie begrijpt. Door intentie te begrijpen kun je mensen een echt nuttig antwoord geven, gebaseerd op de content op je website.

Je hebt een diepgaande integratie nodig tussen je LLM en je rijke content. Zeker in de reisbranche. Je website slimmer maken met een LLM is volgens mij veel logischer dan een popup-“persoon” waarmee je kunt chatten.

De toekomst van AI is ongetwijfeld spannend, maar het is een pad dat we met zowel optimisme als voorzichtigheid moeten bewandelen.

Mijn blik op de toekomst van AI

Vooruitkijkend zie ik AI als een vakgebied vol mogelijkheden, maar ook vol uitdagingen. De reis van de vroege systemen met vaste commando’s naar de intuitieve, contextbewuste modellen van vandaag is fascinerend geweest. Toch is er nog een lange weg te gaan voordat AI mensen echt kan begrijpen en op een dieper niveau met mensen kan omgaan.

Conclusie

De recente ontwikkelingen van AI lijken voor veel mensen plotseling en verrassend, maar ze zijn onderdeel van een lang, doorlopend proces van technologische evolutie. Mijn ervaringen bij 333travel, vooral met innovatieve platforms als Flow.ai, hebben me de potentie én de beperkingen van AI laten zien. Voor de toekomst vind ik het cruciaal om ons enthousiasme voor AI af te wegen tegen een realistisch beeld van wat het nu wel en niet kan.

Je bent uniek door dingen dicht bij jezelf te houden, niet door technologie je kernactiviteiten te laten overnemen. Houd altijd een persoonlijke touch!