Announced earlier this month and talked about for at least a year (I think they mentioned this at the 2007 Dev Summit), ESRI is moving away from socket licensing to using the number of cores on the server.
Through November 30, 2007, ESRI licensed server software based primarily on the number of physical sockets on the server which are being utilized by CPU chips. These CPU chips can have 1 or more processing “cores,” each core providing additional computing power for the CPU chip. Licensing requirements and fees for ESRI server software are based on the combination of the number of utilized sockets on the server and the number of cores on each CPU chip. To address recent changes in the server hardware markets, ESRI has adjusted the licensing and pricing model for ESRI server software to be based only on the number of cores on the server. This adjustment simplifies the process of determining the appropriate license requirements and license fees, especially for new hardware configurations that are continuously being introduced.
Now before you get all worked up that this will cost you more money…. DON’T. Your maintenance will not change because ESRI is adjusting the pricing model as well. It will mean you’ll have a much easier time determining your license and fees using the new chart provided by ESRI.
14 Comments
Why do I feel compelled to start complaining about how that the pricing model doesn’t including virtualized servers?
Ok, I don’t really feel that way. But it’s a good question. Even if they don’t officially support it, it’s still something people will try.
Hmmm, I typed in a comment but I think it’s been lost.
The gist was: how is pricing by core going to work in a virtualization environment? (ESX Server running on a blade server, etc.) You could have a whole OS that is running on less than a core, and then could jump up to using tons of resources when a big job comes through.
It’s hard to price server software.
@ Matt M.
You never actually run on a fraction of a processor and depending on allocation of processors by ESX you will never consume more than that. Yes, memory and network resources can be over allocated and increased in times of contention but processor is not.
If you allocate four processors to a server than that is the most it will ever use.
Actually you do run on a fraction of a processor, if you do your math over time. Simplistic case- six separate server processes, each in its own OS, on an quad core single processor machine. Each one gets 4/6 core time in a strict balanced operations mode. Seems strange to charge for four cores for each server process, since processor time is shared.
Should you pay for the most something could ever use, even when that use is divided into time slices? I wouldn’t.
Matt
Yeah–with server software, it’d be nice if some kind of floating license scheme could be achieved. Or maybe some kind of metric-based approach, like with fractional leased-lines and certain colo services.
Unfortunately, I for one would not like to have such monitoring on my server to accurately measure that kind of utilization. I suspect many other people would feel the same way or are under legal requirements that would forbid it.
Maybe this won’t affect users now, but as it becomes harder and harder to buy a server (even just to do a hardware refresh) with less than four cores it will. And as the scaling-out trend continues this will only get worse. Eventually we’ll be in a situation where we can’t buy new servers with less than (8, 16, 32, 64…) core CPUs.
Usage-based licensing (where the user is charged for actual use rather than potential use) makes a lot more sense, and scales regardless of hardware changes.
Of course, what makes the most sense of all is to use software that does not require licensing fees
The lack of pricing for virtual servers seems to be an omission. VMware ESX allows each virtual machine to be restricted to using 1, 2 or 4 cores. Whether the virtual machine gets full access to those cores depends on how many physical cores the server has and how many virtual machines it is supporting.
What I’d like to see from ESRI is a definitive statement on what licensing would be required to run ArcGIS Server in a VMware instance limited to a number of virtual cores that is less than the number of physical cores in the server.
Example: ArcGIS Server in a VMware virtual machine restricted to 4 cores (equivalent to the current licensing of two sockets of two cores each) on a physical server with a total of 8 cores.
Quad core processors are no longer rare in servers, and it would seem fair to licence the software on the number of cores it can actually use.
@Jason Birch: I’d assume ESRI would just make changes to the licensing agreement. The big issue addressed here is cores vs sockets. I think everyone has pretty much moved away from sockets for licensing so this is really not that big of news.
I’ve had multiple folks tell me that ESRI is looking at addressing the Virtual Server issue in regards to licensing. I’d assume it would be figured out by the Dev Summit (but that is my guess).
Have to second J. Birch – why have such fees in the first place, aside from just fleecing more $$ from users.
I mean, to a degree I don’t necessarily “mind” maintenance fees as long as I get something for it and they arn’t too stiff. But to purchase a piece of software, and then be told that the cost of that software depends on what kind of hardware I run it on is pain. That’s like trying to charge for how potentially useful a product might be to your organization. If you really need it, then we’ll charge you through the nose!
Microsoft has chosen to stay with processor licensing for its SQL Server product, and I know of at least one other example.
For my department, the question of cores was a critical point in whether we stayed with Oracle for a key information system upgrade or moved to SQL Server. With SQL Server, we could expect almost double the processing power (could have been more if we’d gone with 8-core processors) for a lower price. Hard to argue against those numbers.
I guess I don’t have any right to complain though. ESRI is a privately held company and is free to make its own business decisions. As are its customers.
In this case though it doesn’t affect licensing at all. What you paid before this “conversion” is what you pay after. They didn’t exchange socket for core 1 for 1.
Yeah, I wasn’t trying to say that this specific change will affect users, just that the practice of charging per core (which I guess they were already effectively doing… although it was oddly coupled to sockets) will.
I have a brilliant idea for ESRI. How about you charge us for the sockets/cores that your server software can actually take advantage of! That would be revolutionary and honest! Instead of sitting there trying to keep up with the Joneses on sockets/cores/ etc….write your software so that it will effectively take advantage of what you are wanting to charge us for.
Nothing makes me more angry than getting charged for software that is stupid and only uses one core/CPU/thread.
If you look at the various white paper discussions and testing of ESRi’s server products, it scales VERY poorly on more sockets and cores. As someone else mentioned with SQL server if you add another core you can see double the performance….not so with ESRI.
It means, to implement ArcGIS Server in a server with two processors could need just one license?… if it´s so, could be $35,000 less