How to Understand the Differences Between Cloud and On Premises

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

Executive Summary

Cloud is critically different from on-premises in the ways described in this article.
We draw distinctions between AWS/GCP and SAP/Oracle.

Introduction

While SAP and Oracle can’t stop talking about the cloud, what tends to be little discussed is that historically SAP and Oracle environments have built their entire business model based upon on-premises. They have been two of the most successful software vendors under the on-premises model. However, AWS, Google Cloud Platform, or GCP is the official name for the Google cloud offering (but we will refer to it as “Google Cloud” for this book). Azure and others are changing things very rapidly. This allows for software testing in a way that was not possible just a few years ago. AWS has the lead over all other cloud entities regarding size and growth. However, AWS’s lead is now shrinking, at least in usage like the following graphic displays.

This graphic is consistent with other analyses that Azure is even hotter on AWS’s tail than Google Cloud.

Notice the change from 2017 to 2018.

Under the multicloud model, companies don’t have to choose one cloud provider but instead use multiple cloud providers, picking and choosing the services from each that best fit their needs. Using one cloud versus another can also come down to more than just the service’s capabilities or its pricing.

Similarities Between AWS and Google Cloud

AWS and Google Cloud have many similarities, but they are also born from different backgrounds. As observed by Lynn Langit, an AWS Hero and trainer/educator, Google Cloud is very developer focused, while AWS is a “DevOps” (a combination of development with operations) cloud. For example, many of Google Cloud’s services are a logical selection when the desire is for straightforward and more mature services than AWS. AWS, on the other hand, is the standard choice for the latest or most innovative services. Google Cloud has a strong orientation around releasing things that were developed to run Google. Still, in many cases, those services are not necessarily a good fit for the customers, which do not run at Google’s scale, which is, of course, most of the known solar system.

This industry is in a transition from a time when lock-in in IT environments was the norm (with SAP and Oracle being the best at it) to an opening of options and the ability to test in a small way before making a more significant commitment. Furthermore, like Heroku, other providers offer a far more complete PaaS service than AWS or Google Cloud. Use AWS or Google Cloud as the IaaS are preferred over by some developers and companies overusing AWS or Google Cloud for PaaS. Moreover, as we will cover in the book, that is just the beginning of the choices.

Leveraging Cloud Services

Leveraging cloud services is a very different model and way of thinking from leveraging on-premises hardware and software. One example of this is that the cloud has low access and testing overhead. One can start up an account with a cloud provider very quickly, and the primary limitation to using any cloud offering is knowledge, not the ability to gain access. This allows one to get hands-on experience in a way that was not possible under the on-premises model. This translates to there not being a reason to become an “Amazon shop” or a “Google shop” exclusively.

Furthermore, each of these providers is coming up with new things all the time, so one never knows what might come up or what service will be adjusted or repriced that can be leveraged. The benefit of including both in a book is that many things that can be said for AWS can often also be said about Google. There are differences between the two, such as how replication is allowed between the region, how the network was set up, pricing, and many more items. We will illuminate these differences throughout the book. However, AWS and Google Cloud are quite comparable in many ways.

It is difficult not to be impressed by AWS and Google Cloud. However, some of the things we write in this book can also be extended to Azure and other IaaS providers, although we will not cover Azure or these other providers in this book specifically concerning using their services. We discuss Azure as one part of the overall cloud market and as one of the “big three” hyperscale cloud providers. AWS, Google Cloud, and Azure are called “hyperscale” providers because of their enormous scale, based upon their extensive investments into infrastructure. Currently, these are the only three cloud providers discussed in these terms, and as we will explain, their CAPEX investments support this framing. However, others offer other differentiated services. They can also be good options depending upon the requirements. Moreover, as we will describe in the book, there are many more choices than merely among the predominantly IaaS focused providers. One of the most challenging features of leveraging the cloud is choosing the best combination of items that fit a particular company’s requirements.

The things we will discuss cannot be extended to either the SAP Cloud Platform or Oracle Cloud. This is because those offerings are so far behind the leaders of AWS, Google, Azure, and other true IaaS offerings. SAP and Oracle have huge installed bases. This installed base gives SAP and Oracle the ability to push those customers to their cloud offerings SAP Cloud or Oracle Cloud. Moreover, even with that factor, both the SAP Cloud and Oracle Cloud are still quite small in usage.

What are AWS and Google Cloud?

AWS and Google Cloud are frequently referred to as PaaS/IaaS. We use the terms SaaS, PaaS, and IaaS in the book. Also, we often refer to AWS and Google Cloud as IaaS. The problem is this is not accurate. We debated this point before publishing the book and picked up some good insight from Dan Woods(#1), an enterprise architect.

“I assume compute (server or serverless), storage and networking is IaaS. DB is at the very least PaaS. But look at their product list and it’s stacked with SaaS…literally littered with GUIs. Just because it’s not a CRM system doesn’t mean it doesn’t count. In response to your question, I’d call AWS an internet application platform provider. An unsurpassed one at that.”

A” stack” is a combination of software components that interoperate with one another. It is called a stack because the components are viewed as stacked on top of one another. Which components are provided to determine if the provider is a SaaS, PaaS, IaaS provider, or some combination of the three? The problem with defining AWS or Google Cloud as IaaS providers or IaaS and PaaS providers is that these service providers provide access to all of these components in the stack.

We have Heroku listed as a PaaS connecting to AWS or Google Cloud as an IaaS. However, now, as AWS and Google Cloud have so many services, they are vendors, but they don’t transfer a license. There is a lot of grey area here. AWS and Google Cloud offer a range of services. Internally, they organize teams around products, not layers like IaaS/PaaS/SaaS. Both AWS and Google Cloud offer SaaS, PaaS, and IaaS.

Furthermore, they also offer more than just access because they also offer unique products that they developed (Google BigTable, Google Spanner, AWS DynamoDB, AWS Redshift). They don’t transfer a license, but they do allow these products to be accessed. However, if we think of AWS’s data warehouse/data lake/analytics offering, we can observe the following services.

As shown above, AWS and Google Cloud provide the entire stack for data warehousing and analytics. The data can be imported into AWS and Google Cloud and never has to leave before being consumed by the user through QuickSight and Data Studio. This means that AWS and Google Cloud are providing the full stack.

This does not necessarily mean that the customer uses every component of AWS’s stack, but it says that, in this case, AWS can provide the full stack. This is why particularly as AWS and Google Cloud grow their services, they should be considered full-stack providers.

Distinctions that Are Poorly Covered in IT Media

The difference between a software vendor versus a service provider touches on a poorly covered story in the IT media. This story is that AWS and Google Cloud are fundamentally different from the SAP Cloud Platform and Oracle Cloud because neither AWS nor Google Cloud is a software vendor. AWS and Google Cloud are software and hardware service providers. That means they sell access to software and hardware; they do not transfer software ownership in return for income. Being a service provider rather than a software vendor has many advantages. These advantages include the following:

Open Source Promotion: The ability and the incentive to promote open-source (along with their own “homegrown” products). AWS and Google Cloud can do this because they do not care about license revenues. They do not benefit from license revenues (those revenues go to a software vendor, not AWS or Google Cloud).
Leveraging Open Source to Improve the Value Proposition: The lack of licensing costs and licensing restrictions with open source products makes AWS and Google Cloud’s value proposition even stronger. This licensing revenue or commercial software model with closed source software vendors uses their large income streams to promote their software over open-source alternatives. This has led to the overuse of commercial products and the corresponding underuse of open source.
The Incentive to Introduce their Own Products: AWS and Google Cloud have introduced many innovative and important software products. This software is mostly not open source, but AWS and Google Cloud treat their products as if they are open source. That is, they only charge for access to the service.
The Incentive to Introduce Products That Work: The short-term nature of on-premises software sales has promoted many salespeople to become “quick hit artists” and sell products that they know do not work (or at least they have little evidence that they do work). Many salespeople are attracted to on-premises software sales because they can “get paid upfront” as soon as the software sells. That is before the customer tests the software or gets value from the software. SAP customers are often filled with very marginal SAP applications that seemed like a good idea at the time. People who work for companies that still own licenses for SAP PLM, MDM, CRM, PP/DS, SNP, SRM, and many other previous SAP applications will know something about this. AWS and Google Cloud cannot introduce products that do not work because the customer can deactivate the service at any time. Therefore, ineffective services won’t be able to retain subscriptions.

Moreover, the differences don’t stop there; This is because, unlike SAP and Oracle, AWS and Google Cloud developed their capabilities by building something of significance internally before they ever began offering services to customers.

For AWS, this was the Amazon store.
For Google, this was the Google search engine.

And today, Amazon and Google operate the most extensive network of data centers in the world. Furthermore, they don’t manage these data centers; both companies have been primary innovators in the data center and data center networking space. They collectively changed the way that data centers are configured. Some people are fans of Azure; however, Microsoft has never been the innovator in the cloud. Azure is what it is today by copying AWS and Google Cloud. Microsoft struggled with the cloud until they began embracing and copying AWS and Google Cloud. Microsoft wanted something impossible for its cloud to be based on Windows. As long as Microsoft held to that self-centered doctrine, Azure would have never broken through.

The Scale of Service Providers

Many things make AWS and Google distinct from other companies in the enterprise software space. Google innovated in the scale of data centers by shunning proprietary hardware and software and building its infrastructure on open source and commodity hardware. However, this is a bit misleading, as the hardware components are a commodity, but both AWS and Google custom build their hardware. Google even produces their server power supplies. Furthermore, these two companies did not come up with these ideas independently from one another. Google was the initial innovator in this area, and Amazon (before they had expanded into AWS, of course) was impressed by Google’s approach and decided to follow suit.

Google developed the approach of vast numbers of inexpensive redundant Linux based servers. This decision was made when everyone told Google to purchase hardware from established vendors like HP instead. This is observed in the following quotation from Google.

“Our hardware must be controlled and administered by software that can handle massive scale. Hardware failures are one notable problem that we manage with software. Given the large number of hardware components in a cluster, hardware failures occur quite frequently. In a single cluster in a typical year, thousands of machines fail and thousands of hard disks break; when multiplied by the number of clusters we operate globally, these numbers become somewhat breathtaking. Therefore, we want to abstract such problems away from users, and the teams running our services similarly don’t want to be bothered by hardware failures. Each datacenter campus has teams dedicated to maintaining the hardware and datacenter infrastructure.”

SAP and Oracle don’t know anything about this. They sell software to companies, and they don’t even implement most of their software, as partners implement the majority, and of far less than advertised quality.
Neither SAP nor Oracle is well versed in how to run what AWS and Google run.
The world does not use an Oracle search engine or purchase from SAP’s online retail outlet.

SAP and Oracle have convinced Wall Street that selling and supporting software puts them in an excellent position to sell cloud services. We don’t think it does.

How the data centers are designed is not the only area of innovation on AWS and Google Cloud. At a premium tier (top), customers can access Google’s network, which is significantly faster than the public Internet. Google has laid its own undersea cables.

The more you know about AWS and Google Cloud, the more different their entire set of capabilities and philosophy appears from SAP or Oracle. This extends to their documentation, which has entirely different “voices.”