Startseite » SAP Cloud Platform: The Good And The Ugly
Cloud Scp Sap Cloud Platform Kubernetes [shutterstock: 1722461929, Blackboard]
[shutterstock: 1722461929, Blackboard]
Blog Cloud

SAP Cloud Platform: The Good And The Ugly

Life can be very simple: SAP provides a development environment based on which applications are built. As all is running in the cloud, the full product lifecycle is covered, from the development to app store, sales, install, update and decommissioning of the product. Does SCP provide that? Yes, but…

Building a cloud solution is very expensive due to the inherent complexity. However, once it is available, the cost of adding a new customer is low. This has multiple obvious consequences:

  1. The initial investment in becoming a cloud company is very high.
  2. The margin correlates directly with the number of customers.
  3. The chosen cloud architecture has a huge impact on the initial investment cost and the per-customer costs. It is like a seesaw – if one is high, the other is low.

The other point to keep in mind when looking at the history of SAP Cloud Platform is the year in which respective managers were responsible for it and the competitive situation at that time.

IaaS: Cloud at server level

Seven years ago, there was no cloud. You could rent a server, install your software, and that was about it. In such an environment, the idea to rent out SAP servers makes total sense. SAP expands existing IT centers, buys servers, installs SAP software and leases them to customers. SAP knows how to host SAP software better than anybody else, after all. Customers benefit financially as well. Instead of every customer having a private SAP team operating their systems, a single SAP cloud team manages all customer systems, which saves costs. This approach is the Neo environment in SAP Cloud Platform.

Outsourcing deals were very popular in the 2000s but fell short from a financial point of view. The customers had to pay more in the end, were less flexible, and the outsourcing company did not make enough profit. If every customer would have been a clone of the same system, then this method would have worked through scaling effects. However, as each customer had their own individual customizing, the cost savings were nowhere near the desired range.

Most of the huge SAP cloud investments went to infrastructure. As said before, for a high margin, a huge number of customers is necessary. However, customers sign up only if the price is attractive enough. This is simple arithmetic, valid for all cloud vendors, with one exception: A cloud provider limiting themselves to just the SAP market doesn’t have the slightest chance of competing with other providers.

SAP spent all that money for nothing. At least we learned something:

  1. We can never compete with the hardware costs of hyperscalers (Amazon AWS, Microsoft Azure, Google GCP,…).
  2. We need to build software in a cloud-native way to keep a lid on the costs. Installing the software once per customer is way too expensive.

PaaS: Cloud at service level

Fast forward to the year 2016. How about the following idea: All the hyperscalers have their own services and ways to administrate them. SAP adds a layer on top and thus everybody who builds software based on these APIs and services can run their applications everywhere. SAP provides generic interfaces to the cloud. Brilliant!

Cloud Foundry was chosen as the runtime for cloud-native programming. It allows users to write software, package it, and deploy the code in a cloud-native way. One limitation is the maximum program size, but cloud-native means microservice-orientated architectures, anyway. Next, we must define a list of services:

  • Most important is an authentication and authorization service. All other services will derive the permissions of the connected user from this service.
  • Then database-like services: SAP Hana is an obvious choice but also too expensive to be used for everything. An open source database as alternative and MongoDB as NoSQL database should be available as well.
  • For real-time event exchange, RabbitMQ might be a good idea.
  • Runtimes for the most important programming languages: Node, Java, Abap.
  • A routing service to connect each microservice with the other required programs and services in a secure way.
  • Fiori UI programming services.

This is the SCP Cloud Foundry environment, and its first downsides can be seen immediately. While some services will be used by all customers, most of the services exist just-in-case. If a required service is missing, customers cannot add it themselves. Hence this platform has the natural tendency to grow by services which translates into massive costs to keep all up and running.

Surprise, surprise, one year ago the add-on services in SCP got discontinued. They didn’t have enough users to warrant the high inherent costs.

In summary, the Cloud Foundry environment of SCP is too rigid, too inflexible. Meanwhile, hyperscalers provide Kubernetes as container operating and administration environment.

What is left of the idea of SAP providing the generic interfaces to all hyperscaler clouds?

  • A generic API across all vendors: Done, the hyperscalers provide it themselves via Kubernetes. No need for SCP.
  • Cloud-native software development: Done, containers were invented for the hyperscalers and have all the advantages and none of the downsides of Cloud Foundry.
  • Microservices: With containers, all kinds of services can be provided, from a tiny microservice to a huge Hana database. No limitations to just microservices.
  • Routing service: With containers that are part of the infrastructure, normal network rules are used. No app router with its overhead is needed.
  • Customer-specific services: Sure, the customer can deploy this service as a container themselves, in case it is not yet provided by the cloud provider or one of their partners.

From this point of view, the entire Could Foundry investment of SAP was for nothing. But at least we learned something: Containers rule.

Kubernetes: Cloud at container level

The logical continuation is to add a Kubernetes environment to SCP.

Actually no, it is not. Why would a customer favor SCP’s Kubernetes over hyperscalers’ Kubernetes? There are a few minor points, but none are compelling. While using Kubernetes is the right thing to do for customers, I fail to see an advantage to using SAP’s Kubernetes.

SAP partners and customers are doing the smart thing:

  • One company, Linke IT, makes all AWS services accessible via Abap, e.g. a few lines of Abap code and the file is read from the AWS S3 storage.
  • My customers place the raw data in the Microsoft Azure Data Lake storage at virtually no costs and are using Hana Smart Data Integration to load the interesting data into SAP BW.
  • A few SAP partners have solutions to build Fiori UIs via graphical editors.
  • SAP providing infrastructure-services make sense as well, primarily SAP Hana Cloud and SAP Data Warehouse Cloud.

What is the revenue potential of that? SAP’s plan was to rule the cloud world, and now I’m suggesting that providing a few add-on services is a financially equal solution?

Revenue potential for SCP services

To explain what I mean, I would like to look at the Hana Data Warehouse Cloud product and compare it to another vendor: Snowflake Inc.

This company has a market capitalization of 70bn USD. In comparison, at a stock price of 130 euros, the market cap of SAP is 160bn euros. Technically speaking, Snowflake is a poor man’s SAP Data Warehouse. It lacks 80 percent of the features Hana DWH Cloud provides, but it does have three properties SAP is missing:

  • Pay per use: Customers are billed for consumed storage and compute time, not for service availability.
  • Low price: The overall price is about 1/10th of SAP’s.
  • Entire market: Snowflake is a solution for everybody, not artificially limited to SAP customers.

While this is no direct answer to the revenue opportunity, it is an indication of how much potential the market sees in that single service offering alone. Would SAP have had the chance to do the same? Easily! There were enough suggestions on how to make that happen. Would it have worked? Nobody can tell.

Going beyond SCP

Most other recent initiatives, primarily the heavily promoted Business Application Studio, are solutions with low customer adoption rates. Even if it would do everything it promises perfectly, why would a customer use the Cloud Application Programming Model (CAP-M) when the same can be done with containers? Granted, customers who started with Neo and migrated all their code to Cloud Foundry might migrate again to the CAP-Model until SAP suggests using the new Kubernetes runtime for everything. However, this approach is neither a huge business opportunity nor the source of customer excitement.

Question: Which of the SAP products SAP Hana Cloud, SAP DWH Cloud, SAP Cloud Analytics, Successfactors, Hybris, etc. are built with SCP at their core?

As a customer, I would like SCP to provide key services and help customers build containers for hyperscaler clouds. Would this qualify as a defeat? Probably. Would it allow SAP to finally increase its margin and customer satisfaction? Yes! No more investor press conferences with the repeated message of “We need to invest in cloud in order to bring up the margin in the future.”

Quite frankly, the real value of the cloud business is not SAP Cloud Platform, it is the various SAP cloud applications like S/4 Cloud, Successfactors, etc. SAP is busy enough fending off the attacks of Salesforce, Workday, and others coming from the large enterprise side and Odoo-like companies taking the SME market.

SAP’s plan for SCP – to provide a beautiful development environment, get partners on board, provide an app store, and then take the world by storm – has one single point of failure: There are easier and cheaper ways provided by hyperscalers.

Source:
rtdi.io

About the author

Werner Daehn, rtdi.io

Werner Daehn, former SAP employee, is an expert on big data and smart data integration. He is also the CEO of rtdi.io.

4 Comments

Click here to post a comment

  • Enjoyed resign this outsider view of SAP cloud platform journey over the last decade. Insightful. Nicely written. Thanks You.

  • An interesting article and I agree entirely that trying to use SCP for completely bespoke, customer facing applications is probably the wrong way to go. SAP have promoted this, but the real focus at the recent TechEd seemed to be on using the platform to extend the SAP Suite (or maybe as that’s my area of focus it’s where I invested my time).

    For me, some of the key capabilities that the platform offers and where the real value of SCP will come from is exploiting the joined up business services to extend the SAP suite via Machine Learning, AI, automation and that nirvana of a single, consistent UX.

  • Great article! Well written… with an open minded outlook whats next.

    Hopefully there is more to come.

Social Media

ad_banner
Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

Für den Versand unserer Newsletter nutzen wir rapidmail. Mit Ihrer Anmeldung stimmen Sie zu, dass die eingegebenen Daten an rapidmail übermittelt werden. Beachten Sie bitte deren AGB und Datenschutzbestimmungen .

Our Authors
Anzeige