Wat Cloudflare het MKB leert over dure datastromen

Stel: je webshop registreert tien miljoen gebeurtenissen per dag, van bekeken producten tot mislukte zoekopdrachten. Bewaar je van elke gebeurtenis één kilobyte, dan produceer je al 10 gigabyte per dag. Mijn stelling: de goedkoopste infrastructuurverbetering is vaak niet een snellere server, maar besluiten welke gegevens die server nooit hoeft te verwerken.

Dat klinkt minder opwindend dan nieuwe hardware. Toch is het precies de vraag die een groeiend MKB-bedrijf te laat stelt. Een extra kopie, een langere bewaartermijn of een gedetailleerder log lijkt afzonderlijk klein. Samen worden ze een terugkerende rekening.

De les uit een veel grotere datastroom

Cloudflare beschrijft in Rewinding the exponential: How we keep hardware usage down de uitdaging om hardwaregebruik binnen de perken te houden terwijl zijn netwerk groeit. Volgens de introductie van het artikel zit meer dan 20% van het web achter dat netwerk en verwerkt het datateam gegevens uit een wereldwijd verspreid systeem. De schaal is uitzonderlijk. De onderliggende bedrijfsvraag is dat niet: hoeveel van wat binnenkomt, moet je daadwerkelijk verplaatsen, bewaren en doorzoekbaar maken?

Ik zou de werkwijze van zo'n netwerk niet één op één op een webshop of installatiebedrijf plakken. Daarvoor verschillen de techniek, contracten en risico's te veel. De nuttige les is kleiner: datavolume is een keuze, niet alleen een gevolg van groei.

Een ondernemer ziet meestal de factuur voor opslag of rekenkracht. Minder zichtbaar zijn de uren om trage rapportages te onderzoeken, extra kopieën te beheren en uit te zoeken welke data nog nodig is. Juist die verborgen arbeid maakt de reflex ‘we schalen wel op’ duur.

Reken eerst de onschuldige kilobyte door

Terug naar de voorbeeldwebshop. Tien miljoen gebeurtenissen van één kilobyte zijn ongeveer 10 gigabyte per dag, 300 gigabyte per maand en 3,65 terabyte per jaar aan ruwe gegevens. Drie volledige kopieën brengen alleen die ruwe omvang al naar bijna 11 terabyte. Indexen, metadata en tijdelijke verwerkingsbestanden zitten daar nog niet bij.

Dit zijn rekenaannames, geen gemeten cijfers van een bedrijf en geen prijsopgave van een leverancier. De uitkomst verandert als gebeurtenissen kleiner zijn, data wordt gecomprimeerd of het verkeer sterk schommelt. Maar de vermenigvuldiging maakt één ding zichtbaar: een keuze van één kilobyte aan de ingang werkt het hele jaar door.

Nu de interessantere vraag. Welke beslissing neem je dankzij die mislukte zoekopdracht van elf maanden geleden? Als niemand een concreet gebruik kan noemen, is een jaar lang bewaren geen strategie. Het is een standaardinstelling die ongemerkt budget krijgt.

Andersom: de ruwe orderregel die je nodig hebt voor een correctie, geschil of wettelijke bewaarplicht gooi je niet weg omdat opslag geld kost. Het onderscheid zit niet tussen ‘veel data’ en ‘weinig data’. Het zit tussen gegevens met een aantoonbare functie en gegevens die alleen blijven liggen.

Drie vragen vóór de volgende uitbreiding

Begin niet bij een nieuw contract of een grotere machine. Pak één datastroom die de afgelopen drie maanden zichtbaar is gegroeid, bijvoorbeeld websitegebeurtenissen, sensormetingen of uitvoerige foutlogs. Laat de eigenaar van het proces deze vragen beantwoorden:

• Welke beslissing ondersteunt dit gegeven? Een storingsmelding waarmee een monteur wordt gestuurd heeft een andere waarde dan elke seconde een onveranderde temperatuur opnieuw opslaan.

• Hoe lang is het volle detail nodig? Voor een wekelijkse trend kan een dagtotaal voldoende zijn, terwijl onderzoek naar een recente storing minuten of seconden vraagt.

• Wat kost verlies van detail? Controleer operationele, contractuele en wettelijke eisen voordat je gaat samenvatten of verwijderen.

Neem een installatiebedrijf met duizend apparaten die elke minuut een status sturen. Dat zijn 1,44 miljoen berichten per dag, zelfs als er niets misgaat. Voor de planning van preventief onderhoud kan een uurwaarde bruikbaar zijn; voor de analyse van een storing wil je rond het incident juist de oorspronkelijke metingen zien. Je hoeft niet te kiezen tussen alles eeuwig bewaren en niets bewaren. Je kunt de bewaartermijn en het detailniveau per doel vastleggen.

Dat vergt wel discipline. Een samenvatting die alle pieken gladstrijkt, kan een probleem verbergen. Bewaar daarom uitzonderingen en de periode rond een incident apart wanneer dat voor je bedrijfsvoering nodig is. Minder data is alleen winst als de benodigde informatie overeind blijft.

Een kostenbesparing is pas echt als het proces haar verdraagt

De valkuil van dit onderwerp is dat je opslagruimte als enige maatstaf neemt. Stel dat het filteren van gebeurtenissen een ontwikkelaar twintig uur kost en maandelijks twee uur onderhoud vraagt. Bij een intern rekenbedrag van €75 per uur is dat €1.500 aan inrichting plus €150 per maand aan onderhoud. Bespaar je slechts €40 per maand, dan is het geen goed project.

Die bedragen zijn een voorbeeldberekening, geen marktprijs. Ze laten zien waarom ‘minder hardware’ niet automatisch ‘meer rendement’ betekent. Tel ook het risico op gemiste signalen, herstelwerk en extra complexiteit mee. Een eenvoudig systeem met wat overcapaciteit kan voor een klein bedrijf de betere keuze zijn.

Anders ligt het bij een datastroom die elke maand verdubbelt, rapportages vertraagt of voortdurend handmatig beheer vraagt. Dan koop je met een extra server vooral tijd tot het volgende probleem. De structurele vraag is welke gegevens je aan de bron kunt beperken en welke pas later, wanneer ze nodig blijken, uitgebreid worden verwerkt.

Ik zou daarom per stroom vier cijfers naast elkaar zetten: dagelijkse instroom, bewaartermijn, aantal kopieën en aantal keren dat iemand de gegevens daadwerkelijk opvraagt. Je hebt daarvoor geen perfect kostenmodel nodig. Als een groot deel van je data nooit wordt geraadpleegd en geen aantoonbare verplichting dient, heb je een concreet onderzoekspunt. Nog geen toestemming om het te wissen, wel een reden om de standaard te herzien.

Wat je deze maand kunt besluiten

Kies één snelgroeiende datastroom en geef haar een eigenaar. Spreek af welke ruwe gegevens noodzakelijk zijn, welke samenvattingen volstaan en op welke datum je de bewaartermijn opnieuw toetst. Test de wijziging eerst op een beperkte periode, zodat je kunt controleren of rapportages, foutonderzoek en verplichtingen intact blijven.

Meet daarna niet alleen de lagere opslag, maar ook de tijd die het team aan verwerking en zoeken kwijt is. Als die tijd stijgt, heb je mogelijk kosten verplaatst in plaats van bespaard. Als beide dalen en de benodigde informatie beschikbaar blijft, heb je iets beters gedaan dan hardware kopen: je hebt de groei van de rekening losgekoppeld van de groei van het bedrijf.

Dat is voor het MKB de bruikbare gedachte achter het verhaal van Cloudflare. Niet dat een kleine onderneming een wereldwijd netwerk moet nabouwen. Wel dat elke nieuwe datastroom een zakelijke rechtvaardiging verdient, voordat zij jarenlang capaciteit opeist.