I migrated my first SAP database to NetApp® storage in 1999.
When I demonstrated the ease of restoring a large Microsoft SQL Server database to a consistent point in time, my customer was willing to deal with integrator complaints and give it a go, first for their development/testing systems, and then for their production systems. Although they loved the reliability of their rapid data protection, they were very surprised that the database performed better than their local disk had previously.
I got pretty good at applying that experience and did about 10 other SAP implementations over the years. NetApp’s relationship with SAP grew a hundredfold. Soon they even had NetApp SnapManager® for SAP, which automated the process for data protection, cloning, database replication, and disaster recovery in ways no other storage vendor had.
This new thing called HANA
Eventually, SAP introduced this new thing called HANA, and nobody understood what it meant. It used persistent storage in totally new ways, with different performance requirements. SAP initiated a program called TDI — or tailored data center integration — that essentially dictated which original equipment manufacturer (OEM) offerings would be certified to run SAP HANA, outside the original HANA appliance model. This was very different from the previously known relational database management system (RDBMS) for which everyone had trained. In the past, we just had to meet certain performance criteria by using an SAP load tool, and we were pretty much set. Getting included in SAP HANA TDI is not at all easy to achieve, which makes it a pretty big deal when an infrastructure company does achieve it.
Wait, did I say infrastructure company?
Azure NetApp Files and now Cloud Volumes Service for Google Cloud are SAP HANA Certified
Imagine how difficult it must be for someone offering hyperscaler-resident storage to achieve this recognition — to be listed in the Certified and Supported SAP HANA Hardware Directory. And it’s not just for one major cloud vendor, but for two.
Well, NetApp did it. Kudos and congratulations. Azure NetApp Files is a certified storage provider for SAP HANA, not just for the shared file directories, but for production instances. You’re not in Azure? No problem. This SAP-certified solution is also available through NetApp Cloud Volumes Service for Google Cloud.
NetApp helps SAP run SAP
Not only did NetApp achieve that, but SAP is shouting to the world that they use NetApp storage in their own hosted customer instances — nearly 150PB of it. It’s clear that they’ve figured out the same thing my customers did years ago: NetApp delivers data services that are unmatched in the way they protect and manage both unstructured and block data.
So … great! Now we have NetApp providing SAP data through Azure NetApp Files, and through Cloud Volumes Service for Google Cloud. The world has changed overnight! Data centers will never be the same again!
Well, let’s take a breath.
Progress in the world of ERP is more tortoise than hare
If there’s one thing I know about SAP and the world of enterprise resource planning (ERP) in general, it’s that progress is slow. It can sometimes take more than a year to simply plan an upgrade from one dot release to another. These systems run every part of an organization, and making major changes is equivalent to swapping out your spinal cord while you’re trying to run a marathon. To say that firms are risk-averse with these systems of record (especially when dealing with financial auditors; these are financial systems, after all) is a gross understatement. Also, SAP interfaces with hundreds of other applications that either augment its functionality, transport data in or out, or interact with business partners. Change can seem generational.
However, we can’t discount the overwhelming urge of CIOs to get out of the data center business (unless data centers are, in fact, their business). The new economics of IT are causing decision points to have different outcomes than we would have thought possible just a few years ago.
I spoke with an auditor friend today whose firm is moving “everything” to Azure. I asked him if that included SAP, and I got the predictable response, “Oh no, that wouldn’t even be considered.” I’ll bet that within 24 months, the firm has its Azure skills up-leveled, this move is going to be the hot topic of discussion within IT management.
Why would you put your SAP environment in the cloud? Well, consider the pain of getting hardware wrong when performing an on-premises integration. In the cloud, it’s a reboot on a larger instance. But that can’t be the only thing, as cloud does bring with it some risks.
Why Azure NetApp Files and Cloud Volumes Service are game changers
Here is where Azure NetApp Files and Cloud Volumes Service shine. The ability to instantly create NetApp Snapshot™ based copies of SAP landscapes saves the one resource that a company can’t make more of: time. SAP is well known for its use of many instances, for sandbox, development and testing, QA, and so on, not to mention production, and then of course the disaster recovery copies of all of those copies.
Also, regarding time: Getting Azure NetApp Files or Cloud Volumes Service connected to your instances takes minutes. These small factors of time are not what SAP-knowledgeable folks are used to, at all.
Still, this development is relatively new (and available now). Nobody is moving tomorrow because of these recent announcements. However, if you’re an SAP shop, there is low-hanging fruit to be had by taking advantage of these offerings. For instance, your internal SAP training efforts can benefit from rapid cloning of SAP landscapes, which can just as easily be destroyed, all through API calls. Also, why spend all that capital on sandbox and development/testing systems? Do your development on these systems in the cloud, transport them to QA on your on-premises systems, and then deploy. That’s three-fifths of the landscape environment — real money and data center costs to be saved.
This should sound familiar. Remember back in the 2003-to-2005 time frame, when a little company called VMware came about, and nobody wanted to put production systems into this newfangled virtualized environment? They couldn’t trust it, so they started putting only their development and testing stuff on it? I’ll bet that now, anyone in your firm who wants a physical system for their application has to go through all sorts of hoops to justify it (and probably can’t).
So maybe we’re still in 2004 in regard to SAP in the cloud. However, it’s OK to dabble, especially when there’s time and money to be saved doing it.