The point of containers is they aren't VMs, yet Microsoft licenses SQL Server in containers as if they were VMs Microsoft has slipped out licensing details for SQL Server running in containers and it will likely encourage developers to be pretty diligent in their use of Redmond’s database. Spotted by the license-scrutineers at Licensing School in Microsoft’s May 1 Product Terms update [.DOCX], licensing works as follows: For purposes …
The reason that Docker Desktop on Windows creates a Hyper-V container is that it needs a Linux operating system to allow you to run Linux containers. Because containers aren't VMs, they rely on a host operating system to provide the low level services that they need to function (CPU, memory, I/O, ...). One way to think of it is that you're doing cross-platform development. If you wanted to do Android development you would need to run an Android emulator on your machine to run your applications without deploying them to a phone - this is pretty similar.
This isn't representative of using containers in production. This is just a development setup that you can use while working with containers locally.
Apart from the licensing craziness in TFA, this is the other reason I don't get why anyone would run SQL Server containers in Windows. My understanding is that the container runs SQL Server for Linux, which is a Windows app running on shims to translate Linux API calls (pretty much the inverse of WSL v1), then that in turn gets executed within a Linux kernel running in a VM on Windows, which in most cases is probably also virtualised on another hypervisor layer in the datacenter. That goes against the entire premise of running containers for efficiency.
Really, why would anyone think this would be done any other way. You are installing an instance of SQL Server, so you license it on how many cores it has, like a VM.
If you are running in the 'cloud' and using BYOL, then you will be paying for each instance you deploy, as you have no control over the hardware and the number of cores it has (you are sharing it with others).
If you are running on your own hardware, want unlimited instances of SQL Server, buy licenses for all the cores on your hardware you intend to run them on, run as many instances are you want in containers or VMs. Moving SQL Server to a container isn't changing what it is.
If they wanted to move their licensing model to a more container / micro-service approach, they could add a per DB license model, or Data Volume model.
And if they're genuinely lightweight, with this model you would, core-for-core, expect to get more performance per currency unit out of a container-based instance than the same number of cores in a VM.
Of course, if you're not irrevocably tied to SQL Server, you could use PostgreSQL instead and not have to worry about the licensing costs.
Really, why would anyone think this would be done any other way. You are installing an instance of SQL Server, so you license it on how many cores it has, like a VM.
If they're doing it like Oracle does, they charge by the number of cores on the *HOST* system, not the VM. So if you want to balance your VMs around to multiple hosts (maybe just two Oracle or SQL VMs per host) you have to pay for ALL the cores, even if you only assign 2 cores to that VM. This is where the problem comes in.
Microsoft licencing currently isn't like that. If you have a VM, you can license the VM itself or the host if you want to run multiple. You need to calculate the break even point for that. But if you are doing it per host and using VMs you then need to licence all the hosts. Per VM is the VM, move it if you like, but to move it more than every 90 days you need to have software assurance. You can licence just a single host, but you would need to move all the VMs at the same time to the new host, again, needing SA or limiting it to every 90 days.
You also have the server licence instead of core licence model, but you require CALs and that is limited to standard only, so you are limited to 64GB RAM i think it is now. It also means it is really only useful for internal services where you can assign users or devices. Internet facing things using the DB need to be per core.
It's a nightmare isn't it? It took quite a lot of consultations with Microsoft's licensing monkeys to confirm and validate a solution.
In the end we have a license of Windows server datacentre edition with licenses for the number of cores on the VM host servers. This gives us an unlimited number of guest instances of windows server DC edition.
MS licencing is just a simple maths problem. depending number of cores in the hosts and how many VMs you run on them dictates wheter you go DC licencing on the hosts, doing so does simplyfy things some what, there are also restrictions relating to EA/SA agreements.
Std and DC versions are near identicle in feature set, there is just teh licence difference and some extra stuff for Hyper-v in DC. for most VMs I would run Std.
For SQL you can limit VMs to certain hosts and only licence those, again very simple, also developer edition is free so if you put all your non=prod systems on that version you run them anywhere.
Also there are free editions of SQL that may be more apropriate for containers.
Oracle you have to licence ever core that exist anywhere in your estate that a vm could potentially move to. (this is for Oracle databases and Java installs on servers if you use Oracle runtimes like SAP does)
MS Licensing is currently being designed to ensure that any Azure options are starting to look more cost effective. This is all about revenue generation and lockin. The more people that decide to buy into Azure because it makes on-prem licensing cheaper the better (for Microsoft). This will then evolve to the point that people just put stuff straight into Azure and pay.
The end result is the people running the software pay progressively more and become totally dependent on Azure.
Microsoft's goal is to have everything in Azure, you have no need for any data centres of your own because (according to the marketing BS salespeople) Azure is cheaper and better than anything you can do on-prem. This is touted at board level and is bought into by management. Statements such as "server teams are just highly paid janitors that add no value to your business" go down well with the board of directors. The numbers thrown around are complete works of fiction but make great headlines. This is all good until, after a number of years the finance teams want to know why you are spending millions for these services. At that point there is realistically no way out. Some will move back to running their, others will simply continue to pay because they no longer have the capability to do anything else.
Don't need DC for enterprise CA. It used to be that you needed enterprise edition, but that requirement was removed in 2012 i believe when they switch to standard and dc editions, with the main difference being vitualisation rights. This has changed a little in later versions with dc having other features added that standard doesn't.
"so you license it on how many cores it has, like a VM."
Why? I can understand licencing per instance, but licensing per core? All that does is make things run faster and more efficiently. Next thing we know, they'll be increasing licensing based on the speed of each core. The entire concept of charging ever greater licensing fees based on the number of cores is just wrong. Why should my software cost more run per user when I spend more on faster and better hardware? Or be artificially limited to 2 cores on my 64 core beats?
Per core makes much more sense than per instance.
It's about paying for for the software to get through a certain workload in a certain time.
In your model of per-instance pricing, if I only had machines with limited amounts of cores and needed say 4 instances to get through that workload in a certain time, I would be paying 4 times as much than if I had bigger machine with more cores to throw at it. To run the same workload in the same time, with roughly equal amounts of hardware (except some motherboards etc).
You pay more if you use more cores because the software you license gets to do more.
That is how they see it now due to the number of core you can get in a single system. Like you said, now you could have a single system that a few years back required 4, as you can now get 128 cores in a dual socket system.
This may go even further, like you also said its about performance. IBM currently do it for their websphere licencing model. They have a unit cost for different types of processor cores based upon their performance. So you pay for the number of transactions per second a core can do. So have lots of slow cores, or a few very fast ones, same price as they can do the same number of transactions (doesn't work out that way as the per core performances are not very big, so price doesn't change a lot).
Yeah, so basically it's gouging. Pretty much every other item of software you buy, you pay per instance or user at most. I can run a big spreadsheet, video renderer or ray tracer on cheap. low core count hardware and wait ages or I can throw bigger faster hardware with more cores at it. Why should I pay more for the software? They buyers of these databases should have been telling the sellers to piss off when they came up with this cash extraction model.
Like I said, and based on your rate of throughput argument, why are the DB sellers only counting cores? Surely they should be looking at total throughput and increasing the rental rates if you have brand new faster hardware than Joe blogs down the road running on last years hardware but with the same core count.
Oracle did it already years ago. IIRC right before speeds where increasing again quickly between Pentium II and Pentium III. or the latter and Pentium 4, don't remember exactly now, should check. If you needed to change the hardware, and were no longer able to source the slower processors, you had to pay for the new CPU speeds...
I have never before come across a set of circumstances to which the reply 'I don't fucking care, and why should I have to waste a microsecond of my very finite life in considering the implications of this?' seem more appropriate.
There are teams of lawyers worldwide, who are presumably intelligent and reasonably creative people, making more money than I could ever dream of by devoting their lives to this dreck, and we wonder why things that need to be done like sorting out climate change, overpopulation, social housing and the depletion of natual resources (to name but four) seem to be overlooked.
Bring on the heat death of the universe. It's long overdue.
A grumpy old man.
While containers aren't a joke they are definitely overrated and often incorrectly used. The main reason behind them is being able to deploy specific services quickly, and in exactly the same way on multiple machines. Of course, this is almost identical to deploying VMs but the start up time and resources required for a container is less.
If only those BSD and Solaris Beards had wrapped their bash script in a yaml based api that developers could have understood easier than bash script they to could have been going bankrupt like docker.com when the big tech boys stole their product and sold it as a “cloud” product..
Surely people like this? You chose a non-opensource solution, you obviously *want* to pay out of the backside.
There are many alternatives, if you need that support (often used as an argument) then why not pay. And pay extra because you are asking for support in a number of different chrooted environments.
Microsoft are only in the wong by profiteering from people making bad choices.
"Microsoft are only in the wrong by profiteering from people making bad choices."
Microsofts take on containers almost completely misses the point of using containers as a lightweight, self-contained environment on top of a minimal OS as an alternative to a VM environment by making you run that said lightweight environment on top of all the crap you would normally deploy anyway.
That customers then compound the idiotic product offering by being so sure that they need Docker without spotting the architectural flaws that the are willing to pay over and over again.
Two wrongs may not make a right, but they certainly provide a lucrative sales opportunity.
You'd think the programming "geniuses" at Microsoft should be able to figure out a containerization function for MSWindows too, right? Split out userspace functions into their own little boxes; after all MSWindows has such a rock-solid kernel, and distinct separation of kernel-space and user-space...
Wait... what? Oh, nevermind.
"Microsofts take on containers almost completely misses the point of using containers as a lightweight, self-contained environment on top of a minimal OS"
I don't know. Get rid of the VM or container and imagine you are running two instances of their product on the machine at the same time. I suppose each one *should* be licensed and support paid.
If that is still hard to justify, imagine you are running version 2018 of their product on the same machine as version 2020 of their product. Because they are subtly different, they do require extra support. Your containerised instances are also subtly different versions of the product (i.e because they are in different environments)
Of course I recommend choosing open-source in future.
That has nothing to do with licensing a database server. For the matter, many database servers where "containers" because you did run the database and nothing else from that machine if you wanted to achieve decent performance, since but for trivial applications usually the database used all the available RAM, CPU and I/O. Some databases even bypassed the OS file system and take direct control of the disks. Really, the OS was just there to start the database server software. Later the hardware became big enough to allow to run full instances into VMs or containers.
So if you deploy a physical system, a VM, or container for the same workload why should it be priced differently? The fact one or the other could be easier to manage is not a concern of the software maker.
Maybe not a good way to create microservices - but if each microservice needs a separate database instance, IMHO you will have bigger problems in the future than the database licensing.
You’re not buying it... It’s closer to the car PCP model. You rent it. You stop paying rent it goes back to the dealer/MS. You drive the car lots? You pay more to the dealer. You use SQLS lots? You pay more to MS.
I’m not a fan of MS’s licensing model to be fair for various reasons (complexity being high up on the list) but what you describe already exists, and for a physical object, not just software.
That's basically how insurance works.
This article is retarded, SQL instances basically hog cores due to the nature of their workload, the more physical hardware you use the more you pay for it's that simple.
The smarter choice is to avoid it altogether and use elastic instances but the idiot that write this wants to do the typical reg thing and bash Microsoft again.
I don't really see an issue with this. Why would you not be charged for every instance you deploy?
Really?
You bought a DBMS Why should it matter how many cores you run it on, or how many different databases you manage with it -- how would you like it if MS licensed Word on a per-document basis, or charged more for copies of Word that could handle more than a set number of pages in a document, or more than a certain number of documents open at a time?
Licensing per-core or per-instance is just gouging.
Because it impacts directly how many licenses you need. In the past the hardware put an upper limit. You could not scale a database server enough to sustain more than x applications on each, you needed separate physical systems, and a license for each. Then hardware began to grow much more than software needs, so you could scale the hardware only and put more workloads on each. To protect revenues companies needed to find a new license mode. Like it or not, companies exist to make money, and some of those money are also paid to employees and suppliers.
Think if a single computer in the office would let several employee work at once with the same license of Word - it's clear the license model will be changed.
Do you remember how mainframe time was licensed and paid?
So your contention here seems to be that a SME with a need for SQL Server to support a line of business application for 50 users on 4 cores in a VM or container should pay the same as a large multinational who want to support 5,000 users on bare metal and 128 cores.
I don't agree with that opinion at all.
If you don't want to pay the licenses, buy or build a solution that doesn't require them. Otherwise - it's a business, pay for the software.
I'm struggling with the use case as to why someone would want to fire up a very light weight VM (which is what containers are meant to be) and have an instance of MS-SQL server running in it. MS-SQL is anything but light weight. I can understand lots of containers with MS-SQL clients running in them, but to fire up MS-SQL servers on demand? It feels like either a bit of an edge case or a rather "interesting" design choice.
please keep in mind we're talking developers here. They are pretty clueless when it comes to networking, security or infrastructure. They can't be bothered with these mundane details, all they care for is where to paste the code they've copied from the Internet and other cool stuff.
I can think of a few, but they probably don't fit into the licensing issues that this article is about:
- I want to make it easier for other devs to get a development environment up and running quickly, but want to avoid having to go through the full SQL Server installation process, or want the ability to switch versions quickly.
- I want an easy way to spin up a database for running automated end to end tests as part of CI/CD pipelines, and I want to be able to just bin it easily once I'm done.
In both those examples I maybe don't care if the performance of the SQL server instance isn't as good as a bare metal install, and I potentially don't care if any of the data is persisted or not. What I care about is that I can get something up and running quickly.
Not saying you don't have valid points, I'm just saying that production isn't the only use-case for running database servers, and there are situations where you want something transient that you can start and stop rapidly.
The use cases you describe (dev environments, rapid testing against multiple versions) is absolutely where containerisation makes sense. In that case though you'd be using Microsoft SQL Server Developer edition though which is free - feature equivalent to SQL Enterprise you just can't use it for Production workloads... in other words ideal for this use case :)
Fair enough. First off, I'd just use MySQL or the like anyway, screw SQL Server.
But, for the practical purposes of "lets run a bunch of seperate junk on one system" use of running containers or VMs, they are functionally the same for that purpose other than the containers having less overhead. I bet if I wanted to run 5 copies of SQL Server on one machine I'd be expected to pay for 5 copies of SQL Server... so, this way, I'm paying for 5 but at least only have to pay for the subset of CPUs (or threads or whatever) actually assigned to that container. The containerized SQL Server (I assume) will have less overhead and so run a bit better than the SQL Server in a VM under yet another copy of Windows (you're saving on paying for a VM copy of Windows at least!)
edit: Nope, you can pay for all cores on a system and run as many SQL Servers as you want. But still, this provides the offer of giving it like 1 core to save money on some monster 128-core or whatever box.
There three types of licencing,
Microsoft, you have to licence all physiccal cores the software can run on, this can be restriced in software, you just need to prove it.
Oracle, you have to license every physical core that you have in your entire estate that the software is able to to run on or move to even if you would never move it there and we don't care about simplifying your platform management, just pay us all your money just in case you move it to that country over there, oh and did you know it can run on on your edge switches since Cisco added that feature so that is another £1m please..
Open Source, you dont have to licence it, but if if it breaks you will want support and you may have to pay based on every physical core evrywhere in your estate, just in case.
> Open Source, you dont have to licence it, but if if it breaks you will want support and you may have to pay based on every physical core evrywhere in your estate, just in case.
Or you simply pay for support for the dev environment, reproduce the issue, apply the fix, test, then apply the same fix to production. A lot of folks run a mix of RHEL and CentOS following this same model. Much more cost effective than paying for absolutely everything, and avoids the continual wasted time of accounting for it all.
When Microsoft behave like this they bring it on themselves.
Despite what they'd have people believe, it's not like any of their products are the only choice. There are other vendors, and OSS can provide a viable alternative where you don't have to pump untold millions into the licences alone. For the sort of money some of these licences could cost, with the utterly ridiculous per machine plus per user plus per core plus per thread plus per GHz plus per transaction per second licensing models, you could have your own custom software written to do the job which would be both cheaper and far more suited to your each businesses specific use cases.
Licensing is one of the constraints that goes into a systems operational architecture. I have seen developers include relational databases in containerised solutions but to me this should be tiering issue, any persistent data that requires ACID compliance should be in a self contained tier and if cost is your objective that makes more sense to be on a physical cluster or a dBaaS. Non-persistent data and application configuration is better off on an OSS data store and probably non-relational so stick it in the container. the nightmare is when you have to containerise an older application, because you don't have time to fix it properly, and then scale horizontally but consider MS licensing as being a fine on bad behavior then.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
