Azure SQL-database. Lekker simpel en snel?
1. Database Het begint al bij de keuze. Ga je voor een Azure SQL-database, een Managed Instance of SQL Server op Azure…
De trui die ik liet opknappen
Een tijdje terug had ik een oude trui. Dikke, warme wollen trui, jaren trouw gedragen. Ik woonde erin. Op een gegeven moment raakte het bovenstuk gerafeld en dacht ik: ik laat hem opknappen. Nieuwe boorden, nieuwe kraag, opgeknapt geheel. Klaar voor weer tien jaar.
Drie weken later begaven de mouwen het, toen de elleboog, toen de zoom. Ik had de buitenkant vernieuwd, maar het weefsel zelf was gewoon op.
Dit is precies wat ik organisaties zie doen met hun databases bij een cloud-migratie. Ze trekken hun bestaande SQL Server een nieuwe jas aan (Azure VM, schitterende cloud, gloednieuwe netwerkinfrastructuur) en gaan ervan uit dat de database vanzelf meeschaalt naar dat moderne jasje. Drie maanden later komt de factuur. Dan blijkt het weefsel het probleem te zijn, niet de jas.
Wat we steeds zien gebeuren
Klant migreert SQL Server naar Azure. Lift-and-shift, netjes uitgevoerd. Eerste weken is iedereen blij, maar dan komt de maandafsluiting en blijkt dat de database toch niet goed performt. Er wordt capaciteit bijgeschakeld. Hup, de VM snel twee maatjes groter. Alles draait weer, queries lopen, applicatie reageert. Niemand klaagt meer, vergeten en weer door. De kracht van de cloud is maximaal benut.
Dan komt maand drie, en met maand drie komt de eerste serieuze factuur. Een stuk hoger dan de businesscase beloofde. Paniek. De reflex: “Azure is duur.” Of: “Laten we naar AWS kijken.”
In negen van de tien gevallen ligt het probleem niet bij Azure. Het ligt bij de database zelf.
Wat er onder de motorkap gebeurt
On-premise hardware is meedogenloos vergevingsgezind. In je eigen datacenter merkt niemand het als je wat CPU-power hebt toegevoegd aan een VM. Die draait wat harder, de disken lezen wat meer, klaar. De stroomrekening verandert niet, de hardware is afgeschreven, CPU-capaciteit is ‘gratis’ CPU-capaciteit.
In de cloud betaal je extra voor elke CPU, ook de CPU die je niet gebruikt. Een query die on-premise gewoon “een beetje traag” was, wordt in Azure opeens een doorlopende geldkraan.
De drie patronen die we het vaakst tegenkomen
- Indexen die nooit zijn bijgewerkt sinds schepen nog van hout waren en mannen van staal. De applicatie is gegroeid, de queries zijn veranderd, maar de indexstrategie staat al jaren stil. On-premise is dat irritant maar onzichtbaar. In Azure betaal je elke maand cash voor structurele CPU-verspilling.
- Tempdb-misbruik. Slechte query-patronen (ongeschikte joins, ontbrekende WHERE-clauses, monsterachtige SELECT * over tabellen van miljoenen rijen) duwen tempdb tot het breekpunt. On-premise los je dat op met meer disk. In Azure betekent het een duurdere storage-tier, hogere IOPS-vereisten en uiteindelijk een grotere VM die het allemaal moet wegslepen. Laat staan als iemand vergeet de tempdb-databases op een non-volatile D:\SQLTemp\ disk te plaatsen.
- Retention zonder grens. De tabel met logging-data die sinds 2014 nooit is opgeschoond. De auditlog die maandelijks 20 GB groeit zonder dat iemand er ooit naar kijkt. On-premise gooi je er een disk bij. In Azure betaal je doorlopende storagekosten, langzamere back-ups, langere restoretijden en extra compute bij elke query door die tabellen.
Waarom dit nu pas pijn doet
Hier zit het wrange. Deze patronen zijn niet nieuw. Ze zaten er al jaren in. On-premise werden ze opgevangen door de hardware; dure, ruim gesizede servers die de inefficiëntie absorbeerden.
De cloud rekent. Elk inefficiënt patroon krijgt een prijskaartje, en dat prijskaartje verschijnt elke maand opnieuw op de factuur. Wat in je eigen datacenter een verborgen schuld was, wordt in Azure een zichtbare rekening.
Zo bekeken is een cloud-migratie een gratis audit van je database-hygiëne. Met die kleine bijkomstigheid dat de audit niet via een rapport komt, maar via een factuur.
Ga niet eerst migreren en daarna optimaliseren
Dat is de truc met de wollen trui: je betaalt voor het opknappen én voor de mislukking. Doe het andersom. Of in elk geval parallel.
Voordat een database naar Azure verhuist, wil ik weten hoe het staat met indexering en statistieken. Welke queries zijn de top-10 resource-verbruikers, en laten die zich herschrijven? Hoe groot is de vergeten data, tabellen die niemand bevraagt maar die wel doorgroeien? Wat is het werkelijke werkpatroon: pieken, dalen, idle-momenten? Welke onderdelen zijn pure legacy en zouden verbouwd moeten worden naar een ander patroon?
Sexy werk is het niet. Geen migratie-feestje, geen lintje doorknippen. Wel het verschil tussen 20% besparen op je Azure-factuur en 50% méér betalen dan je ooit had verwacht.
We doen het via onze QuickScan of HealthCheck, afhankelijk van hoe diep je wilt graven. Enkele dagen tot een aantal weken werk waarin we de zwakke plekken in kaart brengen vóórdat ze in Azure een prijskaartje krijgen. Wat eruit komt is geen dik rapport voor in de lade, maar een concrete lijst met acties: deze indexen erbij, deze queries herschrijven, deze data weg, dit patroon aanpassen. Dat kun je ons laten doen, of we begeleiden je team erin.
Als de migratie al gedraaid heeft en je toch zit met onverwachte Azure-kosten, komt ons zusterbedrijf OptimaSure in beeld. Zij zijn gespecialiseerd in Azure FinOps en kunnen de cloudfactuur terugbrengen. Het mooiste is natuurlijk dat je hen niet nodig hebt omdat je het vooraf goed hebt aangepakt.
De cloud belooft veel, maar levert pas als het weefsel deugt
Een database met legacy-patronen wordt in Azure niet beter. Die wordt vooral duurder. Het goede nieuws: dat is op te lossen. Het slechte nieuws: niet door de jas te vervangen.
We kijken graag mee voordat je de oversteek waagt. Stuur een mailtje, bel even, kom langs aan de IJsselmeerweg. We bijten niet en we praten liever in het Nederlands dan in jargon.
