I've seen SAP being very slow in further opening the support to run SAP HANA virtualized with VMware, and often I heard arguments that "performance tests needed to be very exhaustive to ensure customers were aware of the trade offs".
The fact is that I truly believe that being over-cautious on this has been hurting more the SAP HANA adoption rates than many at SAP might consider.
My perspective on this is that: IT'S ALL ABOUT THE TCO !!!
It is now supported to run SAP
HANA Productive Virtualized on VMware: yes, but…
Keeping the limitations of:
·
single productive HANA system per server – yes,
even although virtualized;
·
and mandate to use only E7 based certified
servers – again yes, event although virtualized;
Will
hinder the increased HANA adoption rates, expected as a consequence of the
announcement of productive support to run HANA virtualized with VMware, and
will make more customers postpone their purchase decisions.
Customers are disappointed, service providers even more. It’s
hard to understand why SAP is putting such restrictions on HANA deployment
options, when the one that suffers the most is SAP itself with lower than
expected SAP HANA adoption rates, and with increasing numbers of customers that
bought the license but haven’t yet installed it, keeping it sitting on the
shelf (and building up steam…).
Although I do understand some of SAP’s concerns in regards
to HANA performance in a virtualized environment, the human factor is the one
bringing risk and not the virtualization technology in itself. The human factor
is a risk both on virtualization projects as well as SAP Systems implementation
projects, and should not be a reason to limit customer’s deployment options.
I believe the HANA performance discussion when running in a
virtualized environment is overrated!
Today, when evaluating potential HANA implementation
projects, the limitations referred above still make many customers reach
negative ROI numbers.
After all, the virtualization discussion is a TCO related
one! Customers should be able to decide on themselves how much they are willing
to pay for each system based on its business requirements, balancing less performance
needs with more affordable TCO. Increased deployment options would provide
further possibilities for customers to achieve positive ROI for each of their
implementation scenarios, and through that to speed up the HANA adoption rate.
Through this blog post I’ll develop and fundament further
these ideas, my understanding of the reasons for these restrictions as well
ideas to get moving faster.
Setting the scene
It’s obvious that it was a carefully coordinated announcement
between SAP, VMware and EMC, since the SAP’s official press release only was
published early in the morning of that day, SAP Note 1788665 was also
released for customers around the same time, and simultaneously there were
published blogs coming out from the 3 companies!
You have no idea how much customer meeting at EMC World were
completely absorbed by this topic! The customer interest was simply huge!
Remember that there were about 15.000 people there from all over the world.
Never SAP was such a hot topic in an EMC conference.
There was a huge enthusiasm in the HANA community out of
that announcement as well, translated in blogs, tweets, LinkedIn posts, mails
and a lot of other types of communications.
But after the initial enthusiasm with the announcement, and
after reading carefully the conditions of that announcement, there was lots of disappointment
among customers and service providers.
Virtualization is today a mature technology, widely adopted
by small and large customers as well as service providers around the world, and
its benefits are well understood. So, the reality feel a lot short on the expectations.
There were very solid reasons why this announcement was so
expected: for many customers around the world (as well as for all outsourcers
and service providers I know!), the main reason not to adopt HANA was the lack
of a positive ROI business case.
Based on those customers and service providers experience, “productive
support for HANA Virtualization” in its full breath, like all the VMware knowledgeable
people understand virtualization, would be a way to turn many of the current
negative ROI business cases into positive ones.
The SAP Imposed Appliance Model
as a key cost driver
One key factor driving negative results out of the business
case was SAP’s mandate for HANA to be deployed in production only through a single
system dedicated Physical Appliance Model.
Why was the appliance model a problem? Because appliance
means in the SAP HANA world, having a silo of hardware dedicated to a single
HANA system, which all experienced IT Operations Managers know to be a key long
term cost driver.
SAP mandated that each physical appliance could only be used
by a single SAP system, and even on SAP’s cloud, you had to “order” t-shirt
sized systems that corresponded to the physical boxes available. This meant
that to grow, your systems need to be migrated to another server, with negative
implications in terms of cost and service levels. I know this is no longer
completely true as a consequence of the TDI
Program. But when servers are concerned, the principle still applies.
I had a meeting with a service provider last year (one of
SAP’s HEC partners) and the guys on the IT Architecture and IT Operations teams
were going nuts! The guys at that Service Provider’s cloud BU said that for
them to be in business, they needed to achieve cost factors, which the IT guys
said being simply impossible with that “physical appliance model”.
The current restrictions do still do not allow for this
Service Provider to get the numbers straight. We must remember that on the
cloud, the market defines the price! Not the provider. As if you are out of
market price, you may be investing to loose money.
Expected Benefits from the HANA on VMware
productive support announcement
From those comments you can realize that the expectations about
the HANA on VMware productive support announcement were related with the
possibility of:
·
Reducing costs of change;
·
Reducing costs of operation;
·
Standardizing datacenter practices;
·
Reduction of startup costs;
·
Greater flexibility on server choice;
·
Get High Availability at lower costs;
·
Eliminate the cost of vacantness;
·
Assign resources to each HANA system only as
required;
·
Reduce the cost of growth…
In summary, there is a wide understanding that the
restrictions SAP is imposing on the infrastructure technology deployment
options are a key factor in driving up TCO, and as consequence leading to
negative results on the business cases of many customers when evaluating the
adoption of SAP HANA.
Public cloud is not the answer
to everything, everywhere in the world!
I know that some will say right away to go for a public
cloud! Also a lot have been written about that, and although the US is a big
market, it is not the whole world, and in other regions of the planet, there
are economic, technical and legal reasons not to consider a public cloud for
certain IT functionalities.
So, let’s assume that the future will be hybrid, and that
having a part of your systems under direct customer control will be the reality
for most customers. I believe increasing number of people at SAP are already
realizing that…
Nevertheless, the secret sauce for most of successful public
cloud providers is the usage of white-labeled cheap hardware with a
virtualization layer on top!
For example it has been widely referred that Amazon’s HANA
offerings are based on virtualized Intel E5 based servers. Other SPs are doing
the same, so would be better for SAP to assume it once and for all.
Why can’t individual customers get access to the same
conditions as these cloud providers? What is the reasoning of SAP to allow more
openness for the cloud providers and then to put lots of restrictions on its
own customer base?
SAP imposed restrictions when
running HANA on VMware
The announcement for productive use of SAP HANA on VMware
still entails 2 restrictions that on my mind (and of many people I speak to in
customers and service providers) make no sense:
1.
Mapping of 1 to 1 between the HANA Virtual
Machines and Physical hosts (which means that most of the higher TCO driver are
still there, like the cost of vacantness);
2.
Mandate to use only the SAP Certified Intel E7
based servers (which presents most customers from reutilizing their existing
private cloud infrastructure, in most cases based on E5 CPU due to their better
price/performance – as the Amazon’s of the world are also doing).
The 1st restriction I can only understand as a
transitory step to a more open update to SAP’s support statement allowing for
multiple HANA VMs on the same host, as this restriction undermines all the key
TCO related expected benefits out of this announcement: customers with many
smaller productive HANA systems being able to run on the same server, while
leveraging the in-memory capabilities of HANA.
Again: It’s not about performance, it’s
about TCO!
The 2nd restriction also does not make sense, as
some of the statements I’ve seen from people at SAP to justify the imposition
of certified E7 based servers, many times to not account for the own responsibility
of customers to make compromises based on their real business needs:
·
If I as a customer, am expecting 10x better
performance out of HANA adoption, and (by absurd) instead of 400x better
performance if going for E7 certified servers, when choosing Intel E5 based
serves get only 200x better performance, what is the problem?
·
And if I as a customer want to run it
virtualized with E5 based systems and the performance gain is only 180% against
the 200x on physical E5 and my initial expectation was of 10x better, why can’t
I do it if I’m making that choice in conscience?
I think the performance discussion is overrated and SAP is
harming HANA adoption with these complications.
I’m seeing customers with the check in their hands just
waiting for datacenter maturity to show off a bit more, as the datacenter
integration options available are also a signal of the overall maturity of the
software.
The most absurd thing I’ve seen are customers where business
leaders excited with SAP’s sales rep presentations signed the check for the
licenses, and now when presented with the IT bill for the systems deployment
and operation, have ordered a halt to the projects and a full re-evaluation of
the deployment options since they did not expect the costs to be that high.
As I said in my comments at the SAPHANA.com
blog, the SAP HANA virtualization and openness discussion is all about TCO,
and SAP would only win with that!
SAP HANA Benchmarks are a must!
SAP is a very large company, and with no doubt full of very
smart people. But I do know that sometimes, perfection is enemy of speed, and balancing
both is not always easy.
Customers are asking for it, service providers also, I know
that some manufacturers also want more openness. So, why do these restrictions
subsist? SAP must balance better the engineering veins with its business veins.
I’ve heard about discussions with the SAP Benchmarks council
about the definition of a SAP HANA standard benchmark. This is definitely a
missing piece. Also, with the abstraction introduced by hypervisors, running HANA
on Intel E5 CPUs or Intel E7 CPUs should become a cost/benefit discussion, and
not a factor for not adopting HANA.
An infrastructure design
recommendations whitepaper might be useful
But are there any real severe performance risks when running
virtualized systems?
In fact, I’ve written before about it (see the chapter “An
evolutionary analysis of SAP HANA” in my previous blog post), and most of
the performance and availability problems I’ve experienced both as a customer
and as a consultant (excluding the ones related with bad code), were due to
infrastructure integration problems.
It’s not a problem of HANA in the same way it’s not a
problem of the hypervisor.
Is a fact that virtualization brings an additional variable
to the performance equation.
In regards to virtualization, especially in the performance
space, I haven’t yet seen a clear paper describing the infrastructure design
and integration variables that influence the performance of a virtualized
system. Aspects like the network and storage design, as well as their
configuration in the virtualized environment play a key role in many of the
problems I’ve experienced.
My experience has shown that most bad virtualization
experiences are not related with the capabilities of the virtualization
software. Yes, bad virtualization experiences exist. In the same way bad SAP
implementation experiences exist. It’s a factor of having humans involved! In
fact, the possibilities of VMware today make it possible to virtualize more
than 95% of the existing productive SAP Systems in the world.
Problems arrive mostly due to the lack of understanding that
I’ve observed by virtualization consultants and engineers in regards to the
demands of high performance databases and large virtual machines. In that
sense, the production of a whitepaper providing design best practices for
virtualized SAP infrastructures (in line with you could find in the old SAP
Network Integration Guide), would help to reduce the human risk that is today
(in my opinion) confusing the virtualization performance discussion.
Why do I say this? When talking with virtualization
consultants, they always take for granted that performance is there and is no
secret. But I have to say that I’ve already surprised a bunch of very VMware
consultants with real customer problems to which their configuration practices
would represent a problem. Again, it’s the human factor. Humans are not
perfect, and there are of all kinds. This might lead me to another topic that
is the value of converged infrastructures, but let me leave it to a later blog
post…
On the same way, I’ve talked with a bunch of SAP consultants
for which an hypervisor is a completely unknown world. I remember my
grandmother saying: you are afraid of what you don’t know.
So, a document that merges SAP and VMware knowledge together
with infrastructure architecture would streamline the conversation lines
between these teams and hopefully contribute definitely to enable us all to
move forward from this “performance” discussion.
Conclusion
Benchmarks and an infrastructure recommendations whitepaper
could definitely be useful, but not having them cannot be a justification to
limit customer choice.
Human error is a factor in all projects, and that is a risk
that any customer must account for! That’s why certain implementation consultants
make more money, and others get unemployed. It should not determine the customer
available deployment options of SAP HANA.
Poor IT governance and IT architecture practices do exist in
some customer organizations and service providers, in the same way there are IT
organizations very well run. SAP should place the responsibility of choices on
customers and partners, and not limit from the start the potential market reach
that its solutions will have.
Virtualization of SAP HANA in a fully shared hardware model,
using commodity existing components today available in customer organizations,
is definitely a key factor to drive further adoption and make many of those
customers that have the HANA software sitting on shelve to get it out, install
and start to benefit from it.
I hope that SAP moves faster in taking these
steps than it did in making the announcement of last week for productive
support of running SAP HANA on VMware, and through that enable customers to choose
and decide on their own what variables matter the most for each system: if
performance or TCO.
