Several years ago, it wasn’t unusual to hear people say that public cloud computing was significantly cheaper that trying to build a private cloud computing environment. This was mostly because people would see the cost/hour (in USD pennies) and immediately think this was significantly less than the large CAPEX bill they recently paid for racks of equipment in their own data center.
But over time, as more applications were run in cloud computing environments, people began to understand a few basic cost principles:
- For short-term projects, public costs are often less.
- For high-capacity projects (100-1000s servers), or highly variable projects, public costs are often less.
- For long-running projects, private costs are often less.
- For limited variability projects, private costs are often less.
There will be plenty of people that can come back with examples of similar projects where the costs are higher (or lower) in one environment or the other. In fact, what is often found by people using cloud computing is that it doesn’t significantly reduce costs (over time). Instead, the prevailing ROI is beginning to be measured on levels of agility, better application performance, or time to market for new ideas (or applications).
Regardless of whether a company runs their applications in public clouds or private clouds, it’s important to understand how costs are incurred. Today, it’s still difficult to make an apples-to-apples comparison between environments as there is not a consistent unit of measurement, or a consistent list of what costs are included. [See this video for a short explanation of cloud computing still isn’t priced like commodity markets, or listen to this podcast]
For private clouds, many companies are trying to deploy self-service environments that mirror some of the elements of the popular public cloud offerings. They may offer multiple sizes for compute (CPU/RAM) or storage (GB), but in many cases they still can’t offer granular pricing – only per/month, instead of per/hour. But from a simplicity perspective, they bundle in costs like IP-Addresses, DNS Services, Network Bandwidth, and don’t change on the I/O for applications.
For public clouds, any of the following could be part of the cost of the service. It’s important to note that while comparisons can be made between services (do a Google search on “compare AWS to GCE” or “compare AWS to Azure”; or pick any public services), they use different terminology, as well as having different way to buy services – per hour, per year, spot markets, etc.
- Server (VM) – CPU / Memory
- Storage – Local vs. SAN/NAS Disk; HDD vs. SSD; GB, # Input or Output Requests
- Network – IP Addresses, DNS Services, VLANs, Inbound vs. Outbound traffic (Mb/s vs. Total), VPN Services
- Load-Balancing – Enabled or Disabled
- Security – Firewalls, IDS/IPS Services, Monitoring Services
- Redundancy – Moving Services between Availability Zones
- Backup – Internal Services
- Application Services – DB Services, I/O requests
- OS / Application Licensing – Bring Your Own vs. Rent the OS/Application
As an example of how costs can be somewhat confusing, and potentially end up much higher than expected, here is an example of a public service that I’ve used recently. I uploaded about 500Gb of files to the AWS Glacier storage service, for long-term retention. I also setup a Cloudability account to monitor the costs, which I expected to be $0.01/Gb/month, per the pricing on the AWS website. When I started getting the daily notifications from Cloudability (see above), I was somewhat surprised to see their forecasted number. As I started to dig into the pricing, I noticed that AWS also charges “UPLOAD and RETRIEVAL Requests – $0.05 per 1000”, which I soon suspected were the cause of the higher costs. I found that others had run into similar cost surprises. I’m still investigating why the costs are so high, as my logs from AWS don’t list the 1000s of requests it would take to generate $300+ in costs. I may also have to watch out for these costs when I need the files back.
I’ll eventually get to the bottom of my public cloud costs, but as you can see (even in this small example), it is critical that you have tools in place to provide visbility into your application and it’s interaction with other elements (network, storage, bandwidth, etc.). It’s also critical to understand all the elements that are priced into the cost of the public cloud service. This is even more important if you don’t have a very clear understanding of how your application traffic behaves.
The bottomline is that either public cloud or private cloud could be the right model for your business applications, or even a hybrid combination. But either way, it’s imperative that you have the tools in place to understand how much the various options will cost, so that you can truly measure how impactful the new cloud operating model is for your business.