Cloud

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

In HPE we have been speaking to customers recently about models for deployment of SAP HANA and SAP S/4HANA. Many customers we speak to are considering deploying these workloads in the public cloud. At the same time, the strong message from SAP is to 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. While the public cloud clearly has a place in the SAP architect’s kit bag, we believe that SAP architects should not only consider whether or not they can run S/4 in the public cloud, but also whether they should.

The real challenge is that to fully realize the business benefits of moving into the public cloud customers need to adopt a SaaS model, but that can be hard to do for many SAP customers. To explore this challenge in more detail, we recommend that you (1) fully understand the different approaches to implementing S4 in the public cloud and (2) consider some key aspects as you plan how and where to host your S/4 HANA landscape:

#1 Understand all the approaches to implement S/4 in the cloud: For those looking to move to S/4,  the many different approaches to implementing S/4 in the cloud might create confusion and customers can be left not understanding what they are really getting. Below are 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 customers can buy from SAP only. This offering is usually hosted in SAP data centers in-country or in-region, or in a third-party data center if an SAP data center is not available near the customer. The actual data center ownership probably doesn’t matter, as you would be buying a software service from SAP. The important point to note about this option is that you don’t get to customize 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 customizations, this option is likely a good fit only for new adopters of S/4, and even then customizations 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. This option does allow some limited customization via SCP, but if you have your own custom ABAP or Java code that you want to retain in some form, you won’t be able to, so again this approach is a good fit only 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 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 makes this more like PaaS, but SAP doesn’t refer to it like PaaS. HEC could be in a SAP data center, in a public cloud hyperscaler data center, or in some other third party co-lo provider data center that offers the required services for HEC. HEC instances can be customized.
  • S/4HANA on-premises/hosted—This is the classic on-premises model which might not be aaS at all, but could equally be deployed as VMs/bare metal and storage out of a hyperscaler provider or in another public or private cloud –in short, this is the model that offers the most flexibility. The majority of SAP customers who are implementing S/4 are using this model, not one of the SaaS or IaaS/PaaS models described above.

For a more in-depth exploration of these options, this SAP blog describes them 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 of your customizations. If you want to keep your customizations, you’ll need to adopt an Infrastructure as a Service model with at best some application management services laid over the top.

#2: Consider key aspects of running S/4 under an IaaS model in public cloud

Below are of the main aspects we recommend you evaluate prior to making your implementation decision:

  • Be sure that the benefits you are relying on to justify your public cloud implementation will really accrue from an IaaS model. Don’t assume that all the benefits of the SaaS approach can be realized 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 and 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 the public cloud option may give you a few more tools to cover these areas, it isn’t going to do all the work for you.
  • When comparing versus other approaches don’t miss those extra costs that are outside the VM and storage  costs for public cloud:
      • 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.
      • Consider how you are going to model egress fees, meaning the fees 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 systems and outputs or even the cost of data moving to other public cloud regions for Disaster Recovery purposes. The rules on what you are and aren’t charged for when moving data between regions/availability zones can be very cryptic and difficult to understand. 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.” This could also add costs, and if physical links must be installed it 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” utilization patterns associated with test and development are well suited, you should also ask to speak with customers who are running their full productive instances in the public cloud. Hearing their experiences 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 roles and responsibilities. In an IaaS model, your public cloud hyperscaler really isn’t going to care about anything SAP specific.

The key takeaway? 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 potential 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 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. At HPE we operate our own 50TB+ S/4HANA environment in a private cloud and at the same time we use SaaS offerings such as Salesforce, Workday, and SAP Ariba. We recommend a hybrid approach, where the deployment model is chosen according to the workload requirements.

The end-to-end management of a discrete application service can realize huge value for organizations, however where the value of public cloud is more challenging to demonstrate is the IaaS space. Our own calculations show that unless you are moving enough to public cloud that you can actually close down your own data centers, the TCO for public cloud can be higher than keeping the workloads on premises or deploying in a private cloud. While we agree that the 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, this must be offset against the additional costs and lack of control that come with this 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. A recent Gartner report[3] stated that “Although approximately 80% of SAP HANA deployments continue to be on-premises, an increasing proportion is off-premises.”

For customers that want a consumption model that is meter-usage based as opposed to upfront fixed, as well as the  service wrappings of public cloud (but deploying on premises or in a private cloud), HPE offers HPE GreenLake for SAP HANA. This can be delivered in a straight IaaS model, or by layering operational support services, it 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 utilization in HANA systems, it lets you map your IT costs much closer to your business needs.

So going back to the initial question posed in the article, SAP S/4 HANA on public cloud: It can be done, but should it be done? the answer from HPE is, we know you can, we aren’t sure you should. And if after carefully weighing all the benefits and costs you decide against a public cloud deployment, we have a great alternative.

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

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

[2] And 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 https://www.hpe.com/us/en/resources/solutions/gartner-sap-hana-servers.html?parentPage=/us/en/solutions/sap-hana

Leave a Comment