James Staten serves Infrastructure & Operations Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Infrastructure & Operations Professionals successful every day.
Follow James on Twitter.
James Staten serves Infrastructure & Operations Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Infrastructure & Operations Professionals successful every day.
Follow James on Twitter.
Posted by James Staten on May 24, 2012
We all have habits we would like to (and should) break such as leaving the lights on in rooms we are no longer in and good habits we want to encourage such as recycling plastic bottles and driving our cars more efficiently. We often don't because habits are hard to change and often the impact isn't immediate or all that meaningful to us. The same has long been true in IT. But keep up these bad habits in the cloud, and it will cost you - sometimes a lot.
As developers, we often ask for more resources from the infrastructure & operations (I&O) teams than we really need so we don't have to go back later and ask for more - too painful and time consuming. We also often don't know how many resources our code might need, so we might as well take as much as we can get. But do we ever give it back when we learn it is more than we need?
On the other hand, I&O often isn't any better. The first rule we learned about capacity planning was that it's more expensive to underestimate resource needs and be wrong than to overestimate, and we always seem to consume more resources eventually.
Well, infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) clouds change this equation dramatically, and you can reap big rewards if you change with them. For example, sure, you can ask for as many resources as you want - there's no pain associated with getting them and no pain to ask for more, either. But once you have them and figure how much you really need, it heavily behooves you to give back what you aren't using. Because you are paying for what you allocated whether you are really using it or not.
Cloudyn, a SaaS-based cloud cost management company, knows how much this is costing its enterprise clients, as it uses monitoring capabilities to map the difference between what its clients are paying for and what they are really using. It recently shared with Forrester the latest findings in its CloudynDex metrics report that aggregates cloud use and cost data from more than 100 of its clients running on Amazon Web Services' (AWS) IaaS cloud (collected randomly and anonymously with its clients' permission). The data is clear proof that we are bringing these bad habits to the cloud. These clients are spending between $12,000 to $2.5 million per year with AWS and throwing away about 40% of that expense. What kind of waste are they incurring?
Attend Forrester’s Forum for Infrastructure & Operations Professionals EMEA, June 10-11, London UK
Attend the complimentary Webinar Provide Next Generation Services To Your Customers June 5, 2013, 1:00–2:00 p.m. EST
Comments
AWS performance may be part of the reason
Great post -- could not agree more with the overall point. When it comes to the Cloudyn survey, one reason many people use much larger instances than they need on AWS is to get better I/O performance, and to avoid "noisy neighbors" by allocating an instance that fills an entire physical server. Adrian Cockroft's blog last year had great details on this strategy: http://perfcap.blogspot.com/2011/03/understanding-and-using-amazon-ebs.html So perhaps the use of far larger instances than required is deliberate.
Secondly, Bluelock did some work last year that showed that elastic capacity was a better choice for unpredictable workloads, even if they were relatively static in nature, because of the tendency to over-estimate the resources required (as you point out). One of the advantages of a true hybrid cloud is that if you find something is relatively static, you can simply bring it back to your own data center / private cloud and run it there for less. But if your app is bound to a specific cloud, you don't have that option.
Great observations
Excellent, excellent points and observations.
AWS performance and other considerations
The I/O observation is very true. There may be other reasons:
Some applications (Mongo DB is one of the most notorious) perform much better on high-RAM instances, so you have no choice but to use highest available instances.
A slave DB must be of the same type as its master to be able to take over, even when it does nothing most of the time.
But putting these use cases aside, a huge percentage of instances is still over-provisioned. We see cases where for Hadoop processing people launch extra-large servers using only a fraction of the available I/O. We see high-compute servers just sitting there doing nothing. We saw an RDS Extra Large DB Instance doing an I/O of ~10 kb/hour for about 2 months ..
Obviously in many cases you should keep your selected instance sizes. But you should not take the size for granted. And that's what Cloudyn is about: it points you to the possible waste. You know best whether the recommendations make sense or no, but it's worth checking. The saving may be quite rewarding.
Amazon AWS will not be happy to take your "underutilized" money
James S - Great interesting findings. I invite you to check out more on out site at http://www.newvem.com/cloud-radar
You wrote:
"Cloud vendors will certainly be happy to take your money for this. But, really. Is it really that hard to shut down an instance and restart it when needed? "
I am not sure that I agree with you on that. I believe that Amazon doesn't want its cloud customers to feel like it is taking advantage of that "cloud fog" in order to extend its business. Check the followings:
1 - Their "Monitor Estimated Charges Using Billing Alerts" feature - http://aws.typepad.com/aws/2012/05/monitor-estimated-costs-using- - amazon-cloudwatch-billing-metrics-and-alarms.html
2 - Trusted adviser tools
http://aws.amazon.com/about-aws/whats-new/2012/01/30/amazon-web-services...
These prove Amazon efforts to provide analytic capabilities. It is only a matter of priorities - it doesn't matter if you are a small startup or a giant company you still have priorities. AWS cloud develops very fast and no doubt that its first priority is to supply the demand for newcomers with regards to compute and storage resources and only than comes all other "important feature requests".
These type of uncontrolled costs put cloud adoption at risk as companies go to the cloud to eliminate IT costs. Once they get their cloud monthly bill, some of them decide to leave AWS cloud. Companies like Cloudyn and Newvem help AWS customers to adopt the cloud right and take one control step at a time. I invite you to read my CloudAve.com post about what's Cloud Management including some more stuff I think is important for this discussion - http://www.cloudave.com/19762/whats-cloud-management/
Ofir.
@iamondemand