UPDATE: Please see comments below about SPLA and Fail-over Licensing.
SQL Server 2014 comes with some new benefits and improvements that are really nice, and I’d be lying if I said that I’m not excited about a number of them. But, to borrow a term from Microsoft, SQL Server 2014’s story for developers is not just weak, it’s also bordering on hostile. I could have titled this article "SQL Server 2014 Improvements for Developers," and then said, “There are none,” and saved myself the trouble of writing a commentary for this week. But, I’d argue that there are also some subtle and scummy, licensing changes that effectively make SQL Server 2014 hostile to startups and Small-to-Medium Businesses (SMBs).
A Severe Shortage of Developer Improvements
For all intents and purposes, SQL Server 2014 didn’t ship with any new improvements or benefits for developers. Yes, SQL Server 2014 has Hekaton, which lets you move tables and certain code in memory to pick up exponential performance benefits. Although that’s a big win, it’s more of a benefit to ops teams or DBAs who are trying to squeeze additional performance out of hardware that’s running into concurrency and architectural bottlenecks. Hekaton isn’t really a developer-related feature. Nor, frankly, are column-store indexes, which are now updateable.
Instead, there’s only a minor new T-SQL improvement that I’ll argue is more DBA-related and not much else that would apply solely to developers. In my book, developer-related features and improvements would help with new functions, coding capabilities, and improvements to the rat’s nest that’s managing SSRS, SSAS, and SSIS projects within Visual Studio. Developer-related features could also help create a new paradigm associated with querying data that would be on par with the introduction of the SQLCLR. Frankly, a perfect example of what would show developers that the SQL Server team still acknowledges developers’ existence would be native support for JSON—ideally with better performance than Microsoft’s native support for XML, the lingua franca of data transport from an entire decade or two ago. I’m not alone in feeling like this, either—Connect item asking for this functionality is now bordering 700 up-votes.
Subtle Scummy Licensing Changes to SQL Server 2014
A bigger issue, however, is the change in SQL Server 2014 licensing. Prior to SQL Server 2014, I liked to say that SQL Server came with a ‘buy one, get one free’ type of license. Whenever you purchased a production license for SQL Server, you’d also get an equal or lesser license to deploy on a standby server that could be used to only handle loads in the case of a disaster. In essence, the spirit of this licensing benefit was the assumption that if you were spending $100,000 for a license of SQL Server Enterprise Edition on a big server you wanted that license to be running at any given time. As such, a license of SQL Server allowed a primary server to operate with a licensed workload and also extended that license on to a secondary server, where you could run production workloads for up to 28 days only in the case of an emergency failure, if your primary server crashed, blew a back-plane, was done for maintenance, or somehow became unavailable.
For over a decade now, this licensing benefit has made SQL Server High Availability solutions possible because it means that when setting up SQL Server clusters, database mirroring, log shipping, and more, organizations only have to license the primary servers where they’ll be actively handling production workloads. An organization that wanted to build a simple two-node SQL Server cluster would only pay, say, $120,000,enough to license a single, beefy server, instead of paying $240,000, the amount it would take to license the hardware on both servers in the cluster.
The problem, however, is that with SQL Server 2014, this licensing benefit now applies to only those customers who purchase Software Assurance. Without software assurance, you get no failover or secondary license. Technically, customers without Software Assurance aren’t prohibited from setting up High Availability solutions, they just have to pay double.
I can see why Microsoft made this change—they’re trying to drive continuous revenue, instead of making one-off sales. There are also substantial benefits for customers who purchase Software Assurance. My problem with this change, however, is that Microsoft made the change to help bolster its bottom line without thinking of how the change impacts customers. My expectation is that many organizations won’t be impacted too much by the licensing change. However, SMBs who don’t purchase licenses of SQL Server and who instead lease them from hosting companies will be negatively impacted by the change.
Every month, these businesses pay to license their SQL Server workloads based on a pro-rated cost of what it would take to purchase SQL Server over the space of about two to three years. There are pros and cons to this approach, and leasing is not for everyone; it comes with some financial penalties in the long term. It does, however, let organizations amortize the cost of SQL Server over time, and also enables them to upgrade whenever they feel like they need to, as they’re paying for the latest version of SQL Server. The problem, however, is that leases on SQL Server licenses are covered by Service Provider Licensing Agreements, and therefore can not be covered by Software Assurance. As such, my clients who lease SQL Server have some tough choices ahead; purchase SQL Server 2014 outright as part of their upgrade plan, lease 2x licenses instead of 1x going forward with their hosting providers, or simply don’t upgrade to SQL Server 2014.
Azure is Not the Answer
What’s clear to me is that this recent change to SQL Server Licensing helps bolster Microsoft’s bottom line, while completely putting the squeeze on Microsoft’s hosting partners, because the value they used to provide in terms of leases is now gone—customers can either pay double or stop leasing. What I don’t know is whether this side benefit of putting the squeeze on hosting partners was deliberate or was just collateral damage in Microsoft’s bid to get regular, more predictable revenue out of customers. I can’t help but think that all of the changes end up coming across as scummy. Moreover, it’s hard for the skeptic in me to ignore that these changes might be part of a Microsoft power play to push SMBs and startups away from traditional hosting companies and closer to Azure.
In my experience, though, Azure simply can’t deliver the kind of throughput and raw performance that $10,000 worth of hardware and a $7,000 license of Standard Edition can deliver over the space of a few years. Azure simply can’t pack the same wallop that dedicated hardware can, and Azure pricing definitely favors Microsoft instead of customers. Couple this with the fact that Microsoft isn’t showing developers any love, and it’s fair to say that there are some serious and disturbing problems with SQL Server 2014.
