BK cloud / systemen Werk
NL
English ENDeutsch DEEspañol ES中文 ZHFrançais FRPortuguês (Brasil) PT-BR日本語 JAहिन्दी HINederlands NL
Laten we kennismaken ↗
← HomeWerk
02 / GESELECTEERD WERK

Verhalen over techniek,
meer dan alleen projectnamen.

Drie systemen die laten zien hoe ik vanuit een echte beperking naar een betrouwbaar en inzichtelijk resultaat werk.

UITGELICHTE COLLECTIE

Cloudbeheer: lessen die samenkomen

CDN, monitoring, virtualisatie en AWS. Vier verhalen over systemen beter laten werken.

Verken de collectie ↗
PRAKTIJK 01

AWS · PLATFORM ENGINEERING · OBSERVABILITY

2AWS-regio’s gecoördineerd

Een oude WordPress-site werd een snel, statisch AWS-platform met een kleiner aanvalsoppervlak, geautomatiseerde levering en transparante bezoekersanalyse.

Uitdaging

Een onderhoudsintensief CMS vervangen zonder jaren aan materiaal, een persoonlijk karakter of ruimte voor verdere ontwikkeling te verliezen.

Aanpak

Inhoud en presentatie scheiden, de frontend opnieuw bouwen en die via een private S3-origin achter CloudFront aanbieden.

Resultaat

Een responsief portfolio met gecontroleerde toegang tot de origin, beveiligingsheaders, deploymenttools, toegangslogs en inzicht via CloudWatch.

INTERACTIEVE ARCHITECTUUR

Ontdek het platform achter deze pagina.

Kies een component om te zien waarom die bestaat en hoe die bijdraagt aan beveiliging, veerkracht, waarneembaarheid en herstel.

→ →
TOEGANGSPUNT

Route 53

Leidt het openbare domein naar CloudFront, terwijl DNS-beheer expliciet en onafhankelijk herstelbaar blijft.

  • DNS
  • Beschikbaarheid
Beveiliging
Monitoring
Herstel
Kostenprofiel
Verbonden met
Lees de praktijkbeschrijving

Het keerpunt. Het doel was meer dan WordPress naar een ander hulpmiddel kopiëren. Ik wilde onnodige runtimecomplexiteit wegnemen en tegelijk zeggenschap houden over ontwerp, inhoud en beheer.

De bouw. Het openbare toegangspunt ligt bij CloudFront; de S3-origin blijft privé dankzij Origin Access Control. Route 53 verzorgt DNS, responseheaders beveiligen de levering en herhaalbare uitrolscripts houden releases voorspelbaar.

De feedbacklus. Geaggregeerde toegangsgegevens, statuscodemetingen, geografische rapportage en bewaarde logs maken het platform inzichtelijk. De site zelf documenteert nu de technische keuzes erachter.

  • AWS
  • CloudFront
  • S3
  • Route 53
  • CloudWatch
  • HTML / CSS / JavaScript
PRAKTIJKVOORBEELD 02

FULL-STACK · DATAVISUALISATIE · MOBIELE UX

63sessies bijgehouden

Ik bouwde Kraftwerk, een app om trainingsgegevens in te voeren: oefeningen, gewichten en herhalingen per set. De app combineert een trainingslogboek met historie en voortgangsanalyse.

Uitdaging

Breng versnipperde sessie-, volume- en activiteitsgegevens samen in één betrouwbare geschiedenis, zonder het vastleggen van trainingen te vertragen.

Aanpak

Werk met gevalideerde gegevens, importworkflows, aanpasbare plannen en selecteerbare dag-, week- en maandbereiken voor grafieken.

Resultaat

Een trainingsweergave ontworpen voor mobiel, met blijvend opgeslagen sessies, duidelijke volumeontwikkeling, stappengegevens en trends over langere tijd.

Lees de praktijkbeschrijving

De app die ik programmeerde. Kies een oefening en voer de trainingsdatum, gewichten en herhalingen per set rechtstreeks in de app in. De opgeslagen sessies vormen de basis voor de geschiedenis, volumeberekeningen en voortgangsgrafieken. De openbare Kraftwerk-pagina toont deze trainingsgeschiedenis alleen-lezen. Lees hoe Kraftwerk begon →

Data met context. Sessiemetrieken, totaalvolume, stappen en periodekeuzes plaatsen afzonderlijke trainingen in week- en maandpatronen.

Gebouwd om door te groeien. CSV- en gezondheidsdata-import houden historische gegevens overdraagbaar, terwijl de presentatielaag nieuwe meetwaarden kan krijgen zonder de onderliggende gegevens te herschrijven.

KRAFTWERK / MISSIELOGBOEK

Van papier naar vooruitgang.

Vier haltes in het verhaal van een app rond mijn eigen training.

Mijn oorspronkelijke notities over opdrukken.
Mijn oorspronkelijke notities over opdrukken.
Halte 1 / 4
Het begon met een schrift.

Ik kon geen geschikte trainingsapp vinden. Dus noteerde ik datums en herhalingen met de hand. Dit is mijn oorspronkelijke pagina voor push-ups.

  • Responsieve interface
  • Gevalideerde API’s
  • CSV-import
  • Gezondheidsgegevens
  • Interactieve grafieken
PRAKTIJK 03

OBSERVABILITY · BEHEER · AUTOMATISERING

24/7storingsdienstteam

Toen ik in 2000 begon, bestond het uitgangspunt uit een handvol servers en scripts voor loganalyse, niet uit een monitoringsysteem dat de groeiende complexiteit kon bijhouden.

Uitdaging

Reactieve loganalyse vervangen door monitoring die met de infrastructuur kon meegroeien en problemen signaleerde voordat gebruikers ze meldden.

Aanpak

Begin met Nagios en Zabbix, voeg servicechecks en meldingen toe en bewaar prestatiemetingen voor trendanalyse.

Resultaat

Een steeds verder ontwikkelde monitoringpraktijk, later aangevuld met Grafana en Checkmk, die vroege waarschuwingen combineert met inzicht in de operatie op langere termijn.

Lees de praktijkbeschrijving

Een kleine omgeving met een groeiende blinde vlek. Aanvankelijk waren er alleen een handvol servers en scripts die logbestanden analyseerden. Toen het platform groeide, kon die aanpak de schaal en complexiteit niet bijhouden. Bovendien was die reactief: hij vertelde ons wat er al was gebeurd.

De baas en de klant zijn geen monitoringtools. Waarom wachten tot er iets misgaat om het op te merken? Als een leidinggevende of klant als eerste een storing meldt, loopt beheer al achter. Naast het incident zelf brengt dat ook het vertrouwen in het team in gevaar, binnen en buiten de organisatie.

Het klassieke voorbeeld: een TLS-certificaat dat bijna verloopt. In 2000 bestond de automatisering voor certificaatvernieuwing die we nu kennen nog niet in dezelfde vorm. Let’s Encrypt kwam veel later, in 2015. We moesten naderende vervaldata bewaken in plaats van ze via een verbroken verbinding te ontdekken. Certificaateisen en uitgevers kunnen verschillen; ook een geautomatiseerd vernieuwingsproces moet worden bewaakt.

Detecteren, melden en het bewijs bewaren. Onze eerste keuzes waren Nagios en Zabbix. We hadden controles nodig die problemen ontdekten en meldingen die iemand bereikten die kon ingrijpen. Meldingen gingen vooral naar het team met 24/7-bereikbaarheidsdienst, zodat incidenten dag en nacht konden worden opgepakt. Door kostenbeperkingen had de website toen nog geen hoogbeschikbare architectuur. Betrouwbare detectie en snel reageren waren daarom essentieel voor de best mogelijke dienstverlening; monitoring zelf nam het risico op uitval niet weg. In de loop der jaren kwamen daar SMS, WhatsApp en PagerDuty als meldingskanalen bij. Dat waren latere ontwikkelingen; ik beweer niet dat die allemaal in 2000 werden gebruikt.

Van incidenten naar trends. Door prestatiemetingen vast te leggen kon ik verder kijken dan één alarm: hoe ontwikkelden belasting, latentie en beschikbare capaciteit zich door de tijd? Later kwamen Grafana en Checkmk erbij. Het doel bleef hetzelfde: verslechtering eerder herkennen en met gegevens begrijpen waar het systeem naartoe ging.

Het principe dat bleef. Monitoring is meer dan een verzameling dashboards. Het moet het team de kans geven om te handelen voordat iemand anders moet vertellen dat er een probleem is.

Historische bron: de aankondiging van het eerste openbare Let’s Encrypt-certificaat (2015).

  • Nagios
  • Zabbix
  • Grafana
  • Checkmk
OVERIGE RESULTATEN
01 / PRESTATIES · 2008

Statische levering van de webservers halen

Akamai CDN ingevoerd om ongeveer 90% van onze objecten dicht bij gebruikers te cachen en zo de bare-metal-originservers te ontlasten.

~90% objecten dicht bij gebruikers gecachet
Lees het projectverhaal

Het vertrekpunt

In 2008 draaide het platform op fysieke webservers achter één load balancer. Er was geen cachelaag: verzoeken om statische inhoud gingen rechtstreeks naar het webserverpark. Als weerdienstverlener hadden we te maken met extreme schommelingen in de vraag. Afhankelijk van het weer en andere grote gebeurtenissen leverden afzonderlijke dagen ongeveer 20 keer het gebruikelijke verkeer op, vergelijkbaar met de piek van een winkelier op Black Friday. We hadden een systeem nodig dat met die pieken kon meegroeien.

Het knelpunt

Bij hoge requestfrequenties werd de beschikbare socketcapaciteit een knelpunt. De website kon onbereikbaar raken, terwijl een groot deel van de vraag inhoud betrof die niet telkens opnieuw door de origin hoefde te worden geleverd.

De verandering

Met Akamai kon ongeveer 90% van onze objecten dicht bij gebruikers worden gecachet. Slechts zo’n 10% van de aanvragen bereikte nog de origin: ongeveer 90% minder aanvragen op de origin. Die verlichting maakte het mogelijk het webserverpark te verkleinen.

Meer operationele speelruimte

We kregen ook een extra mogelijkheid om drukke dagen op te vangen: langere cachetermijnen voor geschikte inhoud konden de origin verder ontlasten. Daarvoor moesten we per soort inhoud bepalen waar langer cachen acceptabel was, in plaats van overal dezelfde instelling toe te passen.

De les: lever herbruikbare inhoud dichter bij gebruikers en behandel cachebeleid als een middel voor beheer, niet alleen als een prestatie-instelling. Historische projectsamenvatting; infrastructuuridentificatoren en interne operationele details zijn bewust weggelaten.

02 / MODERNISERING

Van fysieke servers naar VMware

Een opslagproject dat niet aan de oorspronkelijke latentie-eisen kon voldoen, werd een succesvol virtualisatieplatform en een keerpunt in mijn denken over infrastructuur.

> €10,000 maandelijkse besparing op rackkosten
Lees het projectverhaal

Een project waar ik bijzonder trots op ben

Als systeembeheerder kon ik configuraties en architectuur veranderen, maar niet elke hardwarebeperking wegpatchen. We hadden een opslagsysteem gekocht als cachelaag tussen de webservers en de productiesystemen.

De proof of concept vertelde niet het hele verhaal

Het systeem slaagde voor onze proof of concept. Onder echte operationele belasting was de latentie echter te hoog voor de beoogde rol. Een project met een investering van enkele honderdduizenden euro’s stond op het spel. Moesten we de mislukking accepteren en de investering afschrijven?

Een ander doel voor dezelfde investering

We sloegen een andere richting in. In plaats van de opslag op te geven, gebruikten we die als basis om onze fysieke servers met VMware te virtualiseren. Het oorspronkelijke plan voor een cachelaag werkte niet, maar de hardware had nog waarde in een andere architectuur.

Een tegenslag werd een meetbaar succes

Het resultaat was een geslaagd virtualisatieproject. Door fysieke servers te consolideren bespaarden we ook meer dan €10.000 per maand aan rackkosten. Een investering die dreigde te mislukken was veranderd in een platform met duidelijk operationeel en financieel voordeel.

Waarom dit me richting AWS bracht

Hoewel het resultaat een succes was, bleef ik verlangen naar meer: infrastructuur die ik dynamisch kon aanmaken en wijzigen, net als software. Dat verlangen bleef. Het verklaart mede waarom ik uiteindelijk mijn hart aan AWS verloor.

03 / CREATIEF PROGRAMMEREN

Browserarcade

Hoeveel Duitse mark heb ik als kind aan deze spellen uitgegeven? Geen idee. Vandaag kan ik met Codex mijn eigen browserversies bouwen.

2 speelbare browsergames
Lees het verhaal

Een klein experiment

Ik wilde weten of Codex de sfeer van een spel in de browser kon nabouwen op basis van een paar screenshots en wat informatie. Die nieuwsgierigheid werd Browser Arcade: mijn eigen versies van Snake en Galaga.

Van zakgeld uitgeven naar zelf dingen maken

Ik weet niet hoeveel Duitse marken er als kind in deze spellen verdwenen. Toen betaalde ik om te spelen. Nu kan ik zelf helpen een versie tot leven te brengen, en dat laat me nog steeds glimlachen.

Het plezier zit in het proberen

Het resultaat is twee speelbare browserspellen, gemaakt voor het plezier van experimenteren. Een jeugdherinnering werd iets dat ik kon bouwen, aanpassen en delen.

Snake ↗ · Galaga ↗