RansomCloud — The pending public cloud price apocalypse

Many moons ago I was a serial owner-operator of internet technology firms — this was mostly transit (the sale and provision of IP connectivity for other internet tech firms as well as my own) and ‘hosting’ (today that is IaaS; SaaS or PaaS) with a smidge of managed services for the same.

Much like other commercial entities we balanced service-v-price and gave out discounts and/or special deals in order to win — and keep — customers.

This post discusses what I believe to be an inevitable material price increase in the public cloud space.

In this post I focus on Amazon Web Services (AWS) but is applicable to other ‘hyper-scale* public cloud’ provider such as Microsoft Azure; Google Cloud or Alibaba Cloud.

* single asterisks means I sighed out loud when typing

Defining ‘cloud computing’

I define ‘cloud’ as simply consuming an internet technology service as a managed utility rather than building or operating it yourself.

It may be highly-resilient and fault-tolerant. You might pay for it on a per-use basis (per second or minute billing). It probably isn’t that special. It will be smothered in marketing magic.

As a general rule of thumb if it is ‘cloud’ it is not on-premise.

Cloud is _probably_ pretty good for you

Cloud computing does help you do some things better (including, but not limited to):

• You don’t need to spend lots of upfront money (capex) on commodity infrastructure (like servers; rack space and power/cooling)
• You generally only pay for what you use when you use it
• Hyper-scale* public cloud providers invest heavily in getting their side of the security responsibility to a worthy state
• In a very sweeping generality: the IaaS/PaaS/SaaS tooling helps you get started quickly and easily
• The hyper-scale* also lets you scale in a way that you probably couldn’t by yourself (well, as easily)

Cloud _can_ be ‘best’ even if it isn’t cheapest

I have consulted with various clients on their technology (…digital*) needs over far too many years — one of my go-to phrases is “culmination of best” which varies in context but is largely the weighing of price, functionality, time, effort, scale, technology R&D (not what it does now, but what it is forecasted to do or could do) and prediction (where these metrics will go combined with your own need for change).

Many times I have found myself to be the only person at a table to state that public cloud providers are ‘not cheap’ (particularly at-scale) but can be ‘best’.

Saying that public cloud is ‘not cheap’ has led to some friction with very senior stakeholders and technical staff so I tend to stick with the “culmination of best” to keep conversations productive. In my view, those who dismiss vendor lock-in and price increase issues too quickly are very good at what they do but they simply don’t think defensively/pessimistically and have wildly varying levels of commercial experience (particularly in being responsible for commercial/business risks)— but I suppose that is why our clients work with consultants like us.

Public cloud is often perceived as being cheap due to how the costs are described (x cents per hour) and by sheer perceived contrast to how much people paid for managed data-centres.

Proprietary cloud implementations (particularly from really old legacy) cost a lot of money/time/effort and in some cases cost far more than using more traditional and less proprietary technologies to achieve the same outcome.

If you want meaningful technology efficiencies from using public cloud you have to jump in with both feet and consume various proprietary services along the way— popular examples include CloudFront; Elastic Load Balancers; Relational Database Services and Simple Email Services.

In the last few years, 9 out of 10 times for my clients the culmination of ‘best’ for hosting needs has been to use a public cloud provider — but each decision knowingly (or unknowingly, depending on the organisation and people at the table) took on (from the list above) price; time; effort and prediction related risks.

It is not public cloud — it is JeffCloud

It doesn’t matter if you’re a Fortune 500 company; backed by a tech fund with significant $AMZN holdings or a government — you do not have ultimate control over the availability of utility service you’re consuming; the current/future functionality…nor the price you’re going to pay for it.

Your response might be ‘well, I am a big customer, I can bargain’ (and that may be true) but you still do not have ultimate control — you cannot dictate, you can only haggle.

Jeff’s cloud is special

While ‘commodity’ is often used as a descriptor for public cloud the service offerings are proprietary.

While standardised consumption (think APIs; XML schemas etc) help make things look the same, ultimately the technology service from AWS is unique and cannot be simply lifted and shifted into Microsoft Azure (for example) — even if you’re running your own commodity container solution (such as Kubernetes).

I would challenge someone with a solution that is bought into the AWS koolaid (CloudFront/WAF + ALBs + Fargate + SQS + RDS with SES/Lambda/CloudWatch surrounded by multi-account configurations and CloudFormation) to describe a simple lift and shift to Azure or in-house Xen/VMWare.

So, whats the problem?

$AMZN recently increased their Amazon Prime annual subscription cost from $99 to $119 (~20%). This in theory creates ~$2billion/year in revenue…from a few lines/variables of pricing/advertising code and a press release.

I thoroughly enjoy my Amazon Prime membership. I have no intention of cancelling or changing my subscription. This would hold true if they had decided to double it… but I don’t think I could say the same for my AWS bills.

On the assumption you’re using public cloud providers; you’ve architected your stuff around their technology; and you are [currently] technologically efficient by using the IaaS/PaaS/SaaS solutions from that provider — you’re locked in.

AWS could easily change their pricing on various core and/or outliner products and with little notice your AWS costs could jump 20%.

Even if you have 2 years left on your pricing agreement they could serve you with notice or simply bide their time to catch you on renewal.

“AWS probably have enough commercial room to decrease their pricing further”

So? They are under no obligation to do so.

The manufactured cost of the $999 iPhone X to Apple has been calculated to be around $350 (I believe this not include iOS or R&D etc)… I do not see Apple reducing the price of their iPhone product line in a meaningfully sustained way, do you?

AWS do give discounts or freebies and I am not saying these will stop or that they will not be meaningful or offer value — but that the house always wins.

“AWS wouldn’t do that [to me]”

I hope you don’t genuinely believe that*

$AMZN do not need your business despite however much they might want you as a customer.

You probably need them.

“I am, or could go, multi-cloud”

I think people like the idea of multi-cloud (to be cloud vendor agnostic)… until they try and do it.

As said above, technology efficiency within cloud providers comes from using their proprietary services.

Multi-cloud requires you to round-down to the common denominator between cloud providers and avoid proprietary products (usually building them yourself, or using a broker in the middle).

An example of multi-cloud would be to run your own Kubernetes (via EC2, not EKS) on AWS and then again on Azure which would ‘fix’ your containerised compute problem but then you’re stuck on middleware brokers for databases; DNS and everything in-between.

So, why does it matter?

I’m not saying it does but that depends on you in your context.

If $AMZN told you that from 2019 your AWS costs would rise by 10% what would this mean to you?

If thats an extra +$100k/year opex maybe you just live with it because your cost of migration to your own data-centres with comparable capability is $<too much>capex.

Maybe its an extra +$1mil/month opex and your migration cost is $10mil capex but that $10mil is looks pretty good compared to staying.

You could be in a position when year-on-year you’re fighting for innovation budgets and your operational budgets are also getting smaller so a 20% price-hike blows your business case out of the water.

A 20% rise x years into using AWS might entirely negate any of the savings you made by moving to AWS.

Is a price increase possible?

Of course.

When will it happen?

Eventually — I realise that isn’t much of a prediction but when companies might increase pricing depends on a whole bunch of complex things.

In my view, the major public cloud players are in the middle of various turf wars over market share, when one feels like it is where it wants to be — boom.

Why will it happen?

The answer isn’t just ‘profit’.

AWS is unlikely to increase pricing without improving services; investing more into R&D or passing on their underlying cost increases (such as power bills).

AWS are smart enough to associate price increases to some sort of improvement in service.

OK, what should I do?

As mentioned above, my clients have knowingly or unknowingly taken on some risk of attaching themselves to the hip of a public cloud technology provider.

Your organisation (as with all supply chain) be aware of (not exhaustive!):

• the costs of moving away (time+money)
• a good-enough indication of how to move (that has various degrees from accessing your data to actually building a new solution and moving ‘production’ service)
• what triggers a move (AWS costs go up x% or spending $x/year means your own data-centre is cheaper etc)
• the impacts of moving (what other things can you no longer do,negative experience to service users etc)
• what you would do if you can’t move but have to reduce or mainain costs (a real-world case of having less money to spend than you did the year before)

Overall, most will simply suck it up and curse those who say ‘I told you so’.

We’ll probably work with our clients to update the definition of ‘best’ and move the cost slider and see what happens.

As usual, the group most likely to feel the pain of a price increase are those already close to their triggers and tolerances.

You might find other exciting posts in my Medium profile. I’m on Twitter as @JoelGSamuel.