Het probleem met omgevingen die altijd aan staan
Veel acceptatieomgevingen draaien alsof ze productie zijn: 24 uur per dag, 7 dagen per week. Dat voelt veilig, want de omgeving is altijd beschikbaar. Maar in de praktijk wordt een OTA-cluster vooral gebruikt tijdens kantooruren, demo-momenten, tests en deploys.
Buiten die momenten staat er vaak compute te wachten op werk dat niet komt. Voor een volwassen enterpriseomgeving lijkt dat misschien een bijzaak. Voor een startup is dat precies het soort structurele verspilling dat je vroeg wilt oplossen, voordat de omgeving groter wordt en de rekening ongemerkt meegroeit.
Waarom EKS Auto Mode hier interessant werd
EKS Auto Mode maakt de compute-laag anders dan klassieke managed node groups. AWS beheert meer van de node-operatie en gebruikt dezelfde denkwijze die je van Karpenter kent: NodePools en NodeClasses bepalen welke compute beschikbaar mag komen wanneer workloads daarom vragen.
Autoscaling helpt alleen niet als je alle workloads gewoon actief laat. Dan schaal je efficienter, maar je blijft nog steeds betalen voor een omgeving die buiten werktijd niet nodig is. De stap bij Bettr was daarom: niet alleen slimmer laten schalen, maar de hele OTA-laag een dag- en nachtritme geven.
De goedkoopste node is nog steeds de node die je niet hoeft te draaien.
De volgorde is belangrijk
Je kunt niet zomaar nodepools uitzetten en hopen dat de rest netjes volgt. De volgorde bepaalt of dit betrouwbaar voelt of als een harde power-off. Bij Bettr loopt de shutdown daarom bewust van applicatie naar database naar compute.
Eerst gaan de applicaties uit. Daarna worden de CNPG-clusters via ArgoCD naar de gewenste uit-stand gebracht. Pas als de workloads geen compute meer nodig hebben, worden de nodepools in het cluster uitgeschakeld. Omdat die nodepools ook in ArgoCD staan, blijft de hele operatie declaratief en herhaalbaar.
- Applicaties eerst uit, zodat er geen nieuwe workloadvraag ontstaat
- CNPG daarna gecontroleerd naar de gewenste toestand via GitOps
- Nodepools als laatste uit, waardoor de compute praktisch naar nul kan
Zichtbaar in het OPS-kanaal
Elke scheduled actie meldt zichzelf terug. Daardoor zie je niet alleen dat de omgeving uit of aan is gezet, maar ook waarom de workflow liep en welke omgevingen geraakt zijn.
Waarom notificaties geen bijzaak zijn
Scheduled automation is alleen volwassen als je kunt zien wat er is gebeurd. Anders wordt het een verborgen proces waar iedereen op vertrouwt totdat er een ochtend iets niet aan staat. Daarom meldt de workflow in het OPS-kanaal wanneer de OTA-omgeving scheduled uit is gezet en wanneer de enable-window de omgeving weer activeert.
Die notificaties zijn klein, maar belangrijk. Ze geven context, zoals de reden van de run, en ze maken fouten direct zichtbaar. Als een actie faalt, komt dat ook in hetzelfde kanaal terecht. Dat houdt de flow operationeel controleerbaar zonder dat iemand elke avond of ochtend handmatig hoeft te controleren.
Developers houden zelf controle over uitzonderingen
Een scheduled shutdown mag geen blokkade worden voor developers. Als iemand een avond langer doorwerkt of nog een test wil afmaken, kan die de OTA-omgeving zelf handmatig enablen via de GitHub Actions workflow. De developer kiest de gewenste actie en welke onderdelen mee moeten. Zo blijft de standaard zuinig, maar blijft de uitzondering self-service, zichtbaar en controleerbaar.
Wat die 50 procent precies betekent
Voor het OTA-cluster halveert deze aanpak de computekosten met ongeveer 50 procent. Dat is logisch: avonden, nachten en weekenden zijn een groot deel van de week. Als de compute in die vensters niet hoeft te draaien, verdwijnt een groot stuk van de structurele kosten.
Dat betekent niet dat de volledige AWS-rekening halveert. Een EKS-control plane, storage, backups, load balancers, networking en andere vaste componenten kunnen blijven doorlopen. De claim gaat bewust over compute. Juist daarom is het belangrijk om dit scherp te formuleren: het is geen magische kostenknop, maar wel een heel concrete reductie op het deel dat vaak het snelst groeit.
FinOps wordt pas volwassen wanneer kostenbesparing onderdeel wordt van de normale platformflow.
Waarom dit naast reservations waarde houdt
Op dit moment is de euro-impact nog niet extreem groot, omdat Bettr ook via reservations kosten verlaagt. Dat maakt de besparing niet minder relevant. Het betekent vooral dat er al meerdere lagen van kostencontrole naast elkaar bestaan.
Reservations drukken de prijs van compute die je gebruikt. Scheduled shutdown voorkomt dat je compute gebruikt wanneer die niets toevoegt. Dat zijn twee verschillende mechanismen. In een startupomgeving, waar clusters, workloads en extra omgevingen snel kunnen groeien, wordt vooral die tweede categorie steeds waardevoller.
De les voor platform FinOps
FinOps blijft vaak hangen in rapportages: waar gaat geld heen, welke service is duur, welke trend loopt op. Dat is nuttig, maar het lost nog niets op. De volwassen stap is dat je kostenkeuzes omzet in platformgedrag.
Bij Bettr betekent dat: de OTA-laag heeft een ritme, ArgoCD bewaakt de gewenste toestand, EKS Auto Mode levert compute wanneer er vraag is en de workflow meldt zichtbaar wat er gebeurt. Daarmee wordt kostenbesparing geen losse maandelijkse actie, maar onderdeel van hoe het platform dagelijks werkt.
Wat het oplevert
Deze aanpak maakt de OTA-omgeving goedkoper zonder haar onvoorspelbaar te maken. Teams kunnen overdag gewoon werken, terwijl de omgeving buiten werktijd gecontroleerd terugschakelt. En als developers een keer langer doorwerken, kunnen ze de omgeving zelf tijdelijk weer aanzetten. Dat is precies waar platform engineering en FinOps elkaar raken: niet alleen inzicht in kosten, maar technische defaults die verspilling automatisch kleiner maken.