Head of Business Analytics & Technology
Bluefin Solutions
Why SAP must acquire a hardware vendor for In-Memory
09 Jun 2011
Business Intelligence (BI), HANA, In-Memory, SAP, ERP
At SAP's SAPPHIRE May 2011 conference in Orlando, I met with Ike Nassi, who has the austere title of Chief Scientist for SAP. He runs SAP's In Memory Database (IMDB) hardware program and was charged with building the original prototypes for hardware that run the underlying database upon which HANA now runs.
He is a deeply interesting individual and spending time with him reminded me of my own mentors at University - some of the late great computer scientists like Roger Needham and David Wheeler. There is a certain analytical style and restless curiosity which has been lost in later generations of computer scientists.
Ike built the VAX for Digital and he's been in and out of retirement for years. It's pretty fitting that he should come back to run this particular program for SAP and how different it must be to building the VAX. These days the hardware that runs SAP's IMDB software is commodity equipment that can be bought off the shelf, which is what he's been doing for the last few years - ducking in and out of Walmart.
How commodity is commodity?
Architecturally it's the same stuff that's in your laptop - Intel's x86 range of computers that has lineage back to the early IBM PCs of the late 70s. In real terms though this stuff is pretty expensive, because IMDB requires (the key's in the name, right) lots of fast memory.
Early versions of HANA 1.0 require rack based equipment but it's certain that later versions of IMDB will run on blade systems - high density servers that fit 8-10 units in an 18" high enclosure. Memory might only cost $100 per Gb now, but for a high-density blade with 2TB of main memory, this means $200k of memory alone. A fully populated IMDB blade enclosure with 20TB of memory can easily cost $3m.
So whilst it is commodity hardware - the costs can ramp up for large-scale systems, although it's worth bearing in mind that IMDB has some 10:1 compression compared to e.g. Oracle and a 2TB IMDB system might hold the same information as a 20TB Oracle database.
But SAP doesn't have a stack, right?
The chairman of SAP's Executive Board, founder Hasso Plattner, has always maintained that SAP is not building a stack - partially to take a peck at competitor Oracle (who acquired Sun Microsystems) and partially because it's historically been true.
SAP's flagship R/3 and Business Suite products will run on anything you like. The laptop I am penning this blog on has a copy running on it, and it runs on IBM's mainframe i/Series behemoths and everything in between. Almost any hardware and all the major databases from Microsoft, IBM, Oracle and (soon) Sybase.
But Hasso's argument is nonsensical in the context of HANA. SAP is implicitly building a stack with HANA because HANA only runs on one hardware platform (Intel x86) and one database (SAP IMDB). Several key executives slipped up and referred to the SAP stack at SAPPHIRE and this is testimony to the "no stack" argument falling apart. It is true that IMDB still runs on equipment sold by the major vendors: HP, IBM, etc. but this is just because they all offer equipment based on the x86 platform.
How is SAP influencing Intel's server strategy?
Well it's worth considering that SAP is a fly to Intel. They are still a pretty small consumer of Intel chips - partially because a lot of SAP's install base, particularly the larger customers, buy specialist equipment still running on UNIX platforms from IBM, Sun and HP - most of which does not bring revenue to Intel.
But Ike said he met with Intel engineers a few years ago and when asked what they should be doing, replied that they needed to increase the ratio of cores:RAM. Let's consider my laptop here. It has 4 cores and 8Gb RAM - a ratio of 1:2, which is pretty typical in the PC market. 3 years ago the top-end x86 equipment ran to 8 cores and 64Gb RAM - a ratio of 1:8. We are now up to 24 cores and 1Tb RAM - a ratio of 1:42.
And yet SAP are finding that IMDB is memory-constrained - the CPUs are not being worked in most applications and they need more RAM. Higher density memory coming later in 2011 should bring 2Tb RAM which should help. But there are very few technologies that need this much memory and neither Intel nor the hardware vendors are really pushing this.
What is SAP doing in the hardware space?
Ike was necessarily a bit tight lipped about what he was doing in the future, but it is clear that SAP is investing in some R&D here. Not to the extent that IBM and HP are, but they have a new datacenter where they have built out some new IMDB appliances.
And the key is that they're not just buying up commodity equipment any more - they are getting their knees deep. The team is trying to find out what equipment characteristics make IMDB fly, and they are getting some interesting conclusions. For instance, they found they can supercharge IMDB by putting an additional level of ultra-high speed memory in the hardware.
This is interesting because this isn't available in the equipment of any of the major vendors - only in the equipment that SAP is building out itself. And in the context of the sort of investment that IMDB appliances requires, a 10-15% increase in performance is significant.
What about the timeline of applications to IMDB?
This has been written to death by other people but the big prize is to run SAP's Business Suite on IMDB, which would be an Oracle killer. We are theoretically already here today - SAP are migrating Business Suite customers onto IMDB in the labs - but the reality is we are still a few years away.
By the end of 2011 we will see the very first NetWeaver BW Data Warehouse customers move onto HANA 1.0 SP03 (formerly known as HANA 1.5 or 1.2), which will be based on SAP's IMDB technology. But BW benefits so much from the performance of IMDB that customers will take it early in the product lifecycle and immature. BW doesn't affect the core business for many customers and that will be a risk worth taking.
It will take a further 2-3 years for IMDB to mature from a stability, performance and tooling perspective for many of the less risk-averse customers who rely on SAP's Business Suite for their core customers - and probably years longer than that for the more risk-averse customers who cannot accept any loss of reliability. This isn't a criticism of SAP's strategy but rather a reality check of how long it takes to take a database to market.
Why does SAP have to acquire and what is the impact?
Whatever Ike's team build out will be a toy in the lab and I don't think he has any other pretentions. When I pushed him on this, he didn't give a straight reply but rather suggested that SAP had no plans to do this in the short term.
Which makes sense - SAP doesn't have a proper IMDB product yet and building its own hardware would cement the idea of the stack and deeply upset relationships with good friends IBM and HP in particular. Building hardware now would be suicide and serve no purpose.
But IBM and HP seem unlikely to build out IMBD specific equipment and SAP need the performance boost of a tailored architecture - in time for when customers start to move their Business Suites on top of the In-Memory platform. This is likely to be 3-4 years in the future, based on the maturity of the existing IMDB platform and what industry analysts are thinking.
In order to build this tailored platform, SAP will need someone who knows how to build volumes of servers, how to distribute and how to support it. This is a specialist business and they won't want to build that capability from scratch: it would be a distraction.
So for my money they have to acquire, and I suppose the question is who? This is rampant speculation but "who not" is much easier - it won't be one of the big guys because they can't afford them. What's more, SAP would only buy a server vendor - they have no interest in PC sales, which narrows it down to one of a few players, or perhaps the server arm of an existing HANA vendor like Fujitsu. We will see.
Comments
John Appleby 22 Aug 2011
Good point and I'm with you; currently SAP seem to be picking carefully and giving POCs away for free. It would be cool if they would "rent" SAP HANA hardware in the cloud - and customers would pay for this, I am sure.
Paul Baverey 22 Aug 2011
Hi John, I know I'm a bit late on this as I've only just come across your blogs (keep them coming!!) but a huge potential for this (as Harald mentioned) is for SAP to off this via their On Demand service for customer POC's. This will allow them to show off 2 great pieces of new innovation.
Vitaliy @Sygyzmundovych 11 Jun 2011
Den, afaik for current HANA "Big Iron" hardware prototypes SAP used another nerds from the Valley: Colfax International http://www.colfax-intl.com/
Dennis Howlett 11 Jun 2011
In all the talk about hardware, I stumbled across this wee company that's doing interesting things. I wonder the extent to which SAP is tapping into the Valley Nerds? Check out: http://www.seamicro.com
Vitaliy @Sygyzmundovych 11 Jun 2011
Let me try to be short this time, although topic is certainly very tempting.
John:
Sorry bro, I need to start with 2 corrections. That’s that devil in me ;-)
1/ "...worth bearing in mind that IMDB has some 10:1 compression compared to e.g. Oracle and a 2TB IMDB system might hold the same information as a 20TB Oracle database..." As was discussed in comments to your previous blog, the current rule-of-thumb is 5:1 compression for columnar store of IMDB. And it is a compression ratio not to the table sizes in other database (data in Oracle or DB2 can be compressed too although with less reduction due to row-based storage), but to hypothetical size of table = # of records * record length in bytes. The reason I am quite sensitive to this topic is that I had BWA customers who followed the simplified thinking and later had issues with fitting their forecasted data into RAM of the accelerator. With HANA it will be even more tricky as there are much more variables in the sizing.
2/ "…We are now up to 24 cores and 1Tb RAM - a ratio of 1:42…" It is up to 64 cores for Intel Xeon X7650 making the ratio 1:16. The server can fit up to 2TB, but SAP decided to stop on 1:16 for HANA with Nehalem-EX architecture, and now with introduction of Westmere-EX and 10 cores per CPU even to lower the ratio to ~1:13. It will be interesting to see this ratio evolving as SAP will focus more and more on compute intensive workload on HANA comparing to analytics workload of just storing, scanning and aggregating.
Continuing Intel-SAP discussion, I think this *is* actually strong HANA differentiator. No matter what SAP bosses are saying and what their unaware marketing repeats, they are not pioneers in in-memory computing. Korean company ALTIBASE developed Main Memory DBMS (MMDBMS) offering in 1999 and right now dominates the market in South Korea. Current product – ALTIBASE HDB (Hybrid Database) – runs on multiple hardware platforms. And this is where SAP strength in deep integration with specific Intel CPUs should come. SAP claims that IMDB running on Intel E7-8870 is 37% faster than running on Intel X7560. Gain of 25pp is thanks to mechanics (25% more cores, 25% more L3 cache), but the rest – SAP claims – is thanks to deep integration of IMDB software using CPU-specific libraries.
Steve:
I bet we will see a split in in-memory use into the commodity-like RAM-storage logic-push-down optimization technology for re-factored versions of their products, but as well into the high-end “every percentage counts” ultra-performance driven use cases. Especially where SAP will be going against others to prove own performance advantage for customers or prestige use cases. Should happen pretty soon.
Harald:
I agree that super-fast computers do not release us from proper modeling, and even more – require even more in-depth thinking. The issue is that customers’ and (oh, Lord!) some consultants’ expectations are that they will be able to throw anything on the machine and will get their instant result – happily confirmed by sales folks. Countless times I had this question if BW modeling best practices still matter with BW Accelerator. And my answer was – best practices do not release you from thinking, and neither BWA. It actually adds.
PS. I promised to be short this time and I am :) Not touching *lots* of other extremely interesting points brought by John and those who commented so far.
PPS. John, is it possible for your SoMe team to change moderation from active to passive, where comments are immediately published, and then removed if needed when responsible people show up in your UK office?
Cheers,
-Vitaliy
John Appleby 09 Jun 2011
Lots of good points as always Harald. I've not even touched on the data model challenges for HANA and we both know these are substantial. Only those working with the product know how complex SAP Business Suite models are and how they are hard to make perform well in any OLAP data model.
Also not suggesting SAP would offer HANA only on SAP hardware, but rather that they could make better HANA specific hardware than by using a commodity server from HP/IBM, particularly for applications requiring the highest possible performance.
Harald Reiter 09 Jun 2011
I am currently on a SAP HANA implementation project which has the objective to be Google fast and Apple easy. This is my second SAP HANA POC and we used HP large appliance in the first one and now using IBM medium appliance in the second POC. Performance of HANA in my previous POC was not limited by the hardware itself but by the data model. If your data model in HANA sucks then hardware in most cases will not fix the problem…just like with SAP ECC.
At my current POC though we are vetting HANA against an in-memory application from another vendor that is really fast - at least from a subjective point of view. At the end of the POC we will need to show that SAP HANA is as fast or faster than the current in-memory software they are using but with the advantage that they can change the UI as they can't do that at the moment.
I don't really believe that the success of HANA will depend on the hardware used but weather SAP can successfully migrate APO, SRM and Business Suite to HANA and at the same time remove all dead weight from those apps to actually allow innovation to happen.
Whenever we have client discussions about SAP HANA and we discuss use cases we have people from Walldorf knocking at the door to listen in...mostly various product teams...to come up with SAP HANA specific applications as this will drive the adoption of HANA forward.
You and me know that between marketing and reality there is often a huge gap and it’s no different with HANA. Creating good data models with SAP HANA is not trivial and that’s just for read-only applications like reporting – moving in the transactional space with APO/SRM/ECC will be a real challenge.
Aster Data got bought by Terada not so long ago mainly due to their software (SQL-MapReduce) and the ability to run on commodity servers or cloud infrastructure. Using commodity hardware usually brings the cost down due to competition with the progressive step of running it in the cloud.
I can see SAP working on hardware mainly to provide a reference architecture for hardware providers but to use it as the only option to provide HANA would in my opinion backfire at them.
I might be wrong – time will tell – but I would rather see SAP offering HANA in the cloud also on a subscription bases to allow more companies to do POC’s as even those can cost quite a bit and to increase adoption overall.
Keep those blogs coming – really enjoy reading them and hope to see you in Madrid and/or Vegas.
Harald
John Appleby 09 Jun 2011
Steve - great feedback as always.
I don't think that these two things are in conflict because I think SAP only needs to build HANA hardware for very high performance scenarios.
Once they are past the PR phase of every HANA scenario having to be high performance (18 months or so) then they should be happy to run HANA on truly commodity hardware for smaller customers.
Then it will become affordable, which I think is OK - as per the Mac Mini example.
Steve Rumsby 09 Jun 2011
This whole situation makes me just a little bit nervous. I understand why custom hardware is needed to wring that last little bit of performance out of HANA, and I know there are customers out there that need all that performance, and probably more, right now. Bringing HANA to market on custom hardware makes a lot of sense. But there are many more customers out there that don't need to process TBs of data, and don't need 100x or more increases in speed. Just being able to run reports 10x faster would be more than good enough. I suspect for the majority of SAP customers, HANA on standard issue hardware would be perfectly acceptable. It won't produce the headline grabbing numbers currently driving the HANA-hype, but it will do the job just fine. But the current incarnation of HANA on custom hardware is just too expensive for all but the biggest of organisations to contemplate, and if SAP get into the hardware business surely that only make sense if HANA continues to be available only on custom hardware? I don't like where that seems to be leading.
HANA is currently a niche product. If it is to escape from that niche is has to become affordable, and I don't see that happening if it stays on custom hardware...