Slashdot Mirror
Oracle Effectively Doubles Licence Fees To Run Its Stuff in AWS (theregister.co.uk)
Oracle has changed the way it charges users to run its software in Amazon Web Services, effectively doubling the cost along the way. From a report: Big Red's previous licensing regime recognised that AWS's virtual CPUs were a single thread of a core that runs two threads. Each virtual CPU therefore counted as half a core. That's changed: Oracle's new cloud licensing policy says an AWS vCPU is now treated as a full core if hyperthreading is not enabled. A user hiring two AWS vCPUS therefore needs to pay full freight for both, effectively doubling the number of Oracle licences required to run Big Red inside AWS. And therefore doubling the cost as well. The new policy also says: "When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable." That table says Xeons cores count as half a licence. Making the Table inapplicable to the cloud again doubles the licence count required.
Not really. Those that know it can make it jump up, sing, dance, and pretty much do anything a a thousand times faster than the pretend databases.
It seems like this move could mean one of two things: either Team Oracle thinks that there is sufficient willingness to pay among users of their products, and they were previously leaving money on the table in AWS instances; or they fully expect this to seriously dent use of their products in AWS; but don't care because they have their own 'cloud' offerings and want everyone not running on premises to be buying cloud from them.
Any guesses as to which it is? Is this a "Larry's a jerkass; but he knows that most of us will suck it up and pay the extra" situation; or is this a straightforward move to make one of the more popular cloud options blatantly uneconomic for use with Oracle stuff, in order to improve the apparent value of Oracle's pet cloud?
DBA here. I work with SQL Server, Oracle, and MySQL. Each has it's pros and cons. One thing that Oracle offers which the other vendors can't really match at this point is Oracle RAC. It's the only out-of-the-box N+1 shared-disk solution that somewhat works properly. SQL Server has tried to offer something comparable with AlwaysOn, and MySQL has MySQL Clusters*, but these really don't fit into the same roles.
I haven't worked enough with DB2, and nothing large scale with PostGres to comment on those. I do feel that RAC is less of a necessity nowadays anyway, and will continue to be so, since the hardware has improved so much that the SQL Server/MySQL solutions can handle pretty much anything. I also don't think RAC is a good fit for a cloud-based solution.
*owned by none-other than Oracle nowadays
If you post as Anonymous Coward, don't expect a reply.
Interesting that the summary uses the words from the article on this from The Register but without their link to the old PDF, and your quote includes [PDF] but then challenges their summary.
the actual old licensing regime counted each AWS vCPU as a full CPU core even though it was actually hyperthread
Sadly the PDF linked by El Reg doesn't provide clarity on this. It talks only about virtual cores and doesn't mention hyperthreading at all. Of course LMS would use that lack of clarity to apply your interpretation (assuming they couldn't invent something even nastier with which to fuck over their 'customer').
My only conclusion is to continue to avoid Oracle wherever possible.