SuccessFactors gears up to prove HANA multi-tenancy at scale

Some of the numbers quoted at last week's SuccessConnect event in Rome illustrate the impressive growth of SAP SuccessFactors. It now has 34 million users spread across more than 4500 companies and its servers process 4.1 billion transactions each month.

These numbers put it in the big league of cloud application vendors and therefore its planned transition to the SAP HANA database platform is of more than academic interest. This will be a real test of HANA's potency, and the vendor is taking great care over the transition. As president Mike Ettling told me in Rome last week, SuccessFactors is already at the leading edge of HANA adoption having implemented analytics and reporting on the database.

There's an element of, we're going where no man has gone before. Running this scale of multi-tenant code in memory, we don't know what's going to happen.

Even with analytics and reporting, I'm the biggest HANA user in the planet. We're in Star Trek territory.

I dug into this further in conversation with senior VP of product management Dmitri Krakovsky. He reiterated the point that the migration ventures into uncharted territory.

Nobody runs HANA in a multi-tenant environment at this scale. That's why we want to be careful, thoughtful — because it's live customers in production environments.

What we don't want to do is take 4,500 customers with all their data and move them from one thing to another because frankly, there isn't anybody who has used HANA at this scale as we would use. Right now, we run about four billion transactions a month and the thing is just growing, it's doubled at least over the year and it's growing very fast.

Scaling to billions

HANA's support for multi-tenancy is not in doubt — it explicitly supports multiple different applications on a single HANA instance and is successfully running multiple instances of SAP Business ByDesign, which last year began migrating its customer base to HANA. What is at issue is the untried nature of what happens when that multi-tenancy scales up to thousands of instances and billions of transactions.

SuccessFactors currently runs on the Oracle database, which went through its own challenges of scaling multi-tenancy during the dot-com boom and then in the mid-noughties as SaaS vendors grew in size. Massive outages at eBay in 1999 and at Salesforce in late 2005 were among the most spectacular outward signs of these growing pains. Many other less visible failings have led to multiple tweaks over the years. SuccessFactors has itself built up a decade and a half of experience on Oracle, as Krakovsky told me:

We've been fine-tuning our app for fifteen years now to run on something else. We've squeezed every little inch of whatever could be from it.

Migration plans

Much of what has been learned from that history is already known to HANA's designers and to the SuccessFactors operations teams. But the vendor must still tread carefully and monitor progress to ensure there are no unexpected surprises as it gradually migrates more and more customers to the HANA database. Krakovsky explained the migration plans.

For some areas of the product that benefit most, we'll move the majority of customers to it. Specifically, Employee Central reporting is now run on a HANA-based stack. We move the data out of the transactional store and run the reporting on top of HANA database. We've done it now for I think all Employee Central reporting customers — three hundred roughly, give or take. That's one side of it.

For other modules, we've started putting customers live in production on the HANA stack. At the moment, we have a handful that are doing that in live production. The basic idea there is, as we get more and more comfortable with how it works — the scale, the performance and everything — we will be moving them over.

I think the articulated timeframe for this is first half of 2017. Internally, we'd like to do it sooner, but we don't want to commit to that because there's some discovery involved with how it's going to go.

As well as understanding how HANA will operate at scale, getting the migration process right is another area of focus. Unlike the ByDesign team, which from the start was putting new customers entirely on HANA, the SuccessFactors team are only putting new functionality, such as reporting, directly on HANA. For the existing applications, the team has opted to start migrating incumbent customers first, he said.

The handful of customers that are live right now — for the app, not for reporting — they are existing customers that have migrated. That's another thing we want to really figure out and understand deeply, is the migration process.

Why make the move?

Other new functions besides reporting that are going straight to HANA include the recommendation engine that drives the recently introduced Intelligent Services capability.

We use HANA graph engine to calculate relationships between people, groups, belonging to particular sets. That's an example that was never on Oracle or anything else. It's on HANA from scratch.

I wondered if there were any special issues the engineers were keeping an eye on as they monitored HANA's performance, but Krakovsky told me there were no major areas of concern. It was more a case of finding ways to speed up certain write operations to ensure no one saw any dips in transactional performance after migration. Read operations are much faster across the board, he said.

[HANA] works well for reads. For writes, some stuff is better, some stuff is worse. Then we need to go and diagnose and see what's going on.

Aside from reporting, we have other areas of applications that are read-heavy types. For instance, we have role-based permissions. It's a way to dynamically calculate permissions on the fly based on a whole bunch of different things.

The reason we're doing it, I think over time, it will be very, very beneficial. We'll break even or be a little bit better on writes. We'll be a lot better on reads.

In analytics, it's being able to do all this dynamically. You don't have to pre-calculate all the indices, all the dimensions, and if you need something else, you don't have to ask somebody else to do different data modeling for you. With HANA, a lot of this is more of an on-the-fly decision.

We'll see a lot of benefits, but it's not a marketing slide where you just plug it in and it all just magically works.

My take

There are many varieties of multi-tenancy but none are more challenging than multi-tenancy at the enormous scale of global cloud application vendors like SuccessFactors. Proving it can be done will be a major coup for HANA and it's encouraging that Krakovsky gave no hint of problems on the horizon. But it's wise for Ettling to emphasize the unknowns given how much is riding on the success of the migration. This is not a job to be rushed.

Image credits: Dmitri Krakovsky on stage in Rome by @philww.

Disclosure: Oracle, Salesforce and SAP are diginomica premier partners. SAP paid my travel expenses to attend the SuccessConnect EMEA event.