Terug naar casestudy’s

Onafhankelijke platformengineering

Zelfgehost softwaredeliveryplatform

Provideronafhankelijke Linux-infrastructuur voor het ontwikkelen, testen, deployen, monitoren, back-uppen en beheren van gecontaineriseerde Angular-, .NET- en PostgreSQL-applicaties.

RolPlatformeigenaar, architect, ontwikkelaar en operator
Periode2010 - heden

Context en verantwoordelijkheid

Ik ontwerp en beheer een zelfbeheerd Linux-platform dat applicatiearchitectuur dicht bij delivery en operations houdt. Het doel is niet om een hyperscalecloud na te bouwen. Het doel is het volledige pad van ontwikkeling tot een herstelbare productierelease expliciet, draagbaar en begrijpelijk te maken.

Ik ben eigenaar van het platform als architect, ontwikkelaar en operator: ontwikkelomgevingen, broncodebeheer, runners, containerimages, ingress, applicatienetwerken, databanken, observeerbaarheid, back-ups en releaseherstel.

Geanonimiseerde platformtopologie

flowchart LR
    Dev[Linux of Windows 11 met WSL] --> GitLab[Zelfgehoste GitLab]
    GitLab --> Runner[GitLab Runner]
    Runner --> Registry[Containerregistry]
    Runner --> VPS[Beveiligde Linux-VPS]
    Users[Publieke gebruikers] --> Ingress[TLS-reverseproxy]
    Ingress --> Web[Angular-applicaties]
    Ingress --> Api[ASP.NET Core-API's]
    Api --> Db[(PostgreSQL)]
    Web --> Observe[Prometheus en Grafana]
    Api --> Observe
    Db --> Backup[Dagelijkse back-ups]
    Mail[Mailplatform] --> Backup

Draagbare ontwikkeling

De ontwikkelworkflow werkt op native Linux, Windows 11 met WSL, Docker Desktop en zelfstandige Docker Engine. Door build- en runtimegedrag te containeriseren, is de workflow minder afhankelijk van één workstationproduct en zijn lokale, runner- en serveromgevingen eenvoudiger te vergelijken.

Oplevering met healthchecks

sequenceDiagram
    participant Dev as Ontwikkelaar
    participant CI as GitLab CI
    participant Stage as Staging
    participant Prod as Productie
    Dev->>CI: Gereviewde wijziging pushen
    CI->>CI: Valideren, testen en image bouwen
    CI->>Stage: Ongewijzigde image deployen
    CI->>Stage: Healthcheck en publieke route verifiëren
    alt Verificatie slaagt
        CI->>Prod: Geverifieerde image promoveren
        CI->>Prod: Healthcheck en publieke route verifiëren
    else Verificatie mislukt
        CI->>Stage: Vorige gezonde release herstellen
    end

GitLab-pipelines valideren configuratie, voeren geautomatiseerde tests uit, bouwen geversioneerde images, deployen naar een geïsoleerde stagingomgeving en controleren de healthstatus vóór promotie naar productie. Referenties naar eerdere releases blijven beschikbaar voor rollback.

Beveiliging, observeerbaarheid en continuïteit

Publiek verkeer komt binnen via een TLS-reverseproxy. Hostpoorten van web en API zijn alleen via loopback bereikbaar, applicatie- en databanknetwerken zijn gesegmenteerd, deploymentsecrets blijven buiten de broncode en databanken zijn niet publiek bereikbaar. Healthendpoints, Prometheus-metrics, Grafana-dashboards, logs en dagelijkse back-ups maken de operationele status zichtbaar.

Langdurig beheer van mailinfrastructuur

Ik beheer sinds november 2010 een multi-domain mailplatform met iRedMail, Roundcube en SOGo. Het platform ondersteunde op het hoogtepunt 40 maildomeinen, bevat momenteel meer dan een miljoen berichten en doorliep drie servermigraties. Ik beheer de DNS-, TLS-, DKIM-, SPF-, DMARC- en back-upconfiguratie.

Gemeten opleverkwaliteit

De gedeployde Chronobat-website behaalde op 21 juli 2026 een score van 100 voor Performance, Accessibility, Best Practices en SEO in gedateerde Google PageSpeed Insights-labtests op zowel mobiel als desktop. Het resultaat is een momentopname van prestatie- en technische SEO-optimalisatie, geen garantie op een permanente score.

Door deze hele keten rechtstreeks te beheren, worden architectuurbeslissingen scherper: elke afhankelijkheid heeft een operationele kost, elke deployment heeft een foutpad nodig en elke back-up moet als onderdeel van het systeem worden behandeld in plaats van als bijzaak.