If you had to pick one characteristic of cloud computing that sets it apart, that defines what makes it different from, well, just plain computing, it would probably have to be elasticity. Of course we all know what elasticity is, right? The NIST definition of rapid elasticity states that “capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.” Naturally I’m as grateful as anyone else in the industry that NIST provided some good definitions at a time when cloud was just taking off and everyone needed to know what it was. But… guys… you do realize that you used the term itself in the definition of the term, right? Elasticity is …elastic provisioning?
I’m being a little facetious here, but this does point to a real problem. The tendency for early adopters of cloud computing has been to look at elasticity as a check box – something you have to have to qualify as cloud. “Is your service elastic, Mr. Provider? Yes? Great!” But the word elasticity is a relative term. It cries out to be qualified, which is undoubtedly why NIST added the word “rapid” before they defined it (but then also used the word rapid in the definition – ouch). Any IT resource that can be increased or decreased is elastic – so what? It doesn’t become interesting unless you know how elastic it is! We have to measure it for it to have any value.
So, how do we measure elasticity? For our measurement to be useful we need to look at the actual characteristics that benefit the customer. How fast will each resource be added when it’s needed? How fast will it be released when it isn’t needed? When each resource is added how much gets added? How much gets released? How is the process of provisioning and de-provisioning resources automated? Is it under application control? Is it according to a template you fill out? Is it determined by the provider’s monitoring tools? Does it require you to make a phone call or send an email? These are all questions that need to be asked, and the answers can vary widely from provider to provider and from service to service.
The other major factor that will vary widely, of course, is how much you care, because that will change from application to application. If the application you are putting into the cloud is expected to generate very volatile workloads that change in minutes rather than days, and you don’t want to pay for capacity you aren’t using during the low points in those workloads, then very rapid, granular, automated elasticity is something you should place a high priority on. If your application has steady, predictable workloads then your need for elasticity is going to be less. Your infrastructure is there to run your applications, and the cloud doesn’t change that. So figure out what you need first – consult your application team and your business owners, and then when you look at cloud services ask the questions that will tell you if you are actually getting what you need rather than just checking a box. Later on you will be glad you did.
About the author
