Understanding SQL Licensing in 2020 | Black Diamond Consulting

Understanding SQL Licensing in 2020

SQL, SQL, SQL *robotic voice*

When most people write about SQL they initially think in regards to the complex world of querying. Today, I'm here to shed light on another important aspect that is often overlooked, SQL licensing.  ​According to Templeton Interactive, licensing wasn’t an issue for many early applications, because the software was shipped in a hard to copy format, such as proprietary game cassettes or on audio tapes, which were difficult to duplicate in the days before mass market cassette recorders. But this all changed with the advent of floppy disks in the 80s - now ISVs (Independent Software Vendors) had to come up with new strategies to protect their business interests; from activation codes to USB dongles to  nothing was secure enough to protect the individual licenses because they could not be tracked. 
As computers became more and more networked, ISVs developed license delivery systems that were installed on servers, rather than having individual licenses tied to a specific machine - this is the method that most enterprises and SMB clients utilize today.

2 Types of SQL Licenses: Core vs CAL Basics
 
*The (2) ways to license SQL are by Core (Std & Ent) & CAL (Std ONLY since SQL 2012 was released)
 
*MSFT will still honor CAL Ent 2012 – if client is paying for Extended Support (ESUs) but will be limited to 20 core for newer SQL deployments
 
*Both licenses can be used on prem or in the cloud as IAAS but CANNOT be used in the PAAS cloud scenarios (see MSFT Hybrid Benefit attachment)
 
​*Server CAL model was designed for departments ex. Accounting but doesn’t support expansions – CALs are harder to track since they are tied to a person instead of a device.
 
*If Hyperthreading will be used this will affect the licensing of the underlying core license count
 
* Systems that utilize CALs & Core models can sometime run into Multiplexing scenarios so if you are dealing with hospitals, schools, etc your client should be aware of the solutions to remedy this potential licensing issue.
 
*Perpetual License – Buy License, then pay Software Assurance annually
*Subscription License – Pay annual fee to RENT license, ~150% cost of SA
*Break Even Point – 4.5 years for Enterprise Core, so if client plans to deploy a workload for less than 4.5 years it would actually make more economical sense to RENT via subscription license
*Licenses will be based on the “high watermark” usage
 
Microsoft Agreement Types
 
Enterprise Agreement (EA): 3 year term, must have Software Assurance (SA) for term of agreement, True Ups (TUPs) account for any additional SQL license deployments that have taken place during the life of the agreement for new hires, new projects, splitting workloads, etc, TUPs take place 30 days prior to agreement anniversary date
 
Microsoft Products and Services Agreement (MPSA): is a transactional licensing agreement for commercial, government, and academic organizations with 250 or more users/devices. MPSA works best for organizations that want to license Microsoft on-premises software, cloud services, or both as needed--with no organization-wide commitment under a single, non-expiring agreement. Software Assurance is optional.
 
Server Cloud Enrollment (SCE): similar to EA, 3 year term, perpetual license that requires SA for term of agreement, also required to carry SA on ENTIRE SQL estate even on old servers in exchange the client gets discounted % on those older servers and future discounts on new licenses, another major benefit of the SCE is it allows the client to mix perpetual and subscription based license. Example: Client plans to deploy new workload for a time based project of 1 year. The client doesn’t need to BUY a perpetual license, which would include SA costs, since the deployment is temporary. Under SCE, they have to option to RENT the license, Subscription, and only pay for the time they used the license. The cost to rent this license is ~150% of yearly SA cost but once again you are only paying for the time you use versus SA which you have to carry for the entire term.
 
Hybrid Flex SCE: 3 year term, takes perpetual licenses and converts them into subscription licenses at SA Only pricing, Example. Client buys 100 perpetual licenses w/SA for on-prem in Jan 2020 equal to $1M, a year later the same client now only needs to deploy 80 perpetual licenses w/SA on prem, since the client is still locked into the 3 year agreement they are still required to pay the $1M in SA costs BUT since they have decreased their on prem deployments to 80 perpetual licenses they are actually paying $800K for on prem license and the other $200K is now avail as AZURE MONETARY COMMITMENT which can be used to leverage ANY Azure Cloud Services. The idea of this program is to give clients the flexibility to move their spend from tradition SQL to Azure w/o penalty or SA that you may not need for the full term.
 
Microsoft Software Assurance Values
 
*Next Version (historical value)
*Mobility Rights (rel. SQL 2012) – allow for VMS to be reassigned more than once in a 30 day period, especially beneficial for virtualization since the VMs are constantly moving from one physical server to another. Essential for Failovers
*Failover/Disaster Recovery (rel. SQL 2014) – new SA allows for Active Node supported by (3) additional nodes for D.R. sites, which can now be “warm”. In addition MSFT will provide an IAAS VM for 2nd “warm” site (cannot be used for production workloads)

I hope this helped clarify some of the complexities in regards to some of the aforementioned Microsoft licensing  agreements. If you have any questions or insights please leave a comment!

#BeGreat #FocusOnTheMission

-TC

Share this post