Production HANA on VMware – for the few, for now

Production HANA on VMware is in “controlled availability, allowing selected customers, depending on their scenarios and system sizes to go live with SAP HANA on VMware vSphere immediately” per SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.  However, the SAP marketing team left this small stipulation off the press release and got everyone very hot and bothered.

It sounds like everyone should be able to put their HANA system on VMware.  First, my wife, who is not in the IT world, sent me a link to the NY Times SAP and VMware Head for the Future Together and then I got about dozen copies of the Market Watch Report: SAP and VMware Announce SAP HANA® for Production Use on VMware vSphere 5.5.  Well, at least that mentioned you needed the latest version of VMware.

So for now, if you want to production HANA on VMware, the main requirements are below and included in SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.

  • Must be approved for controlled availability by SAP
  • Must be on VMware vSphere 5.5
  • Must be on SAP HANA SPS07
  • Maximum of 1 TB
  • Must be on SAP approved HANA server and storage
  • Must comply to SAP’s current recommendations for vCPU and RAM
  • Must not over-provsion the CPU nor RAM
  • Maximum of 1 Virtual Machine (VM)

In other words you need the latest and greatest version of VMware and HANA running on your HANA approved appliance in a nearly non-virtual manner.  While this is less than what we all want, it is a step in the right direction.  It will allow you to manage the HANA instance under your VMware management utilities.  It makes HANA part of your Software Defined Environmental strategy.  I’m confident that over time, as it becomes Generally Available, that production HANA will have far fewer restrictions.

I’m actually looking forward to when we can run production HANA on lots of virtualization schemes.  I look forward to more of software defined service level agreement (SLA) with SAP so that other virtualization environments including the cloud providers can provide production services. Right now it is about shipping hardware to Waldorf, DE for certification and is so specific, it is not practical even for hardware manufactures.

SAP needs to move to software defined SLA would be good for everyone including SAP by making HANA more available and take less effort to certify platforms, hardware and cloud providers who want the ability to vary the make-up of servers based on market conditions and newer evolutions of chipsets, and especially my clients who want HANA, but in but running in a completely virtual word they are defining, not the one SAP is trying to define for them.

As Vishal Sikka (former SAP CTO) exits, limited Production HANA on VMware is great first step for the product he called his child, HANA. Unlimited production HANA on VMware would be a great toddler-hood.  I really look forward to seeing it rapidly reach its teenage years and start trying to run on everything everywhere.  Isn’t that what teenagers do?

 

Please STOP using meaningless terms for cloud like Private, Public, and Hybrid

There are 2 dimensions that have meaning when discussing cloud solutions and the terms public, private, and hybrid contains too many overlaps and ambiguity.  Is a cloud private if it is hosted?  Is a cloud public because I access it over the internet and does that mean my corporate data center accessed via VPN is public?  Worse, the term Hybrid Cloud gets bounced around so many different ways that is no longer relevant at all.   I could have SAP ERP and SuccessFactors  or SAP ERP production in a corporate data center and the non-production SAP ERP systems on a IaaS cloud provider such as IBM’s SmartCloud IaaS  or it could mean I do some ERP functions on SAP ERP on premise and some using SAP Business-by-Design (BbyD) or on NetSuite ERP.   In the end, it only means  is I’m using more than one type of solution.

There are meaningful dimensions to describing cloud solutions.  The two (2) dimensions that matter are: 1) location, and 2) separation.

First is location.  Where is the solution residing?  Is it on my premise, site or facility that I own or at least consider part of my corporate network of locations.  Alternatively, is it away from the bulk of my IT assets such  that I need a WAN to access it.  For clients with highly distributed data centers this becomes a moot point since everything connects over the WAN; however, most clients have consolidated their corporate application and data centers into just a few locations.  IBM runs its corporate business in just a few data centers with SAP in just 2 of them globally.

Second is separation.  What separates the resources.  Are the solution resources separated by physical boundaries such as server, application, or database or is the solution separated by layers of software?

The trend is clearly towards SaaS where location is off premise and all the infrastructure and application components of the solution are software separated.  In a SaaS solution, it is clear you are using the SaaS providers data center of choice and not your own.  You also are accepting that the secured division of servers, network, and storage.  Even more importantly, you are accepting that your data in flight (within the application) and at rest is kept secured and separated from others including your competitor.  I have seen numerous cases where direct competitors use the same SaaS solution.  In fact, most SaaS providers count on competitors using their application to scale since you can’t build a SaaS business on single client.  Clearly, we do believe in software separation has come of age.

Software divided applications and infrastructure is becoming a the rule.  If you want to take the software divided and secured environment on premise, IBM calls it Software Defined Environment (SDE) ().  Another major player, VMware, calls it Software Defined Data Center (SDDC).  Regardless, each is an attempt to virtualize the infrastructure for more effective use of all assets.  This is good for both cost savings and for agility.  Deploying virtual infrastructure is far faster than physical.  Often clients think the value of the business case is in the cost savings, but ultimately it is found in the agility that translate into real application and business value.

So, next time someone comes to you with a hosted semi-private cloud infrastructure offering with hybrid capabilities, just ask them 2 questions.  Where is the solution residing?  What is separating the infrastructure and applications?  Concise answers will reveal a lot about the solution and you’ll have more time to do something beautiful like grow your hybrid tea roses and find PEACE.