Microsoft Licensering – SQL

Door: Marc Stuifzand

Met elke nieuwe uitgave van een product, oplossing of iets anders nieuws wat Microsoft aankondigt, wordt beweerd dat het licentiemodel wat daarmee gepaard gaat makkelijker gemaakt zal worden. ‘Verrassend’ genoeg is dat tot op heden nog niet gebeurd. Iedere keer wanneer iets nieuws is geïntroduceerd, lijken de regels daaromheen alleen maar ingewikkelder te zijn geworden. Helaas kan ik niet stellen dat dat in het voordeel van de klant is. Dit betekent niet dat sommige stappen die Microsoft neemt niet begrijpelijk zijn, maar het betekent ook niet dat we met alle stappen die genomen worden blij zouden moeten zijn. In dit artikel zal ik ingaan op SQL en een aantal licentiegerelateerde zaken die een enorme impact op klanten hebben gehad – en in de toekomst ook zullen blijven hebben.

Hoe was het in het begin:
Eigenlijk begon het vrij simpel… er was een server en daaraan waren een aantal apparaten gekoppeld. In de tijd dat dit speelde waren er slechts twee dingen die geteld moesten worden: servers en gekoppelde apparaten. Al snel werd het een stuk complexer: door de introductie van de term ‘Multiplexing’ werden een groot aantal klanten flink in de war bracht. Klanten dachten dat ze met een tussenliggende applicatie, gebonden aan een server, slechts één Client Access License (CAL) nodig hadden. Dit is niet waar en dit is ook nooit waar geweest. Toch hebben veel klanten hun licenties aangeschaft op basis van deze aanname, waardoor ze onmiddellijk incompliant werden. Wanneer klanten met deze incompliancy werden geconfronteerd, moesten ze in alle gevallen flink betalen.

Vandaag de dag denken veel klanten nog steeds dat bovenstaande aanname klopt. Ze denken hun licenties aan te schaffen tegen een lage prijs, maar in werkelijkheid staat ze een vervelende verrassing te wachten. Dit voorbeeld is gelukkig nog wel gemakkelijk uit te leggen. Maar, na het model ‘per apparaat’, kwam natuurlijk ook het model ‘per gebruiker’.

Hierna kwam, wellicht als reactie op multiplexing, iets genaamd ‘SQL per processor’. Wat betekent dit? Je telt niet meer het aantal CALs, maar het aantal fysieke processoren in de servers. Dus, eerst tel je de servers, daarna alle fysieke processoren en dat is waar je als klant voor betaalt. Dit model kwam natuurlijk naast het huidige server CAL model te bestaan. Dit komt omdat niet alle klanten in een model passen. In principe was dit vrij simpel en ook eerlijk. In dit model was SQL (en Microsoft) een geduchte tegenstander van Oracle. Prijs-kwaliteit werd daarom zeer goed waargenomen door Microsoft haar klanten.

Hierna gebeurden drie dingen die impact hadden op de SQL server installaties en licensering:

1. Virtualisatie
2. Core licensing
3. De komst van de Cloud (bijvoorbeeld Azure)

Deze ontwikkelingen hebben een gigantische impact op de licentiestructuren. De wijzigingen van de licenties zijn beschreven in whitepapers van maar liefst 40 pagina’s. Een voorbeeld: een klant heeft nu 10 SQL server Enterprise per processor gelicenseerd. Dit model bestaat niet meer. Wat zou in dit geval het huidige juiste licentiemodel zijn? Wat zou de beste optie voor de klant zijn op korte, maar ook op lange termijn? Hoe bereken je dit? Welke vragen moeten er gesteld worden? Heb je ergens bewijs van nodig in bepaalde situaties? Wat als je, in de laatste maand voor het einde van de overeenkomst, bent begonnen met virtualisatie? Moet je Software Assurance (SA) activeren? En wanneer moet je dat normaal gesproken doen voor SQL?

Laten we dit verder proberen toe te lichten:

10 fysieke processoren – Enterprise – op dit moment
• Hoeveel fysieke cores heb je op dit moment?
• Hoeveel virtuele cores heb je op dit moment?
• Load balancing?
• Actief, passief?
• Cold back up?
• Heb je Enterprise nodig?
• …

Nadat je hebt vastgesteld hoeveel licenties je nodig hebt, is het tijd bang te worden van de prijzen ervan. We hebben een case om handen gehad waarin de klant, alleen al door het veranderen van het licentiemodel, € 850K per jaar in plaats van € 200K per jaar moest betalen… de installed base bleef in dit geval exact hetzelfde. Dat maakt deze case nog interessanter, want de enorm hoge extra kosten voor de klant zijn puur en alleen ontstaan doordat Microsoft de licentiestructuur veranderde… Helaas kan dit niet in alle gevallen worden voorkomen…

Wat zou je moeten doen als SQL klant:

• Kijk erg goed naar je huidige installed base (MAP Tool)
• Let op de licentie implicaties
• Houd je toekomstperspectief voor ogen
• Let op de licentie implicaties
• Geef de installed omgeving wellicht nog een review
• …




« Terug naar het overzicht