AWS and Google Cloud Versus SAP Cloud with HTTP 2.0

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

AWS and Google Cloud are distinct from SAP Cloud in many ways.
This article explains the differences regarding HTTP 2.0.

Introduction

SAP Cloud attempts to appear competitive, but under the covers, the SAP Cloud is far behind AWS and GCP. In this article, we will focus on HTTP 2.0.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Why Does SAP Cloud Not Yet Support HTTP 2.0?

One of the very bizarre aspects of SAP Cloud that is another indicator as to SAP’s lack of investment is the fact that SAP Cloud does not, as of this publication, support HTTP 2.0. AWS, GCP, and Azure all support HTTP 2.0. The newer protocol (released 2015) supports multiplexed requests across a single connection. Instead of buffering requests and responses, it handles them in a streaming fashion. HTTP 2.0 reduces latency and increases performance.

The SAP Cloud network analysis shows HTTP 1.0. (See under protocol column).

The Google Cloud network analysis shows HTTP 2.0. (See under protocol column).

HTTP 2.0’s multiplexing and concurrency, dependency streaming, header compression, and server push can decrease web resource load time compared to HTTP 1.1. Furthermore, HTTP 1.1 is more secure than HTTP 2.0. This means if SAP Cloud is connected to AWS, the connection from SAP Cloud to AWS reduces the security of AWS.

Notice that even Google Search, which only transmits search information between a local computer and Google, also has HTTP 2.0.

SAP Cloud and Heroku (a PaaS) reduce the overall design’s security as they both communicate to AWS or Google Cloud using HTTP 1.1.

Strange Missing Things with SAP Cloud

SAP could add HTTP 1.1 very easily, but they have not seen fit to do so. The reason is likely that SAP Cloud is little used. So there is not much point. In a discussion on this topic, SAP resource proposed that SAP Cloud acquired protocols from an acquisition of PLAT.ONE. This is a deceptive statement that was designed to trick anyone listening. First, you don’t need to acquire a company to “use HTTP2.0.” HTTP 2.0 is an open standard developed by the ITEF. This would be like saying you acquired the ability to “use HTML” from a vendor you purchased. People are behaving as if SAP Cloud is real and just “missing a few things.” SAP Cloud is not functional. This leaves SAP resources in the position of having to make excuses for it, and in many cases making false statements about SAP Cloud.

But the HTTP 1.1 issue versus 2.0 is small in the overall scheme of things.

Denis Myagkov correctly points this out:

“The HTTP version is not the problem. It actually depends on the server settings. Today most common approach is to hide all micro-services behind a ‘reverse proxy’ like Nginx. To add HTTP/2 support to Nginx I just need to add 5 letters.

The real problem is that SAP cloud has no tool comparable to AWS VPC.

A Virtual Private Cloud (VPC) lets you provision logically isolated resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

For example, you can create a public-facing subnet for your web servers that has access to the Internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to your instances in each subnet.

More importantly, you can create a Hardware Virtual Private Network (VPN) connection between your corporate data center and your VPC to leverage public cloud as an extension of your corporate data center.

SAP Cloud has no concept of a VPC. This makes it impossible to deploy production-grade enterprise workloads on SAP Cloud and by extension, refactoring any non-trivial ABAP code to run on SAP Cloud. Without VPC, for instance, there’s no way to apply IAM (Identity Access Management) policy to the endpoints of your own cloud estate. This is both a security and an operations nightmare.

And this problem is HUGE! This by itself makes SAP Cloud useless for anything more intricate than ‘Hello World’ application. There also no analogs of AWS IAM, however in AWS permission management is a core component. So in SAP Cloud any junior developer will be able to devastate all solution in production.”

The Limitations of SAP Cloud

To list the limitations with the SAP Cloud would be a chapter on its own. However, a lack of VPC capabilities is not the end of the missing items. SAP Cloud lacks either a load balancer and reverses proxy in addition to VPC. As soon as there is no VPC, the security argument is lost. Is this a solution that is ready for anyone to use? The lack of documentation or usability of the SAP Cloud indicates that the SAP Cloud sees minimal usage.

We were on a project where an SAP consulting partner was using the SAP Cloud. Using AWS or Google Cloud or Azure was not even discussed.

Why?

Because the consulting partner only recommended using SAP solutions. There was not any discussion of any competition. It was the SAP Cloud just because of the relationship between the consulting partner and SAP. We see this all the time, where the client’s interests are entirely secondary to choosing whatever SAP happens to offer.

The Latency Issues with SAP Cloud

In addition to massive limitations, things not working, and incredible latency in using the SAP Cloud, it also comes with significant liabilities. One liability is that the SAP Cloud Platform is, unlike AWS or Google Cloud, not an open environment. However, you can’t tell this from reading what SAP has to say about the SAP Cloud. Those reading this book probably have had the SAP Cloud/SAP Cloud Platform promoted to them at some point. There are essential features of this SAP offering.

Observe how SAP tries to propose the converse in this quote.

“SAP Cloud Platform is an open platform-as-a-service (PaaS) that delivers in-memory capabilities, core platform services, and unique microservices for building and extending intelligent, mobile-enabled cloud applications. The platform is designed to accelerate digital transformation by helping you quickly, easily, and economically develop the exact application you need – without investing in on-premise infrastructure. Based on open standards, SAP Cloud Platform offers complete flexibility and control (emphasis added) over your choice of clouds, frameworks, and applications.”