SAP S/4HANA on public cloud: It can be done, but should it be done?

[ComputeExperts]

I’ve been speaking to customers recently about models for deployment of SAP HANA and SAP S/4HANA. Many customers I speak to are considering public cloud in some shape or form. At the same time, the strong message from SAP is “come run S/4HANA in the cloud”[1], whether that be SAP’s own cloud or one of the public cloud hyperscalers that SAP has a relationship with. My own view is that while public cloud clearly has a place in the SAP architect’s kit bag, I’m feeling a bit like a certain scientist in a famous movie about dinosaurs right now, to paraphrase:

“Your SAP architects were so preoccupied with whether or not they could run S/4 in public cloud, they didn't stop to think if they should.”

The real challenge here is that to really realise all the best business outcomes of moving into the public cloud you need to adopt a SaaS model, but that can be hard to do for many SAP customers. Let’s explore this dichotomy in more detail. What should you be looking for when considering how and where to host your S/4 landscape? Here are a few points to consider:

Issue #1: The first issue for those looking to move to S/4 is that the many different approaches to implementing S/4 in the cloud create confusion and you can be left not understanding what you are really getting. So let’s lay out the options as clearly as we can. In reality this is a little bit of a simplification, but presents the broad set of options available:

• SAP S/4HANA Cloud (otherwise known as S/4HANA Cloud Multi-tenant Edition)—This is a SaaS offering that you buy from SAP only. This is usually hosted in in SAP datacentres where they have them in-country or in-region, but they may use other third parties where they don’t. The actual datacentre ownership probably doesn’t matter to you anyway as you are buying a software service from SAP. The important point to note about this option is that you don’t get to customise it at all in the traditional SAP R/3 way. It runs as an entirely vanilla S/4 instance[2] and any extensions need to be created in SAP Cloud Platform (SCP) and only using whitelisted APIs. So unless you are ready to throw away all your customisations, this is only any good for new adopters of S/4, and even then customisations will require investment in cloud developers with specific SAP skills. S/4HANA Multi-tenant Edition will also require you to accept four updates per year according to SAP’s schedule, not your own.
• SAP S/4HANA Cloud Single Tenant Edition—This is also a SaaS offering that you buy from SAP. Again this might be out of a SAP datacentre, one of their partners, or a hyperscaler, but it doesn’t matter because you purchase the service from SAP. This option does allow some limited customisation via SCP, but if you have your own custom ABAP or Java code that you want to retain in some form, forget it, you can’t run that, so again it is really for new S/4 adopters who want just a little more flexibility and control on a vanilla S/4 implementation.
• S/4HANA in SAP HANA Enterprise Cloud (HEC)—This is a basically an IaaS offering that you buy from SAP - On top of the basic IaaS service, you also get some Application Management Services from SAP, that make this more like PaaS, but SAP don't refer to it as PaaS. HEC could be in a SAP datacentre, in a public cloud hyperscaler datacentre, or in some other third party co-lo provider datacentre that offers the required services for HEC. HEC instances can be customised.
• S/4HANA on-premises/hosted—The classic on-premises model which might not be aaS at all, but equally could be deployed as VMs/bare metal and storage out of a hyperscaler provider or in another public or private cloud with the point being this is “do what you want”. Actually the majority of SAP customers who are implementing S/4 are really using this model, not one of the SaaS or IaaS/PaaS models just described.

 For a more in-depth exploration of these options, this SAP blog describes the options in greater detail.

The key takeaway? If you want to run SAP in a Software as a Service Model in the cloud, you’ll have to throw away all (or most) your customisations. If you want to keep your customisations, you’ll need to adopt an Infrastructure as a Service model with at best some application management services laid over the top.

Issue #2: So if you have to run S/4 under an IaaS model in public cloud, what should you be thinking about?

• Be sure that the benefits you are relying on to justify your public cloud implementation will really accrue from a IaaS model. Don’t assume that all the benefits of the SaaS approach can be realised with an IaaS approach.
• Don’t forget that under IaaS you still have to think about how your landscape is architected, how you implement security, who manages your virtual machines and storage, who manages your operating systems, who manages S/4 itself. You also have to think about how you do backup and recovery and, of course, how high availability and disaster recovery can be achieved. While public cloud may give you a few more tools to cover these areas, it isn’t going to do all the work for you.
• When comparing with other approaches don’t miss those extra costs that are outside the VM and storage costs for public cloud. Specifically, consider these two things:  (1) Unless all users are connecting across the public internet, you’ll need the infrastructure required for private network links into the public cloud. Whatever it’s called (Azure ExpressRoute, AWS Direct Connect or Google Cloud Dedicated Interconnect), it adds cost and you will need it. (2)Try and think about how you are going to model egress fees (what public cloud providers charge for pulling data out of their cloud). This notoriously opaque part of the public cloud pricing model is hard to budget for and actively encourages customers to move more and more of their services into the public cloud whether it makes technical sense to or not. It’s not just about the movement of data between S/4 and users, but the possible costs of data moving through interfaces to other system and outputs or even the cost of data moving to other public cloud regions for DR purposes (the rules on what you are and aren’t charged for when moving data between regions/availability zones can be very esoteric). Don’t forget as well that egress fees will apply if a decision is made in the future to move out of public cloud.
• Consider data gravity. Applications coalesce the closest to the data they need to access. Where does this data reside? Where is the data that is feeding your SAP systems coming from? Does it make sense for those systems to be further away from their data sources? Think about latency. Whilst latency in public cloud is perfectly acceptable for a human interface, what about machine interfaces? Keep in mind that many SAP customers have actual production and logistics machine interfaces tied directly into their SAP instances that could rely on sub-second response times. As already noted, you will probably need network infrastructure at the “cloud end” of your SAP landscape, but you may also need additional network infrastructure and links at the “business end.” And this could also add costs and if physical links must be installed can significantly impact adoption timelines.
• Check what you are actually getting. For many larger SAP HANA instances (over 3TB) public cloud providers will actually deploy bare metal servers that don’t come with all the “bells and whistles” in terms of operational flexibility that their virtual machine offerings come with and costs are significantly higher.
• Make sure to get reserved pricing. You don’t want to risk the resources you need to run your business not being available!
• Ask for references. Whilst there are plenty of customers running test and development S/4 instances in the public cloud, for which the “peaky” utilisation patterns associated with test and development are well suited. You should also ask to speak with customers who are actually running their full productive instances in the public cloud. They are out there and hearing their war stories is important to help avoid common mistakes.
• Think about talent. How easy is it to attract and retain the talent required to implement? Operate and manage your SAP environment in the model you choose to adopt. Be clear about who’s responsible for what. In an IaaS model, your public cloud hyperscaler really isn’t going to care about anything SAP specific.

What is the key takeaway here? There’s a lot to think about when implementing S/4 under an IaaS model in the public cloud. Take the time to identify all the costs and pitfalls.

So what’s HPE’s point of view on all this?

At HPE, we believe in a hybrid cloud approach. Public cloud is one more tool in our “solution kit bag” and has its place, but in an increasingly data centric world, moving our applications away from the source of their data is not always the right answer. Where public cloud certainly makes sense is in the SaaS space, and that’s something we practice as well as preach (while HPE operate our own 50TB+ S/4HANA environment in a private cloud we also use SaaS offerings such as Salesforce, Workday, and SAP Ariba).

The full end-to-end management of a discrete application service can realise huge value for organisations. Where public cloud has to “work for its lunch” is in the IaaS space, our own calculations seem to show that unless you are moving enough to public cloud that you can actually close down your own datacentres, then the TCO for public cloud can be higher than on premises/private cloud. Yes, public cloud can bring advantages in terms of flexibility and automation that are harder to achieve “off-the-shelf” on premises and in private clouds, but this must be offset against the additional costs and lack of control that come with the public cloud model. We think this point of view is backed up not only by SAP’s own comments around license sales and pivot to “any-premises” but also by independent market research, including a recent Gartner report entitled "How to Select Your Optimal SAP HANA Systems Vendor" [3]. 

Of course, for customers that want the consumption model (meter-usage based as opposed to upfront fixed) and service wrappings of public cloud (but on premises or in a private cloud), HPE can offer HPE GreenLake for SAP HANA. This can be offered in a straight IaaS model, or by layering operational support services can be extended to a PaaS model. In addition we can offer much simpler consumption metrics than public cloud. So rather than thinking about all the VMs, all the storage, your private network costs and your egress charges, we can bring all this down to just one simple metric: how many gigabytes of memory are my SAP HANA instances consuming? Given that’s a strong measure of your business throughput and platform utilisation in HANA systems, it lets you map your IT costs much closer to your business needs.

So going back to my statement that I called out at the start of my post, the answer from HPE is this: We know you can, we aren’t sure you should. And if you don’t want to, we have a great alternative!

Learn why HPE is the #1 system vendor for SAP HANA

If you are planning to migrate to SAP HANA, this is a good place to start.

[1] Late breaking news: At the recent SAP Field Kick Off Meeting in Barcelona, SAP altered its message subtly from “cloud first” to “any premises." We think this further validates HPE’s hybrid approach. A SAP executive also stated that 70% of its licenses sold in 2019 were on-premises.

[2] SAP executives have publicly stated that the cloud edition of S/4HANA is of limited scope.

[3] How to Select Your Optimal SAP HANA Systems Vendor 

---

Meet Server Experts Blogger Duncan Edmonstone, Mission Critical Solutions Sales Specialist, HPE. Duncan is a 25-year technology industry veteran with experience in software engineering, customer presales and sales, including the last 13 years with HP and HPE. Duncan has been helping customers implement SAP infrastructure since 2001 and is now a Mission Critical Solutions Sales Specialist in the HPE UK&I geography

Server Experts
Hewlett Packard Enterprise

twitter.com/HPE_Servers
linkedin.com/showcase/hpe-servers-and-systems/
hpe.com/servers