Maksim Kabakou - Fotolia
The new technology required to run SAP Hana will force sourcing executives to rethink their options for hosting SAP software where Hana-based systems are needed.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Hana technology introduces some major differences from the traditional SAP architecture. The Hana architecture only runs on the Hana in-memory database management system (IMDBMS), not the traditional DBMSs from other suppliers.
This requires much larger amounts of server main memory because the entire database operates in main memory. However, the good news is that Hana databases are much smaller than traditional architecture, due to their high levels of data compression.
The Hana IMDBMS includes its own data replication features, which affect high availability and disaster recovery operations. Hana also needs new software tools to manage it, and server virtualisation is much less commonly deployed with Hana technology today than with traditional SAP architecture.
Client feedback consistently shows that larger Hana appliances are more expensive than traditional servers.
If running on-premise Hana will be too complex or costly, sourcing executives can also evaluate Hana hosted services or consider public cloud infrastructure-as-a-service (IaaS) deployments.
Read more about SAP Hana
You can offload most -- but not all -- management, handle it in-house or try something in between. Here's a rundown of the HANA deployment choices, ranked by administration effort.
The SAP board has launched an initiative to publish and clarify roadmaps, especially in respect of S/4 Hana and its cloud applications, and one product of this is a new technology choice tool.
Third-party SAP hosting providers face substantial engineering costs in designing new platforms for Hana. SAP applications run very differently on Hana compared with traditional architecture. Existing hosting offerings must be redesigned to provide the large memory operating system (OS) instances that Hana needs. Virtualisation technologies must also be re-evaluated against using Hana’s core capabilities.
Also, SAP’s Hana Enterprise Cloud (HEC) offers a managed private cloud. In this model, SAP provides the entire IaaS hosting and Basis managed service model for all layers of the stack, except for any custom ABAP code, which is still maintained by the customer.
For providers, this is another challenge. Already-fierce competition has been made worse by the existence of SAP’s HEC, against which all other hosting providers will be compared. Gartner expects a number of smaller SAP hosting providers will find their businesses no longer viable and will exit the market, although there may be an opportunity for some to partner with SAP to deliver HEC as a white-label hosting arrangement.
Another issue for SAP customers is that there are very few reference customers anywhere that are live on Hana systems, for either S/4 Hana or Business Suite on Hana (BSoH), and have proven disaster recovery capabilities.
SAP S/4 Hana cloud editions are new and very different because they are multitenant software-as-a-service (SaaS) offerings that are available only directly from SAP. SaaS systems are very different from general IaaS SAP hosting technology options.
The market for Hana hosting is growing as more of SAP’s customer base migrates. A 2016 Gartner survey identified more than 170 suppliers offering SAP hosting. The advent of new, competitive public cloud-based hosting models will create opportunities for sourcing leaders to deliver cost savings for SAP Hana hosting.
During the same period when SAP introduced Hana technology, there has been huge client interest in both private and public IaaS for all IT projects, including SAP infrastructure
Amazon Web Services (AWS) was the first public cloud IaaS provider to offer Hana systems. Its 2013 SAP partnership offered Hana One database as a service, which allowed a complete Hana instance to be provisioned on AWS public cloud IaaS in less than an hour. This enabled customers and SAP partners of all types to quickly and cost-effectively acquire Hana technology for evaluations, software development and proof-of-concept trials, and pay for it on an hourly basis.
SAP has certified the AWS public cloud IaaS service to run full production systems of Hana-based applications, starting with SAP BSoH, followed by SAP Business Warehouse (BW) powered by SAP Hana and then S/4 Hana.
In September 2016, SAP and AWS announced support for the new SAP BW/4 Hana data warehouse system. The X1 AWS server “instance types” are optimised for high memory, and two new types have been introduced recently to provide support for Hana. The x1.32xlarge instance type provides 2TB of RAM backed by the requisite storage, while the x1.16xlarge instance provides
1TB of RAM.
The second major public cloud IaaS provider, Microsoft Azure, also supports SAP Hana. In May 2016, Microsoft announced that SAP had certified Azure for Hana workloads up to 3TB in size, and also certified scale-out to support Hana BW workloads up to 32TB in size. Again, these deployments are limited to certain regions, but Microsoft will extend these over time. It is also likely that the range of SAP systems supported by Azure will continue to expand because Microsoft has a track record of catching up in other late-entry marketplaces.
Lower three layers
Neither AWS nor Azure directly supports the full layers of the SAP technical stack. Rather, they focus on the lower three layers, including the hypervisor, but excluding the OS. This means that other new service providers have partnered with these cloud providers to deliver the remaining top layers in the technical stack, without providing their own Hana-ready infrastructure.
But because multiple providers are now involved, SAP customers must take care when planning or operating any hosting arrangements involving IaaS. When comparing the total cost of ownership of public cloud proposals, sourcing executives must look at the cost of not just the cloud platforms, but also these middleware service providers. The operational service and management of multiple suppliers must be tied in from the start, possibly using a multisourcing service integrator to provide them.
As well as providing large-scale infrastructure optimised for Hana, both AWS and Azure deliver flexible charging options. Most clients usually start off with a pay-as-you-go model for individual servers, where savings can be made initially by using the cloud in new ways — for example, by turning off unused development and test environments.
In the longer term, clients can save more money with prepaid options. AWS’s Amazon Elastic Compute Cloud (EC2) offers the concept of “reserved instances,” where, by booking server usage and paying partially or completely up front, clients can achieve discounts of up to 75%, compared with pay-as-you-go.
Likewise, Azure also offers prepaid models, but has the option for smaller businesses to buy through their existing resellers, and for larger businesses to enter into an enterprise agreement. Both of these options provide substantial discounts.
Both cloud providers are competing on price, and have offered regular price cuts. AWS will pass a series of public cloud IaaS cost reductions on to its customers by focusing on scale of deployment and increased automation. Azure matches this.
AWS and Azure are both popular choices for midsize organisations because costs can be spread over multiple years and match business demand, rather than having to make regular expenditure on capital upgrade programmes.
This is an extract from the Gartner research note “The Impact of SAP Hana on the SAP infrastructure utility services marketplace”. Derek Prior is a research director at Gartner.