Virtualization - but with what?
Each environment has its own adaptations for high availability (according to SLAs), support and licensing. With Hana, however, there are additional restrictions in addition to the features.
Here, based on the given structures, know-how, and size and complexity of the existing system environment, it is necessary to weigh up which of the platforms is better suited to the processes.
These rigid restrictions (also present in the appliance or bare-metal TDI environment and in the resulting hardware) are completely excessive for most customers and cause resentment.
Few ignore this because of the support issue and are prepared to keep reserves of the necessary magnitude for the support case.
SAP and the hardware manufacturers are working on a solution that will provide the necessary flexibility. Valuable work is being done here by the user groups that are driving this issue at SAP.
Especially the Hana-on-Power community and DSAG are interested in short-term optimizations. But when this will be published is still written in the stars.
Best dynamics through virtualization
However, the necessary dynamics can still best be achieved with virtualization. Many companies even use both virtualization technologies.
In such environments, one sees a mixed operation of power virtualization via LPAR for critical and performance-intensive applications and VMware for less critical and smaller applications such as: ASCS or other application servers (AAS), Java portals, HR systems (Hana sizing <4TB vSphere 6.x or <1TB vSphere 5.5).
Here, memory bandwidth and per-core performance at IBM play an essential role in performance, as do the various RAS features, which already prevent various components from a complete failure in terms of hardware.
Flexibility is provided by resource adjustments as well as the short- or long-term addition of not yet licensed resources via CoD (capacity on demand) (free of charge for test purposes; permanently associated with costs).
VMware also has the advantage of being able to virtualize operating systems such as Windows. However, this is an aspect that only affects Hana marginally (e.g. as an application server or server for other applications that communicate with the HDB, such as Power Designer, Data Services, etc.).
In addition to the release for Hana listed in the table, there are of course also aspects such as VMwareHA and fault tolerance, which are popular for securing availability, especially when using application servers and ASCS, since the user notices virtually nothing in the event of a failure.
Thus, this hypervisor is also very suitable for critical applications as long as the performance is sufficient and the sizing allows it. The possibilities and applications are versatile.
If you value maximum availability, you not only have to keep all components highly available for a possible data center outage, but you also have to think about their maintenance.
This is where features such as system replication (near zero downtime maintenance with DBSL suspend feature) and rolling kernel switch come into play, ensuring uninterrupted maintenance of the operating system, Hana database or SAP kernel. Both hypervisors offer the necessary integration for this.
Those who want to remain homogeneous and already operate their existing Windows servers virtualized, fall back on VMware.
Those who already have a Power HW in use or now have higher SLA conditions or performance requirements and this cannot be realized with VMware, fall back on the solution from IBM.
A mix is, as already mentioned, the best, but also the most expensive solution. It combines the advantages of both worlds and balances the disadvantages. This is conceivable if you are forced to expand your VMware/Power landscape due to Hana, but have very high requirements for the new environment.
From this follows: Mapping of the database layer (Hana) via LPAR and presentation layer/clients (PAS, AAS, ASCS) with VMware.
Both platforms have their advantages and disadvantages. In the end, both must be able to be integrated into existing processes.
It's not just a matter of what's more expensive or performs better, but what fits best into your landscape. Ultimately, it's the administrators who have to deal with it.
From experience, as is often the case, it's a philosophy question.