Slashdot Mirror
Microsoft Windows Server 2016 Moving To Per-Core Licensing (arstechnica.com)
rbrandis writes: Windows Server 2012 has two main editions, Standard and Datacenter. They had identical features, and differed only in terms of the number of virtual operating system instances they supported. The licenses for both editions were sold in two-socket units; one license was needed for each pair of sockets a system contained.
Windows Server 2016 reinstates the functional differences between Standard and Datacenter editions. Datacenter will include additional storage replication capabilities, a new network stack with richer virtualization options, and shielded virtual machines that protect the content of a virtual machine from the administrator of the host operating system. These features won't be found in the Standard edition.
Windows Server 2016 licensing moves to a per core model. Instead of 2012's two socket license pack, 2016 will use a 2-core pack, with the license cost of each 2016 pack being 1/8th the price of the corresponding 2 socket pack for 2012. Each system running Windows Server 2016 must have a minimum of 8 cores (4 packs) per processor, and a minimum of 16 cores (8 packs) per system.
Windows Server 2016 reinstates the functional differences between Standard and Datacenter editions. Datacenter will include additional storage replication capabilities, a new network stack with richer virtualization options, and shielded virtual machines that protect the content of a virtual machine from the administrator of the host operating system. These features won't be found in the Standard edition.
Windows Server 2016 licensing moves to a per core model. Instead of 2012's two socket license pack, 2016 will use a 2-core pack, with the license cost of each 2016 pack being 1/8th the price of the corresponding 2 socket pack for 2012. Each system running Windows Server 2016 must have a minimum of 8 cores (4 packs) per processor, and a minimum of 16 cores (8 packs) per system.
Microsoft was knee-high to a grasshopper and might not have even yet been in the business of selling word processors to Mac users and a cheapo 'disk operating system' for 8086s back wehn IBM was already making licensing complicated.
They've certainly grown up since then, though.
I have no doubt that they'll make this change confusing, just because they always do, but the move from per-socket to per-core seems like it should come as basically no surprise from MS, or anyone else selling software whose scale is limited primarily by the power of the underlying system, rather than 'per user' or 'per seat': The number of cores, and amount of supported RAM, per socket has just skyrocketed lately, even for comparatively modest sums of money, while the sheer board complexity and need for fancy high-speed interconnect has kept socket counts relatively flat(the plummeting costs of computer equipment in general means that team supercomputer-with-custom-interconnect-fabric is still buying more sockets than ever; but among cost-sensitive customers I wouldn't be at all surprised if 8-socket systems are getting hammered, and 4 sockets dead in the water or even declining, as the number of cores you can cram into 1 or 2 socket systems increases).
On the minus side, this can't be good news for AMD: their per-core performance is lagging; but they have some parts that are kept somewhere in the running because they offer a lot of (fairly slow) cores, and support a lot of RAM, for a relatively low price(it's not terribly glamorous; but there are applications where you have a zillion lightweight http server tasks, or need a big huge memcached server for cheap and single threaded performance matters less than price). If MS is licensing per-core, without any modifiers for the power of the cores, that is going to put a great deal of emphasis on high per-core performance in any environment that tithes to Redmond. In their ideal world, they'd obviously just have a more competitive design; but AMD can't be happy that MS isn't 'weighting' cores for licensing purposes.
As someone who is peripherally involved with MS data centers I can tell you that the whole Azure/cloud thing is booming like mad. It's insane.
They literally cannot build data centers fast enough so what they're doing is buying and/or leasing buildings, gutting them, rebuilding them and hardening them to keep up with demand. And they're still not keeping up, there's a huge pent up backlog of demand and capacity that is growing like crazy. They literally can't keep up with the need for secured server space that meets their requirements.
Just cruising through this digital world at 33 1/3 rpm...
Well, nobody is going to invite you to a holiday resort and play golf with you if you use Linux servers. Though I'm not sure whether Red Hat has caught on by now.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Licensing per core is stupid, and frankly it should be illegal.
Why illegal? There is already licensing per user. So why not per core? Why not per watt?
There is an alternative - use a competitor that uses a more palatable licensing scheme.
I think "making things easier" is being mixed up with "easier to find MS experience than Linux experience."
The problem I encounter, having sat in both worlds, is that each side thinks their stuff is the right hammer, and everything is a nail. The MS guys want to use their wrench as a screwdriver, while the Linux guys want to carve notches in bolts so they can use their screwdriver in place of a wrench.
A couple use cases: Spawning Hadoop instances on OpenStack [1] or AWS is a lot easier with Linux than Windows. It can be done with Windows, but it is a lot easier to find howto guides and such under Linux. Another case is popping up nginx web servers on compute nodes for static content behind a load balancer. That is pretty easy with ansible [2], lsync, and varnish. In Windows, it can be done, but it would require some fancy footwork with SCCM/SCOM/WIM.
On the opposite side, for a massive directory service (something spanning multiple geographical regions, with many employees and company division/org charts that look like spaghetti), AD has a lot more support than the various LDAP platforms [3], and has proven to be good enough, security-wise.
Best thing to do is use both. Windows winds up at the core, Linux/BSD/etc. are at the edge.
[1]: Windows and OpenStack are like oil and water. I've not heard of any OpenStack deployments based on Hyper-V, especially on Kilo and Liberty. I wouldn't be surprised to see it (as Microsoft has embraced Docker in a useful fashion), but not at this stage.
[2]: Ansible is easy to include in the VM image, so it either can have an image pushed to it, or it can hit a Git server, grab its playbooks, then run those.
[3]: I've used other directory services. I would say that AD is a lot less painful than AFS or DFS/DCE. Things can change on a dime, and an AD competitor that can scale and replicate can come out of nowhere, similar to how Ansible/Puppet/Chef/Salt wasn't on anyone's radar a few years ago, but now is a staple of IT/DevOps as of now.