How AWS and Google Cloud Define Elastic with Autoscaling Pricing

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

Executive Summary

AWS and Google Cloud have brought fantastic elasticity to their services.
This article explains how this elastic functionality works.

Introduction

The emphasis of AWS and Google Cloud is “elastic.” This means that the services offered by AWS and Google Cloud can be easily scaled. AWS also has auto-scaling, which is covered in the AWS document AWS Auto Scaling. Autoscaling is free to use (it’s just a matter of configuration).

Our References for This Article

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

Go to top

Autoscaling currently applies to the following AWS offerings:

● Amazon EC2 Auto Scaling groups
● Aurora DB clusters
● DynamoDB global secondary indexes
● DynamoDB tables
● ECS services
● Spot Fleet requests

Under the Compute Engine in Google Cloud, notice the second option is “Autoscaling.” Any service can be scaled manually, but also scaling can be automated. The downside? If a large load hits the system, the pricing may catch customers off guard. That is why it is important to keep an eye on the running costs.

AWS continually reinforces the idea that because it is so easy to scale up, that customers should start small.

“No minimum commitments or long-term contracts are required unless you choose to save money through a reservation model. By paying for services on an as-needed basis, you can redirect your focus to innovation and invention, reducing procurement complexity and enabling your business to be fully elastic.”

And when any “serverless” service is enabled, the autoscaling is automatic.

Stuffing the Account with Licenses

Everything described up to this point regarding AWS, and Google Cloud is the opposite of SAP and Oracle. AWS and Google Cloud offer flexibility to customers, while for decades, SAP and Oracle have provided lock-in. SAP and Oracle rely upon “highly motivated” salespeople to meet their quota. This is a problem with SAP and Oracle and the on-premises sales model as well – SAP and Oracle are merely two of the most aggressive at manipulating this model. Even the autoscaling feature described in the previous section is considered a novelty with SAP and Oracle. However, characteristics like this provide freedom for the customer. It is based upon an entirely different sales principle than the status quo. SAP and Oracle try to get as much of their applications and databases into the customer regardless of its utility. It is quite common to find both SAP and Oracle customers “stuffed” with applications that they barely use or that are shelfware. License consultants help companies negotiate what to do with shelfware licenses with SAP and Oracle.

One sales rep whom we know for SAP had so stuffed their customer base with applications (and made so much money) that knowing they would have little ability to push more software into their customers, they quit SAP the following year and took the year off!

A natural question would be, why did this degree of stuffing make sense for the sales rep?

Here is why.

Stuffing customers filled with products triggered several compensation accelerators that allow for more compensation to the sales rep than if they had spread those sales over multiple years. SAP and Oracle create these incentives to which the sales reps respond. It has nothing to do with what is sustainable or good for the customer but what is in line with the Oracle executives’ short-term objectives.

One extreme example of this stuffing is Fusion (or now various Oracle Cloud components, Oracle ERP Cloud, Oracle Procurement Cloud, etc…) for Oracle. Oracle Cloud is where many customers own licenses they don’t use. SAP has its own ERP system that is used primarily as shelfware for customers that own a license. Moreover, S/4HANA for SAP, which has since its introduction, had only around 17% of those that hold a license recorded by SAP as having implemented the application. The actual number of customers lives far lower than this, as we covered in the Study of S/4HANA Implementations. This is for a product that should have been free to exist, customers of the ERP system (called ECC), as we covered in the article Why S/4HANA Should be Free.

AWS and Google Cloud’s approach is much more similar to a utility than a finished good purchase. In some cases, AWS and Google Cloud’s billing increments have become ridiculously (from the context of traditional IT mindsets) small. This includes per second billing for EC2 (and there is billing below the second now) and Google Cloud’s services. For instance, AWS’s “serverless” Lambda allows code to be run without any servers to be provisioned, which means that only the compute time is charged. That by itself is quite amazing. The other side of “on tap” billing is the reservation, whereby AWS allocates capacity in return for the customer purchasing the allocation.

As one example, all of DynamoDB’s pricing is published.

Notice the per-hour pricing for DynamoDB.

Google Cloud pricing can be calculated in their pricing calculator to create a forecast before the service is brought up. The first step is choosing the right item to be priced. The number of questions asked by the calculation form is extensive. We counted 32 questions for the Compute Engine calculation. Each calculator differs in the questions based upon the item. The Network selection has only nine questions.

Matching AWS and Google on Price?

Finally, SAP and Oracle talk to customers regarding matching AWS on price. Oracle has stated that running the Oracle Cloud will cost less than AWS. However, this is a ridiculous position to hold for companies coming in consistently so high in price and TCO for their customers since they started doing business. One reason neither Oracle nor SAP can compete with AWS or Google Cloud on price is that they aren’t multitenant. In the cloud, economies of scale come, in significant part, from multi-tenancy (we will discuss SAP and Oracle’s lack of cloud infrastructure investments further on in the book). Second, SAP does not even have a virtual private server or VPC capabilities, so it could not offer multitenancy also if they had multitenant capabilities. Moreover, of course, neither SAP nor Oracle provides a managed database service.

Furthermore, SAP and Oracle tell a very different story to investors than they do to their customers. Both companies propose that moving to the cloud will allow them to maintain or even increase their margins.

This is evidenced in part by the following quotation from the head of SAP.

“In terms of the March 2020 targets, yes, we absolutely believe that the SaaS/PaaS business, will the biggest net accelerator on cloud gross margins as we exit 2017. They have a huge catch-up to do. But if you think about the fact that at the moment we are essentially operating duplicate infrastructures across the main ones of our SaaS/Paas assets, especially SuccessFactors, that of course is a massive cost burden that will basically go entirely away once all of the customers are migrated by the end of this year. Hence we are still confident that we will achieve the gross margin progression marching towards around about 80% that we have in mind for SaaS/Pass by 2020.” – Bill McDermott

Once again, none of this is a problem with AWS or Google Cloud. AWS and Google Cloud do not have two sets of stories, one where they tell investors they intend to increase margins using the cloud and another story for customers where they state they will reduce costs.

Are Oracle and SAP a bit conflicted about whether offering cloud services will decrease prices for customers or increase margins for Oracle and SAP? Yes, yes, they are.

AWS has been very upfront with its investors to reduce costs through both scale and automation. Google tends to be a more quiet company regarding these types of topics and has a consistent message.

This is the type of thing you will not see on SAP or Oracle’s website. Pay as you go explanation. SAP and Oracle view it as in their self-interests to both get as much money as possible un front and to make pricing as difficult as possible to understand.

Go to top

Conclusion

SAP and Oracle customers looking to leverage AWS and Google Cloud will find an entirely different orientation in these companies. SAP and Oracle could not be more different than AWS and Google Cloud. While nothing can be done with SAP and Oracle without a high degree of interaction with sales reps, discussions on licensing, investigations into audits, and indirect access, AWS and Google Cloud provide access over the Internet to all of their services in an instantaneously usable form. The only thing necessary is a credit card. Oracle and SAP licensing management has its own consulting specialty firms. Upon audits, it is recommended to engage outside legal specialists in software audits. These licensing complexities and many others burn a significant effort that could be put to better uses.

With SAP and Oracle, but on-premises software vendors in general, the full costs of purchasing decisions are hidden within the overall IT budget. The billing in AWS and Google Cloud is not the TCO of the services, as there continue to be internal costs associated with using the services and hiring AWS and consulting partners for assistance. However, the total costs are at least more observable when using cloud service providers. The outcome of more cloud services being used (versus more on-premises purchases) is that the total costs become easier to track.

One of the essential features of cloud services is one of the lesser discussed. This feature can pause to shut down services, which vastly increases the ability to test services and co-test services with other services. The ability to quickly and efficiently bring down services is such a massive shift in flexibility that it is difficult to overstate the impact.

The on-premises software model is predicated upon high levels of commitment to purchase decisions that, for the most part, cannot be rolled back. This is why there is so much IT investment waste at SAP and Oracle customers. There is also a fear in admitting the waste as it career limiting.