Waarom uw Azure-kosten ontploffen bij realtime rapportages
“De kosten voor onze datalijn zijn een veelvoud van wat we hadden begroot.”
Dat was de boodschap tijdens een escalatiegesprek bij een productiebedrijf waarvoor wij het dataplatform op Azure beheren. De oorzaak? Het dataplatform was opgezet als een lift-and-shift van de bestaande on-premise architectuur. Dat werkt voor een dagelijkse batch, maar niet voor near-realtime rapportages. On-premise architecturen draaien op lokale opslag waar I/O vrijwel gratis is. In de cloud betaal je voor elke lees- en schrijfoperatie. Bij I/O-intensieve workloads zoals frequente dataverwerking lopen die kosten snel op.
Hoe het mis ging
De architectuur was een klassieke lift-and-shift: de on-premise dataverwerking was vrijwel ongewijzigd naar Azure verplaatst. Data uit Business Central werd via BC2ADLS naar een Fabric Lakehouse geschreven, verwerkt door Synapse pipelines, en gebruikt door een BI-tool voor managementrapportages. Voor een dagelijkse batch werkte dat prima.
Maar toen de business drie operationele rapporten nodig had met data die elke paar minuten ververst moest worden, brak het model. Een architectuur die on-premise geen probleem was (lokale schijf-I/O is praktisch gratis) werd in de cloud een kostenpost. Dezelfde pipeline moest ineens 96x per dag draaien in plaats van 1x. En de hoeveelheid data die over de lijn ging, bleek ook een veelvoud: niet 8 tabellen via een OData feed zoals oorspronkelijk gepland, maar 100+ tabellen via BC2ADLS. Elke run betekende duizenden lees- en schrijfoperaties, en in de cloud betaal je voor elke daarvan.
Waar de kosten vandaan komen
Bij Synapse en Fabric betaal je voor compute-capaciteit en I/O. Een lift-and-shift houdt daar geen rekening mee: on-premise draait I/O op lokale schijven zonder metertje, maar in de cloud tikt elke operatie door. De Fabric-capaciteit die prima voldeed voor een dagelijkse batch was binnen een week opgesoupeerd toen we richting realtime gingen. Opschalen was nodig om überhaupt te kunnen blijven werken.
De kosten zitten in drie lagen:
- I/O-intensiteit: elke pipeline-run leest en schrijft grote hoeveelheden data. Wat on-premise onzichtbaar was, is in de cloud een directe kostenpost. Bij 96 runs per dag in plaats van 1 loopt dat snel op.
- Fabric capaciteit: de capaciteitsunits worden gedeeld over alle workloads. Meer I/O-verwerking = meer capaciteit nodig = hogere SKU.
- Data volume: 100+ tabellen bevatten aanzienlijk meer data dan de oorspronkelijke 8. Meer data = langere verwerkingstijd = meer I/O = meer capaciteitsverbruik.
Wat we gedaan hebben
Eerst: de paniek wegnemen met harde data. We hebben de Synapse-tabellen, Azure cost analysis en pipeline-runs geanalyseerd en een notitie geschreven met twee versies - een technische en een voor management.
Vervolgens hebben we de datastroom ontleed. Van de 100+ tabellen die elke run over de lijn gingen, bleken er maar een stuk of 15 daadwerkelijk nodig voor de operationele rapporten. De rest was analytische data die prima op een dagelijks schema kon blijven draaien. Door die twee stromen te scheiden (frequent voor de kritieke tabellen, dagelijks voor de rest) daalde het I/O-volume per run drastisch. Daarnaast hebben we technische optimalisaties doorgevoerd in de verwerkingslaag, waardoor de doorlooptijd per cyclus halveerde.
De les
Realtime rapportages zijn technisch altijd mogelijk. De vraag is wat het kost en of de business case dat rechtvaardigt. Een lift-and-shift van een on-premise architectuur naar de cloud werkt voor eenvoudige batch-workloads, maar bij I/O-intensieve scenario’s zoals near-realtime verwerking lopen de kosten uit de hand.
Drie dingen die u kunt doen:
- Reken het door voordat u begint. Niet alleen de compute-kosten, maar ook het datavolume dat over de lijn gaat. Vraag uw BI-leverancier welke tabellen ze exact nodig hebben.
- Scheid operationele en analytische datastromen. Eén pipeline voor alles is simpel maar duur. Twee geoptimaliseerde routes zijn goedkoper en betrouwbaarder.
- Monitor vanaf dag één. Wij monitoren nu actief het aantal rijen per tabel en de verwerkingstijden. Bij afwijkingen krijgen we automatisch een alert - voordat de factuur binnenkomt.
De cloud belooft schaalbaarheid. Maar een lift-and-shift zonder herontwerp van uw data-architectuur levert geen schaalbaarheid op, alleen een hogere rekening.