Google vs Azure vs AWS Comparison. Part 4: What do first - S/4 or Cloud Transformation?

1????????This transformation is huge

With his essay series, the author wants to support customers facing one of their biggest technology transformations so far. It is about S/4-conversion of SAP landscapes on the one side. The way into the cloud on the other side. Each of those moves are already a big challenge as such. Both together then heap up “a big wave” which the staff in business and IT need to face (see Braun 2021 [I]).

Well, the picture above from the so called “bridge of glass” out of Netflix blockbuster “Squid Game” might be over-dramatized a bit. However, a wrong step in doing these ventures might get business in trouble. Whilst the reward for a successful pass is extraordinary. The enterprise is then positioned well and competitively with its IT for the next few decades. The doors are wide open to the new generation of cloud-native services like Big Data Processing, Artificial Intelligence (AI) and World-Class Security described in part 3.

Did the author say “decades”? Yes! R/3 as the predecessor of S/4 started in 1991 (SAP 2021 [III]) and is still the dominant release in the businesses with ECC 6.0 (Release Pack 8) at the times of writing. This software runs for three decades now; even the predecessor R/2 run already for 10-20 years in the companies. So, it is fair to assume that S/4 serves customers over the next generation.

Why is now the choice for the right Hyperscaler so important? True, SAP workloads in many cases are critical to enterprises. The modules contain FI with regulation-relevant information; production and logistics systems decide upon if the supply chains work or disrupt. An outage in these kinds of systems can stop production processes. Not only the backing technology is essential for your SAP success but also the service processes of the Cloud Providers. They need to keep the systems running and healthy 24x7. Hence, it is key for the customers to find the right Hyperscaler for their specific situation. Part 1 elaborated on some reflections which you might want to do; parts 2 and 3 support in doing a first comparison of the most important features.

1.1????????S/4 transformation – why progress is so slow

Figure 1: The evolution of SAP to S/4 (Roan 2020 [II])

S/4 is in the game since 2015 (Noyes 2015 [IV]). Why do customers adopt this new release so “slowly”? The author of this essay found various reasons within his relatively broad international customer base – which might not be fully representative – but however gives indication what is going on.

1.????The function gaps. Especially in the DACH-Region, which is Germany, Austria, and Switzerland we find a lot of big and medium-sized companies which are Champions in their industry. They evolved to world-class because SAP R/3 was the base system with which they could grow over the last decades. They developed a lot of customized functionality which differentiates them from other companies. “Unfortunately” for the migration – but “fortunately” for keeping their leadership over competition – S/4 brings a lot of simplification and standardization. The specifics are not supported any more. That is why some of the champions refrain from migration. Companies wait until function gaps become smaller with the releases of the S/4 roadmap.

2.????Business reorganization needs. Many clients designed their enterprises to some extent matching SAP functionality. When you look on how Financial Departments used to be organized, you find a lot of “SAP design” in it. The way creditors, debtors, closing, and treasury departments are formed reminds you of SAP software. Moreover, a closing process which used to take several days to weeks in an SAP-workflow determined how departments were organized. Now, with S/4 Finance (Simple Finance) the process is down to hours. You will need less people in your department – and they need to work in another way. However, the engineering of is a complex business redesign process. The skill to do these kinds of projects are very scarce in the companies and even in the market. Other processes like logistics or production look alike.

3.????The cost and availability of in-memory computing. The author accompanied customers who sought for a lift of their systems from R/3 to S/4. The cost of operations could easily be a multiple of the former cost just because customers need to churn their storage into memory. How expensive! The need to simplify the systems before transformation and archive old data is again a costly project which will bind bottleneck resources in the customers’ company. Often the project has then to be de-prioritized.

1.2????????Does the cloud make your dilemma smaller?

Indeed. You get much more flexibility to match the size of your systems to your demands over time. That is a big advantage of the cloud. Moreover, the availability to use virtual machines instead of bare metal makes your consumption cloudy. Ramping up and down cost drivers like CPU, memory and storage is easier as if you would sit with your own premises or HLI instances for several years.

The Disaster Recovery (DR) abilities of the big three cloud providers using two Regions go beyond the possibilities any on premises-datacenter could ever deliver. Many classical providers can only offer you “DR” using two datacenters which are quite near to each other, let us say 5-10 kilometers. That, however, is what Hyperscalers would “only” call high availability in two zones. When disaster strikes it will take down a whole Region, not only one Availability Zone. Fancy stuff? Then you might want to remember last years’ winter storm in Texas who took a whole region down because of Energy shortage. Datacenters were off for days. When? In 2021! Where? In the US, one of the most civilized countries in the world.

Figure 2: SAP DR capabilities in the cloud – scale up scenario (Morgan 2019 [VII])

Figure 3: SAP DR capabilities in the cloud – scale out scenario (Morgan 2019 [VII])

1.3????????Use cases for moves from private R/3 to S/4 in the cloud

Figure 4: Use cases – How customers chose to move (M. Braun 2022)

In this section, the author elaborates on five different move scenarios customers use for their double transformation.

1.????Big Bank. The big bank described in this example is an industry leader for the usage of SAP-banking functionality. Therefore, the customer chose to start with a pilot on one SAP system to test out S/4. The complexity of the system was in the middle of the spectrum. The bank still feels to be bound on private cloud for the test itself. This is because banking is strongly regulated. There are still concerns in the industry, that compliance might be a risk because of evolving legislation. The customer chose a so-called brownfield-approach because they wanted to take essential functionality to the S/4 system not being in the standard for now. They evaluate different public (and private) cloud providers for the future setup as they practice with S/4. The old systems are then migrated to S/4 on prem before moving the ready systems to the Cloud. The author perceives that in the Finance industry several customers have an affinity to Google Cloud. This might be because the banks used to invest heavily in microservices architectures over the past years using different providers and Open Source. This is Googles home turf.

2.????Retailer. A world-class retailer preferred to wait with the relaunch of his S/4 project after the (2021) pandemic phase. He wanted to first decide on a public cloud provider for future SAP hosting and then move on. All Hyperscalers were evaluated in his investigation. He opted for AWS. The customer having quite a few R/3 system is working with greenfield and bluefield approach system by system. The new target S/4-systems are built up directly in the public cloud while the R/3 legacy remains on the former private cloud.

3.????Mid-sized pharma distributor. The company of this example took quite a few company acquisitions over the last months. Instead of integrating the companies in the legacy SAP-world, the transformation was directly done via greenfield approach into target S/4 systems on Azure.

4.????Life-science & pharmaceuticals company. The company is a heavy user of several R/3 systems on private cloud. In pharmaceutical industry, so-called GxP compliance (what is good practice guidelines) is an important prerequisite. Hence, in the selection process which focused on AWS and Azure, the operations model of the Hyperscalers and its partners needed to take this into account. The customer selected one major SAP-system to be the target of the S/4-pilot which runs on private cloud at the beginning. Again, the complexity of the pilot system was medium. After successful migration, the selection of the preferred cloud goes on with sandboxes in the Non-SAP application space as well as in the SAP area. The final decision will then be taken after several months. The migration strategy for now is to do the S/4 uplift in situ on private cloud before then moving further to public cloud. One reason for that again being the brownfield approach (bluefield in some areas), which takes over quite some functionality from the legacy world in the IT-landscape of tomorrow.

5.????Chemical company. The chemical company is the last example and the one which went through a Hyperscaler evaluation first, leaving the systems as they are on private cloud. The evaluation concluded in AWS – the granularity of services in the legacy (especially for Non-SAP) being one reason for that among others. The customer then immediately started the Public Cloud journey with his R/3-systems. During this step, an upgrade to HanaDB was done in some cases to get better prepared for a future S/4-move. The time until then is used to skill the staff in the new technologies. The operational model of the Hyperscaler is much more standardized (and thus stringent) than the model the private cloud provider used.

1.4????????Conclusion on move strategies

Some customers use the way of piloting S/4-systems in their old private or on premises world, use the time to skill up the staff especially on the business side and do a cloud evaluation. After this decision is done, S/4 is transferred to the Hyperscaler space. IT staff then gets used to new Hyperscaler operations.

Few customers move their R/3-systems first to Hyperscaler datacenter after their evaluation. In some cases, a heterogeneous migration from any database to HanaDB is done. This however does not change the typical usage of SAP-systems. Only the operations of the database changes slightly. The IT-team can focus on skilling up on Hyperscaler operations, while busines still runs on the old R/3 world. The second step is to start S/4 pilots on public cloud whilst preparing business staff to work in the S/4-process-world.

Only few customers dare go “all in” and do a one-step move from R/3 on-premises to S/4 in the cloud. Usually, this way is bound to a greenfield approach. That means no complex legacy functionality – mostly coded in ABAP - is transferred to the new world. For the business and IT-staff this way is challenging. Business is running on new processes compared to old R/3 systems. IT is switching to Cloud operations at the same time.

Is there one “golden way”? No! The migration path depends on the preferences and the legacy of the customer. The more brownfield character the move has (that means the customer needs to take over old functionality in his new systems) the more de-coupled the moves should be.

2????????Comparison – how Hyperscalers are doing the SAP space

The three Hyperscalers have their own specific methodology to migrate and operate SAP workload into the Cloud. All of them work closely with SAP which support the offered solutions by certification. That means that the offerings are proof-stamped, and customers can rely on general reliability of SAP workloads in the cloud without any concern. The following sections will elaborate on all the three suppliers highlighting briefly on current technical boundaries, methodologies, and partnering approach.

2.1????????SAP on AWS

Figure 5: SAP Business Technology Platform by AWS (Knoeller 2021 [VIII])

AWS provides specifically for SAP Workloads the SAP Business Integration Technology Platform (BTP). It provides a lot of integration work necessary to link SAP workloads hosted on other platform like SAP HEC or on premises datacenters to AWS. Moreover, it gives an environment for SAP workload on AWS which integrates well with basic services like S3 blob storage, SNS, SWF and SQS (also compare part 2 of this essay series). Further tools used for document-based workflow integration (XML, IDocs) are AWS Lambda (serverless functions) and AWS Glue (ETL) help to individualize workflows. This toolset makes various hybrid scenarios easier to use.

Furthermore, data processing and Big Data Analysis is supported be the tools Kinesis (batch and stream data processing), EMR (Hadoop Cluster for data processing) and Redshift for Data Warehousing.

AWS typically works with partners to migrate and operate SAP on AWS. The partners use the data and VM migration techniques and tools introduced in part 2 of this essay series. AWS does not sell SAP licenses itself but works with resellers. Databases are licensed based on an bring your own license (BYOL) model.

The VMs currently supported by AWS go up to 3.904 GB memory with 128 vCPU (X1e.32 xlarge) and a more specific machine with 448 vCPU and 12 TB (u-12tb1.112xlarge). The bare metal support goes up to 24 TB for horizontal scale (u-24tb1.metal, 448 vCPU) for OLTP and 18 TB (u-18tb1.metal, 448 vCPU) for OLAP respectively. SAP S/4 supports scaling up to 4 nodes of 12 TB whereas classical OLAP scales horizontally up to 100 TB (AWS 2022 [IX]).

According to the experiences of the author, AWS satisfied all typical scenarios to migrate and run SAP workload. Most customers use a service partner not only for migration but also to help orchestrate on-premises and cloud operations.

2.2????????SAP on Azure

In Part 1 of this series, the author already elaborated on the close relationship between Microsoft and SAP. An example was that Microsoft itself conducted one of the early and most mighty S/4 transformations itself. The companies developed a differentiated methodology set for joint customers. Besides homogeneous and heterogeneous migration types, the Software Provisioning Manager (SWPM), Database Migration Option (DMO) of SAP Software Update Manager (SUM) using R3load are in the center of the methodologies and SAP toolset (Morgan 2019 [VI]).

Figure 6: Horizontal vs vertical migration using SAP Azure (Morgan 2019 [VII])

The vertical migration approach moves application for application over all production stages like Sandbox, Dev, Test and then Production. The horizontal approach migrates stage for stage. It depends on the customer preferences influenced by complexity which approach will be most suitable. Another taxonomy used for migration is a classification in Netweaver-based and Non-Netweaver-based applications.

The close cooperation between Microsoft and SAP reflects also in a tightly coupled tool integration of Office-products into the SAP Suite. Recently, Teams was merged into the setup (Microsoft 2021, [XI]). Azure offers Enhanced Monitoring Extensions for SAP and Diagnostics Extensions which plug into the Azure Monitor. With that, operations of SAP workload is well supported.

Azure offers a maximum size of 24 TB per Hana Large Instance (HLI) for OLTP and OLAP (S896, 896 vCPU). Additionally, a model for OLTP with 960vCPU and 20 TB memory is available (S960m) (Microsoft 2021 [XII]).

Up to now, the author made the experience, that any reasonable SAP use case can be handled with no restrictions in the Azure Cloud. Both, migration and operation support is best done with a partner.

2.3????????SAP on Google Cloud

Figure 7: SAP by Google Cloud governance model (Google 2022 [XIII])

Google’s affinity to Open-Source and its flagship services like Machine Learning (ML) and BigQuery form the key value driver for running SAP on GcP (Google 2022 [XIII]). The migrations as such are conducted by partners. In that point, there is no differentiation between the three Hyperscalers.

GCP offers virtual machines with memory up to 12 GB for OLAP and OLTP workloads (m2-ultramem-416, 416 vCPU, 11.776 GB) – matching the sizes of its competitors. The bare metal solutions go up to 24 TB nodes (o2-ultramem-896-metal, 896 vCPU, Google 2022 [XVI]). Concerning the scale-out capabilities for OLAP-workload the author could not find the current limits but will add this at his place as soon as information is available.

Looking into the overall setup, Google is the “latest joiner” in the SAP workload space among the three Hyperscalers. However, with the intense cooperation started between Google and SAP we surely will witness a fast catch up ([XVII]).

3????????Summary

The author gave an overview of possible move paths in passing the bridge from legacy SAP towards S/4 and move from private to public cloud. We saw various experiences of customers who went via greenfield, bluefield and brownfield migrations. A smart strategy is essential to not threaten stability of business and IT operations by overloading the employees of the enterprises.

We then investigated the methodologies and infrastructure options provided by the Hyperscalers. In a summary all three Hyperscaler provide similar options. Azure and AWS are the mature market player for SAP operations. Google the challenger, coming up strongly in the last months.

Figure 8: Comparison Hyperscalers on SAP Operations (M. Braun 2022)

With that the author finished his series of four essays about SAPonAzure, SAPonAWS, and SAPonGCP. He is happy to read your comments and hints.

About the author:

Dr. Marc Braun works as Vice President Service Delivery Management at T-Systems since 2009. He helps customers to migrate and run SAP workloads on “their” right cloud. Most recently, combining some of the moves with the customers’ S/4 transformation. Variants of SAP-Workloads on Azure, AWS, HEC and more and more also Google combined with private hybrids are building a really multi cloud scenario. Marc achieved Professional Architect certifications of AWS, Google, and Azure as well as SAP certifications.

Marc earned his PhD in 1999 with a research on Component Business Architectures based on Microsoft versus SAP for small to medium sized enterprises (SME). In his thesis he elaborated rule-based structures (algorithms) to match the disperse requirements of SMEs with adequate software functions.

4????????Annotations

I.????????Marc Braun 2021, How big is that wave? Customer Success - Public Cloud goes hand in hand with S/4 Transformation https://www.dhirubhai.net/pulse/how-big-ist-wave-marc-braun-dr-/ [2022.01.11]

II.??????Alexander Roan, SAP HANA and S/4HANA – a simple guide, https://blogs.sap.com/2020/06/04/sap-hana-and-s-4-hana-a-simple-guide/ [2022.01.11]

III.?????SAP 2021, Die ?ra SAP R/3, Die ?ra SAP R/3, https://www.sap.com/germany/about/company/history/1991-2000.html [2022.01.11]

IV.?????Katherine Noyes 2015, SAP unwraps a new enterprise suite based on Hana, https://www.pcworld.com/article/431658/sap-unwraps-a-new-enterprise-suite-based-on-hana.html [2022.01.11]

V.??????Google Retail 2022, Carrefour Belgium: Driving a seamless digital experience with SAP on Google Cloud, https://cloud.google.com/blog/products/sap-google-cloud/carrefour-belgium-leading-in-retail-digital-transformation?utm_source=linkedin&utm_medium=unpaidsoc&utm_campaign=fy22q1-googlecloud-blog-enterprise_customer-infeed-no-brand-global&utm_content=carrefour-sap-blog&utm_term=-&linkId=8022603 [2022.01.11]

VI.?????Daniel Holz 2021, https://cloud.google.com/blog/topics/retail/3-german-retailers-modernizing-with-sap-on-google-cloud [2022.01.11]

VII.???Nick Morgan and others, Birmingham 2019, SAP on Azure Implementation Guide.

VIII.??Arne Knoeller 2021, AWS for SAP, Integrating SAP Systems with AWS Services using SAP Business Technology Platform, https://aws.amazon.com/de/blogs/awsforsap/integrating-sap-systems-with-aws-services-using-sap-business-technology-platform/ [2022.01.11]

IX.?????Amazon EC2 Instance Types for SAP, https://aws.amazon.com/de/sap/instance-types/ [2022.01.11]

X.??????AWS 2022, SAP HANA on AWS, https://aws.amazon.com/de/sap/solutions/saphana/ [2022.01.11]

XI.?????Microsoft 2021, SAP and Microsoft expand partnership and integrate Microsoft Teams across solutions, https://news.microsoft.com/2021/01/22/sap-and-microsoft-expand-partnership-and-integrate-microsoft-teams-across-solutions/ [2022.01.11]

XII.???Microsoft 2022, https://docs.microsoft.com/de-de/azure/virtual-machines/workloads/sap/hana-available-skus [2022.01.11]

XIII.??Google 2022, Overview of SAP on Google Cloud, https://cloud.google.com/solutions/sap/docs/overview-of-sap-on-google-cloud [2022.01.11]

XIV.??Google 2022, SAP on Google Cloud, https://cloud.google.com/solutions/sap [2022.01.11]

XV.???Google 2019, https://cloud.google.com/blog/products/sap-google-cloud/announcing-the-general-availability-of-6-and-12tb-vms-for-sap-hana-instances-on-gcp [2022.01.11]

XVI.??Google 2022, https://cloud.google.com/solutions/sap/docs/certifications-sap-hana [2022.01.11]

XVII. SAP 2021, Google Cloud and SAP Partner to Accelerate Business Transformations in the Cloud, https://news.sap.com/2021/07/google-cloud-and-sap-accelerate-business-transformations-cloud/ [2022.01.11]