All of the opinions expressed here are mine alone and do not necessarily reflect the opinions of my clients.

On a recent project we had to architect a solution for a 1,000,000 user plus Oracle DB based solution. Before I came to the project there was an IBM based proposal on the table for hosting the DB on their Power 6 platform.

I would like to see this more commodity based and deploy to an X86 Hardware platform. I would like to do this to reduce costs, increase scalability option and make the architecture more commodity based (allow for vendor choice at all levels). It would be ideal to standardise on X86 and reduce the amount of IBM and SUN hardware and thus costs. I needed to make a case for this and gain the necessary funding etc.

So far I like my architecture for scaling, resiliency and supportability

But what about cost?…Ok, guess which is cheaper?

Well IBM P series hardware is not cheap. Let’s just say for 2 P6 Server its around $300k as opposed to 5 x X86 servers costing $100k or so. As you can see we can get much more for much less from a scale out point of view, yes we lose clock speed against the P series but have much more processing capacity which we can use for other processes on the same servers and can easily scale out also.

So far so good for my architecture..

The last item on the list is the Oracle DB pricing:

Oracle DB Costs

General Licence list prices ( I have also included per named user and standard DB pricing for comparison purposes) as below:

On IBM P Series, each core is the equivalent of 1 Oracle Processor licence so 8 licences are required per server, which equals 16 licences for the whole environment.

On the target X86 servers each core is 0.5 of an Oracle Processor licence - so that’s 24 per server which of course is a total of 120! Licences for the whole environment.

Cost summary

Hmmm…. from this point of view Big Blue is looking good (wrt Cost)

Partition for heaven’s sake I hear you cry!  Ok then let’s look at that.

IBM have LPARs which Oracle kindly recognise as Physical Partitioning, meaning the size of the defined LPAR is all you need to licence – sweet. So if I decide to add more hardware to the above architecture or if the business wants to reduce capacity I can restrict the Oracle licencing impact by using LPARS.

X86 platform has a few options for partitioning.

VMware. Yes this would be perfect as we already have lots of it and would mean we can scale out later. Alas this is not possible. Oracle does not certify DB running within a VMware environment. Meaning for any production issue that is not already known to oracle we would need to reproduce on a bare metal environment. Also VMWare would be regarded by Oracle as Soft Partitioning and therefore we would need to licence for all cores in the server ! – so no point then

BIOS Disabling of Cores/CPU. Yes another good idea but Oracle would again say Soft Partitioning and we still need to pay the 48 per server licences.

Buy smaller servers (8 core, 16 Core or whatever) – proper partitioning! But this goes against the scale-out aspect that I want to achieve with the new architecture; I would be building something I know I would have to replace soon as the volume grows.

Oracle VM (Xen). Oracle really are pushing this and it is regarded as Hard Partitioning - shocker ;) . The real issue with this is that its new to us and new in general to the Oracle stack for critical Database hosting.  

Ok, Oracle VM looks like the only option here, so lets see what we can do with that.

Using OVM I could reduce the core count to 4 for UAT and 2 for Dev in a bid to control costs (not ideal but we can make it work)

Ok now we are talking, I can scale as we need to and reuse the capacity for other processes in the short term and it’s $300k cheaper than the IBM based architecture.

Outcome

In the end I pushed to get the X86 servers on the condition we can get Oracle VM working. Unfortunately we hit a bug from the start where Oracle VM does not run on the latest X86 servers we wanted to use!! I must point out that Oracle are working very hard to rectify this and have the TOP people working on it but as yet no permanent countermeasure is in place. We have had to go back to using older X86 servers with low core count for launch and will migrate to the larger servers when they work with Oracle VM.

Conclusion

Oracle really makes it hard not to use their platforms. If I had chosen Sun SPARC hardware all would have been good as I could have used Solaris containers and Core Factors can be only .25 on some Sun servers also. I would like to remove Sun servers not add to them though.

I also feel that Oracle really only want to sell large Enterprises an all-in Exadata solution now,  roughly $2.5m+ for this scale and in my opinion comes with vendor lock-in on par with a mainframe and is hardly reducing costs.

Of course IBM will be delighted with this licencing policy as it plays directly to their big iron LPAR based strengths that some enterprises go for.

As will Microsoft who can capture the enterprise commodity market with fair per socket pricing and VMWare support.

NoSQL and Open Source DB vendors must be loving this also, they can really exploit this market with quality products at affordable prices. How will they licence though to make this happen?

Personal Conclusion.

Microsoft SQL Server has never looked so good ;)

References:

Oracle Database is licenced and priced in an open way and a pdf can be found here that outlines this.
Oracle Server Partitioning Licencing Policies are outlined in this pdf
Oracle Processor Core Factor table can be found in this pdf

SpringSource TC server and VMWare Virtual Image Licencing

I recently spoke with the very nice sales teams of both SpringSource and Vmware (same company I know but different divisions). The explained how the TC server is licenced:

One licence per CPU Socket

But….

Only for a maximum of six cores!

So for an 8 core server that’s 2 licences and for a 48 core server that’s 8 licences – simple enough?

Given that most CPUs come in 2, 4, 8, 16, 32, 48 core jumps, 6 is a strange number.

Why not 8 core? I asked – “Good Question. dunno, VMWare decision” says the Spring guy.

Hmmmmm

6 is such an awkward licencing metric. A VMware ESXi virtual image will only take a maximum of 8 cores per image which means you need 2 licences per fully scaled out VMware Image or that you have to put a policy limit of 6 per image. Not liking that.

This completely goes against the point of using this Spring /TC server /VMWare stack which allows you to automatically add cores and start new images in an event based manner. How could this work unless you licences EVERY CORE in EVERY SERVER that you deploy this architecture too.  Otherwise there is no benefit in this approach.  Could you buy small servers to limit exposure?  Yes, of course you can BUT there will be no way to benefit of the Elastic Computing power that the stack promises.

So I guess they choose 6 cores to make sure they had multiple licences per socket and therefore multiple maintenance and support renewals year on year. I would much prefer to have one single more expensive licence per socket (regardless of size) which means I can predict the cost of the architecture to cope with future demands as without this predictability this architecture would be too risky from a cost point of view.

This would mean that every time you replace a server (faulty or whatever) it will probably come with MORE cores than the model you had before and therefore pushing prices up in an uncontrolled manner.

To be clear, I know that VMWare are not the only company struggling with this issue and have gone with what they may consider a safe model  but I have to say from an architecture viewpoint I think  they will see a lot less sales than they would if they licenced in a more predictable and fair manner.

Licencing policies are difficult for software houses to get right. Which unit do they choose to charge per licence?

Which model to use?

•  per socket?
•  per instance?
• per production instance?
• per core?
• per named user?
• per hostname?
• per user?
• per usage metric?
• per site?
• per concurrent user?
• per Enterprise?
• per avergae consumption per month?
• per message?
• per socket up to a limited number of cores?

Tricky stuff!  Which one should they choose? What is the strategy behind the choice that they make?  Money? Fast Adoption? Market Share to make them ripe for buyout?

Getting this decision right will absolutely determine how successful the product is within an Enterprise business environment.

This may sound melodramatic but I have recently seen (at first-hand) some good examples of product licencing policies which have ruled out the product for being considered as standards for Multi-national blue chip companies.

Over the next few blogs I will illustrate these and hopefully make the point. I also hope that people can collaborate and share their knowledge and experience on this issue – so feel free to comment or trackback.

Dreaming of dual core cpu for your next Andriod? - forget that and start dreaming of Quad Core instead! 

Qualcomm, the makers of the already speedy 1Ghz Snapdragon processor have today annouced thier new lineup

http://www.qualcomm.com/news/releases/2011/02/14/qualcomm-announces-next-generation-snapdragon-mobile-chipset-family

The headlines for the short of time:

• New lineup boasts Single, Dual and Quad Core models.
• Speeds of up to 2.5GHz per core
• Will include a new GPU ( Adreno ) with up to four 3D cores

I look forward to a warm pocket when they are released