When A FAIL Is A WIN – How NIST Got Dissed As The Point Is Missed
Randy Bias (@randybias) wrote a very interesting blog titled Cloud Computing Came To a Head In 2011, sharing his year-end perspective on the emergence of Cloud Computing and most interestingly the “…gap between ‘enterprise clouds’ and ‘web-scale clouds’”
Given that I very much agree with the dichotomy between “web-scale” and “enterprise” clouds and the very different sets of respective requirements and motivations, Randy’s post left me confused when he basically skewered the early works of NIST and their Definition of Cloud Computing:
This is why I think the NIST definition of cloud computing is such a huge FAIL. It’s focus is on the superficial aspects of ‘clouds’ without looking at the true underlying patterns of how large Internet businesses had to rethink the IT stack. They essentially fall into the error of staying at my ‘Phase 2: VMs and VDCs’ (above). No mention of CAP theorem, understanding the fallacies of distributed computing that lead to successful scale out architectures and strategies, the core socio-economics that are crucial to meeting certain capital and operational cost points, or really any acknowledgement of this very clear divide between clouds built using existing ‘enterprise computing’ techniques and those using emergent ‘cloud computing’ technologies and thinking.
Nope. No mention of CAP theorem or socio-economic drivers, yet strangely the context of what the document was designed to convey renders this rant moot.
Frankly, NIST’s early work did more to further the discussion of *WHAT* Cloud Computing meant than almost any person or group evangelizing Cloud Computing…especially to a world of users whose most difficult challenges is trying to understand the differences between traditional enterprise IT and Cloud Computing
As I reacted to this point on Twitter, Simon Wardley (@swardley) commented in agreement with Randy’s assertions, but strangely what I found odd again was the misplaced angst by which the criterion of “success” vs “FAIL” that both Simon and Randy were measuring the NIST document against:
Both Randy and Simon seem to be judging NIST’s efforts against their lack of extolling the virtues, or “WHY” versus the “WHAT” of Cloud, and as such, were basically doing a disservice by perpetuating aged concepts rooted in archaic enterprise practices rather than boundary stretch, trailblaze and promote the enlightened stance of “web-scale” cloud.
Well…
The thing is, as NIST stated in both the purpose and audience sections of their document, the “WHY” of Cloud was not the main intent (and frankly best left to those who make a living talking about it…)
From the NIST document preface:
1.2 Purpose and Scope
Cloud computing is an evolving paradigm. The NIST definition characterizes important aspects of cloud computing and is intended to serve as a means for broad comparisons of cloud services and deployment strategies, and to provide a baseline for discussion from what is cloud computing to how to best use cloud computing. The service and deployment models defined form a simple taxonomy that is not intended to prescribe or constrain any particular method of deployment, service delivery, or business operation.
1.3 Audience
The intended audience of this document is system planners, program managers, technologists, and others adopting cloud computing as consumers or providers of cloud services.
This was an early work (the initial draft was released in 2009, final in late 2011,) and when it was written, many people — Randy, Simon and myself included — we still finding the best route, words and methodology to verbalize the “Why.” And now it’s skewered as “mechanistic drivel.”*
At the time NIST was developing their document, I was working in parallel writing the “Architecture” chapter of the first edition of the Cloud Security Alliance’s Guidance for Cloud Computing. I started out including my own definitional work in the document but later aligned to the NIST definitions because it was generally in line with mine and was well on the way to engendering a good deal of conversation around standard vocabulary.
This blog post summarized the work at the time (prior to the NIST inclusion). I think you might find the author of the second comment on that post rather interesting, especially given how much of a FAIL this was all supposed to be… 🙂
It’s only now with the clarity of hindsight that it’s easier to take the “WHY,” and utilize the “WHAT” (from NIST and others, especially practitioners like Randy) in a manner that is complementary so we can talk less about “what and why” and rather “HOW.”
So while the NIST document wasn’t, isn’t and likely never will be “perfect,” and does not address every use case or even eloquently frame the “WHY,” it still serves as a very useful resource upon which many people can start a conversation regarding Cloud Computing.
It’s funny really…the first tenet for “web-scale” cloud that AWS — the “Kings of Cloud” Randy speaks about constantly — is “PLAN FOR FAIL.” So if the NIST document truly meets this seal of disapproval and is a FAIL, then I guess it’s a win ;p
Your opinion?
/Hoff
*N.B. I’m not suggesting that critiquing a document is somehow verboten or that NIST is somehow infallible or sacrosanct — far from it. In fact, I’ve been quite critical and vocal in my feedback with regard to both this document and efforts like FedRAMP. However, this is during the documents’ construction and with the intent to make it better within the context within which they were designed versus the rear view mirror.
You are spot on Chris by pointing out that NIST was simply providing a framework or starting point for discussions of what cloud computing is. Their definition is begin used by a multitude of companies that I speak to every day. They are using this “what” to gauge against those that would be “cloud washing” offerings along with using other aspects of the NIST working group like their reference architecture and standards roadmap to get to the “how”. The “why” is for every organization out there to determine is this a viable option for their organization. This definition and standards, combined with an understanding that cloud is really an operational model and armed with a rearchitected (IT) business model will help make organizations successful in this new age of computing. All three combined (what, how, and why) are necessary not just one. The rant about Cap theorem and socio-economic factors is all hot air. i can tell you with certainty that the CEOs and other executives that I have spoken with aren’t looking at any of the stuff. It doesn’t matter to them.
Great post here.
Cheers
Michael
Michael Keen’s point is right on. Over the last four years of working in selling enterprise software, I’ve yet to run across an IT shop that is worried with such details as CAP theorem. Most shops are barely holding their head above water and such theories of Computer Science is just minutia for them.
I think it is important that we remember the lack of sophistication in most IT departments. Most IT departments haven’t automated basic operations such as configuration changes and patching, yet automation has been around for years and is a mature technology. So now we are expecting these immature shops to rapidly adopt the advanced and cutting edge (to them) concepts of Cloud?
NIST’s guide provides a starting point for IT shops to begin the conversation. It’s a reference, as the title of the document states in it’s title “NIST Cloud Computing Reference Architecture”.
Truly an interesting discussion. My colleagues and I have gone through the NIST documentation a number of times with varying outcomes.
On the matter of creating dialogue around a different technology model, I agree that the NIST definition accomplished its goal. On the matter of being sufficient, I find it has come short.
For consumers of “cloud” technologies, the difficulties lie not in the what, but rather the how and why. Similarly, those who have worked within the hosting or managed services space find the “cloud” annoying as 90% of cloud was old news.
My customers are not struggling with technology in regard to cloud services; they wrestle with impacts on business processes, security, auditing, and billing.
I say this to emphasize the fact that the NIST guidance is already becoming moot as the technology is moving behind and the processes are quickly arising.
** As most clients are focused on IaaS at this time, the comments above do not address the radical changes pending for software development in a distributed processing model nor the architectural marrying of procedures to insure service availability.
Resurrecting an old thread…
From my perspective, the NIST definition is just that – a “definition” – which is all about “what”. If you want the “why”, you need to be looking for a “justification”. Think of it in the perspective of a car. When you define what a car is, you describe it in terms like “self propelled”, “capable of carrying stuff”, etc. You don’t talk about WHY you might want to have a car (“take kids to sporting events”, “commute to work”, “go on vacation”, etc.).
I think NIST was spot-on. They provided a broad generalization that enabled the business leader to begin to comprehend what “cloud” means. Is it a comprehensive definition? No. I don’t think anyone can give a comprehensive definition (it’s constantly changing).
Is it a FAIL? No. It did exactly what it was supposed to do…