The cloud price wars are still on. Granted, these are now nowhere near what they were a couple of years ago when Amazon and Google tried to outdo each other with a relentless price slashing. If you remember those days, one of the big vendors would announce every quarter yet another round of price cuts, which was quickly followed by a competitor responding in kind. After a while, they probably realized that the desire to be first in a race to the bottom had to stop. Don’t get me wrong, slashing prices so customers spend less is a very good thing. But it can’t go on forever. We all know the saying “we need to do more with less,” but if we keep going down that path, we will eventually have to “do everything with nothing,” and that’s not sustainable.
The following two charts illustrate historical price cut trends, as well as some specific server price reductions on AWS.
History of Cloud Pricing
All three big public cloud vendors (AWS, Microsoft and Google) have historically had different price models for renting virtual servers. Let’s quickly review how they’ve changed over the years:
- Amazon started charging by the hour with a 1 hour minimum, and just recently migrated to per-second billing (more on this later).
- Microsoft started with billing VMs by the hour, then moved to billing by the minute, and now bills by the second but only for containers and functions.
- Google used to charge by the minute with a 10 minute minimum, and now charges by the second with a 1 minute minimum.
All public cloud vendors’ hourly rates vary from a few cents to a few dollars depending on how powerful a server you rent.
On top of that, every vendor has a different approach to helping clients realize additional cost savings if they rent virtual machines for a long time. Amazon allows you (or forces you, depending on how you look at it) to prepay for capacity by buying reserved instances. If you are going to use a server consistently for a year or more, it makes sense to prepay upfront and save a good chunk of money in the long term. Google’s approach is different. They automatically give customers discounts based on how long the server is in use. They call this feature a sustained use discount, and it’s a nice, automatic way to get a cost break if the server is in use for awhile. Azure also started offering reserved instances recently, but with the added twist that you can cancel them if you want.
Buying reserved instances upfront does force one to think through the capacity and usage required, but let’s be honest, most enterprises are not very good yet at predicting server capacity on the cloud and properly utilizing it to get the most of it.
Needless to say, these convoluted price structures are extremely confusing to customers and in dire need of simplification.
The Shift in Thinking
After the all-out price cuts on servers ended, cloud providers got a little more sophisticated. Now, instead of simply cutting prices for your virtual instances per hour, most vendors are trying to cut back on the amount of time they charge you for. Amazon recently announced that it is moving to a per-second price model. That move was quickly mirrored by Google a week later.
This recent shift in pricing seems to be focused on removing cloud adoption friction by minimizing the need for upfront planning. This more flexible pricing arrangement (sub-minute billing) for VMs is bringing some parity to already existing serverless offerings (Azure functions, AWS Lambda, Google Cloud Functions), by allowing you to address your computing needs while paying by the second (or even less at times).
This change is another great step in bringing the true promise of cloud elasticity and “pay as you go,” versus “plan a ton upfront and hope you get it right”. However, that still leaves us with the focus on buying servers by the hour or minute or second, and I think that’s wrong. I am not saying that saving money is not important–it most definitely is. But I am saying that placing a focus on “look, now you pay for each second used instead of each hour” doesn’t significantly change things for an average enterprise, and distracts you from other more important aspects and benefits of the cloud, such as agility, flexibility, features and capabilities. I see this as more of a marketing gimmick to outshine other providers.
Let’s Count Peanuts
To support my assertion about “not significantly changing things.” I’m going to use an AWS price structure (US-East Ohio) for this exercise, but other cloud pricing could work here just as well.
Use Case 1: Let’s say you’re an average size company with a distributed set of applications (some commercial off-the-shelf, some home-grown Java, .Net, etc), and have 1000 VMs in a public cloud. Most of those VMs never stop, running continuously to support your production. Let’s say you are also one of those advanced companies who stop all their Dev/Test machines every day at 7 PM and restart them at 7AM, and they’re never up on weekends. Let’s further assume that 70% of your virtual machines are dedicated to your Dev/Test environment. So if your scheduler shuts down the machines at 7:00:01 PM, you will now be charged for the 1 second instead of the full hour. Let’s even further assume that ALL these development virtual machines are a good size (C4.4xlarge – 16 vCPUs and 30GB RAM) that costs you $0.796 / hour. In this scenario, you will see daily savings of $557.
Here’s the formula: 1 hour savings x $0.796 per hour x 700 instances = $557 per day.
That adds up to weekly savings of $2,786, and annual savings of $145K. Wow, that’s a lot of money, but let’s dig in a little further. For the numbers above to be true, you would be using all your servers in a pay-as-you-go model (without prepaying for reserved instances). If you prepaid, your hourly costs would have been much lower and so would your potential savings. In addition, prepaying suggests that you expect to use the servers most of the time and not start/stop them a whole lot. If you’re starting and stopping them as described above, something is wrong in the architecture and business models, and you need to rethink your approach.
But let’s say the architecture and business models are fine, and you truly need to do what was described. In that case, the actual cost of those servers to you is:
700 servers x 12 hours (7 AM – 7 PM) x $0.796/hour x 5 days/week x 52 weeks = $1,738,500.
Now, that’s a BIG number, and the savings amount to 8.3% of your total compute spend! But if you’re spending $1.7M a year on simply renting servers from a public cloud vendor, something else is wrong. You either have not done a proper TCO analysis of your cloud usage, did not architect your applications and environments to take advantage of cloud capabilities, or simply are not paying attention to where the money goes. If those are all true, I don’t think you’re the type of company that cares about a “mere” $145k in savings–it doesn’t look like it makes that much of a difference to you. By the way, your true cloud bill is most likely much higher because we haven’t even talked about the cost of storage, networking, APIs, etc.
Use Case 2: Now let’s look at a more realistic scenario than the one above. Something like web servers that need to handle spikes in traffic, or applications that periodically spin up a series of servers to perform high-intensity computations. Let’s examine the bursty web server scenario. Your company has a very cool website that’s incredibly popular. You have 300 web servers (c4.large – 2 vCPUs with 3.75GB RAM) powering the website, behind a load balancer and an auto-scaling group set up to account for spikes. Each server costs you $0.10/hour. Every day, there’s a spike in activity each morning and then for a couple of hours in the afternoon, where you need to increase the capacity by 40%. That’s actually a lot, but let’s go with it for argument’s sake. Let’s also use the above comparison where shutting down within 1 second saves you the whole hour. So your annual savings now are:
120 servers (300 servers x 40%) x 2 spikes a day (1 hour savings in the AM shutdown and 1 in the PM) x $0.10 x 365 days/year = $8,760
That’s a decent chunk of change that should definitely come in handy for other needs.
Now, let’s calculate your total spend:
- Regular servers: 300 x $0.10/hour x 24 hours/day x 365 days/year = $262,800
- Scaled-up servers: 120 x 2 times/day x 2 hours/spike x $0.10/hour x 365 days/year = $17,520
- Total: $280,320
So your $8K savings represent a puny 3.1% savings of your compute spend, and a much smaller percentage of your overall spend when you include storage and networking.
Do you see the pattern here? Savings are always good, but the true savings will NOT come from using cloud as a “rent-a-server,” or from spinning up servers for only 1 minute instead of the full hour. You should absolutely expect your cloud infrastructure provider to charge you less as they realize additional cost benefits from economies of scale. You should also expect your cloud provider to offer a simple price structure that a normal person without a Ph.D. can understand. And you should not fall for the gimmick of “look, we now charge you per second” if all of your servers run 24×7.
The True Cost Savings
So what does this all mean? Savings from vendor price reductions and charging for smaller increments are byproducts of technology innovation and economies of scale, and should be expected. True savings on the cloud will come from the following:
- Conducting a proper analysis of your application portfolio estate, and understanding how well those applications are suited for the cloud
- Designing the most appropriate application architecture that considers interconnectivity, resiliency, high availability AND takes advantage of cloud-native features and PaaS capabilities
- Performing a true TCO of your cloud estate and basing that TCO on the proposed cloud architecture
If you haven’t performed the three steps above (whether you haven’t started your cloud migration yet or have simply moved some applications via the “lift-and-shift” approach), you have not done yourself justice in figuring out what your true costs–and best savings–could be.
The following three aspects are core to our Cloud Adoption Program methodology by which we help our clients realize significant advantages (cost, technology and business value) from public cloud.
Let’s take a look at each one in more detail.
1. Assess Application Portfolio
You have hundreds of applications that vary from commercial off-the-shelf to home-grown and open-source. All these applications have unique characteristics–software versions, memory footprints, network latency, BC/DR requirements, revenue and business value and interdependencies between them. You need to conduct a holistic review of those applications to understand which ones are already well suited for the cloud, which ones could be well suited with some amount of refactoring, and which applications should not be on the cloud at all. Knowing that information is the first step in identifying what your cloud costs will be. You also need to identify a compelling first application to move to the cloud, to help your organization understand what it takes to operate there and to test your hypotheses for the rest of your application portfolio.
2. Design Appropriate Cloud Architecture
The goal of the cloud is not simply to mirror your current infrastructure server by server, and subnet by subnet, as is usually an organization’s first reaction. You should be looking for ways to take advantage of cloud features and capabilities to optimize your current applications and infrastructure, while maintaining or improving security, performance and availability, and decreasing costs.
Yes, quite often you can simply move the application to the cloud as-is, but that might not be the right thing to do, and not just from a cost perspective. My example above where a company had 700 development servers is a good use case of the need to re-architect something. Maybe instead of each developer getting a server, the applications need to be re-written, containerized, broken into micro-services, etc.
During the application portfolio assessment process, you should have identified some characteristics for your applications that will guide you toward whether the app is good to go as-is, or needs to be replatformed, refactored or just plain retired. All these decisions affect your future cloud architecture and operating and migration costs. Step #10 in our Cloud Adoption Blueprint outlines a solid migration approach, and different ways to categorize your applications.
3. Perform TCO / ROI assessment
Do you really want to know how much public cloud is going to cost you? Do you really want to know whether shutting down those servers in 10 seconds will make a difference? If yes, you need to take the learnings from above and calculate the TCO of your cloud operations, including your desired architecture, maintenance costs, licensing and additional incremental projections over the next three years. If you need ROI, you will need to couple your TCO data with a proper analysis of your current on-premise costs for applications, infrastructure, human resources and software licenses, and calculate the costs of migrating or refactoring the applications on their journey to the cloud.
Do these exercises need to be as comprehensive and laborious as getting a Ph.D. in Computer Science or an M.B.A. in Finance? No, but you should dedicate the appropriate amount of time to ensure you have complete visibility into what’s going to happen before you get into the cloud.
And if you’re already running on the cloud and are past the point of doing the things I am recommending above, you should still be constantly watching your spend and optimizing your operations. Amazon’s announcement of charging for VMs by the second might have a direct impact on how you decide to architect your application.
Are you sure you’re getting the most benefit out of your public cloud? If the answer is not a 100% yes, call us. We can help.