A few observations on the NIST DRAFT Cloud Computing Synopsis and Recommendations

NIST have produced a   DRAFT Cloud Computing Synopsis and Recommendations. draft

The draft presents an overview of major classes of cloud technology, and provides guidelines and recommendations on how organisations  should consider the relative opportunities and risks of cloud computing.

Firstly by Organisations I’m sure they really mean US Governmental Depts and by association companies providing services to them. I thought it worth a close scrutiny as a result

The document starts off with definitions of types of clouds and  service models where they note that IaaS type services are more portable .  Personally I  think these definitions are a little outdated as he blurring of lines makes them redundant.  With the introduction of ‘Bring your own PaaS / containerised PaaS’ this statement does not stand up to close inspection.

I’ve only got to page 10 of a 84 page document and already I have serious concerns of the applicability of this document but whatever I’ll move on.

Under the Commercial terms of service section this covers Promises (SLAs) , Limitations, End user obligations

SLA’s Nothing new here basically you get SLA’s that promise certain levels of avialbilty, compensation for failure to perform, Data protection and Legal care of subscriber information with anything not just cloud services . Same observation with the limitations section. The recommendations are due diligence recommendations which you’d so anyway regardless of what services you were engaging cloud or not. The only interesting item in this section is this statement:

“Negotiated SLA. If the terms of the default SLA do not address all subscriber needs, the subscriber Should discuss modifications of the SLA with the provider prior to use.”

Making modifications to SLA’s for commodity computing resources which the public cloud provides will I suspect be one conversation that will take too long and probably with no acceptable outcome unless the supplier is willing to ring fence resources and can  really can provide a superior service on request.

I do however love the section on General Cloud environments it cuts right to the chase with it’s opening paragraph:

Many individuals and organizations have made general statements about cloud computing, its advantages, and its weaknesses. It is important to understand, however, that the term “cloud computing” encompasses a variety of systems and technologies as well as service and deployment models, and business models. A number of claims that are sometimes made about cloud computing, e.g., that it “scales”, or that it converts capital expenses to operational expenses, are only true for some kinds of cloud systems.

Pretty much telling you to do your homework and not listen to the Marketing claims.

This section is actually quite good reading and I feel will be seen as controversial for some.

It describes as well as I’ve seen it done the  general cloud environment concepts such a public, private, hybrid .   It should also help alleviate the fear from some quarters of the IT department re their relevance as it points out you will still need IT skills. Yes that is obvious but it needs stating as this message is not coming across with all the marketing and we need to get rid of the FUD.

The statement about the significant to high costs to migrate to the cloud  plus the limitations on scalability using the onsite private model will be an interesting one for ‘Private Cloud’ suppliers to negotiate when faced with this. Interestingly enough an outsourced ‘Private Cloud’ is seen as having moderate to significant costs to migrate to the cloud and more flexibility in terms of scaling.

The community cloud model I’ve struggled with as a concept but I’ve started to appreciate where it can apply such as Colleges and educational institutes and charities but I still would look at the public cloud model first (That’s a discussion for another day though) .

The section on the public Cloud I feel is  out of date and lacking in detail. The generalisations made here are not applicable to certain providers and types of cloud solutions. When they talk about the private cloud it’s different as they are the assets of the organisation so it’s possible within limits to lump them altogether. As an example of my issues with this section is the statement on the risks of multi tenancy and removal of data. I for one have come across inappropriate data removal processes with Traditional Data Centre hosted solutions so this concern isn’t a new one and shouldn’t be presented as such. The security of the public cloud in many cases will far exceed that found on premise and with the maturity of some providers lessons have been learnt and controls are in place to mitigate perceived risks around the use of multi tenancy. The public cloud migration to the cloud gets a low up front cost rating. This makes sense as there is no initial capital investment unlike the ‘private’ model flavours.

The document then goes onto to look at other cloud environments which is where I feel it struggles and it is already out of date.

The SaaS model is obviously well understood after all it has been around a while and the depth of detail and relative lack of concerns voiced reflects this. Note the statement on Data Deletion says Require that cloud providers offer a mechanism for reliably deleting data on a subscriber’s request” where as in the Public cloud described in the General Cloud environment the tone is one that reflects more concern “As an example of this limitation, a subscriber cannot currently verify that data has been completely deleted from a provider’s systems”

Unfortunately the PaaS section is woefully out of date , quite abstract and does not take into account the newer players on the market like CloudFoundary and OpenShift or even at a stretch Elastic Beanstalk from AWS. To make matters worse Microsoft’s Azure doesn’t even fit their definition because of all the work involved with using their VM Role. If you look at a statement in the benefits section you can see what I mean

PaaS providers are able to Manage the lower layers and relieve PaaS subscribers of the responsibility for selecting, installing,maintaining, or operating the platform components. Infrastructure charges are implicitly present in PaaS offerings because PaaS consumes infrastructure resources in some form, but the infrastructure charges are bundled in the rates charged for the PaaS execution environment resources (e.g., CPU, bandwidth,storage).”

This is the case with Microsoft Azure but if you use say  use OpenShift this is not the case as you are responsible for ( As much as I hate using the terms PaaS and IaaS  it fits here) the underlying IaaS that the PaaS container needs to run on if you decide to use a non multi tenanted  flavour. The lack of portability section is also not right as in theory you can now with containerised PaaS move your application from one cloud to another if you are using the right set of building blocks  e.g mongodb , mysql or even take your PaaS container with you. This section is just plain inappropriate I could go on and on here but I still have another 40 pages to go .

The IaaS section has nice description about hypervisors though but the scope of control diagram will only apply to those providers who stick purely to the model described so AWS will not fall into this camp.

What I found odd when reading this though was the relatively appropriate recommendations for considering  these specific models which  didn’t quite sit well with the public cloud recommendations they inevitable go with. That will confuse I reckon.

Many of the issues outlined in the Open Issues section I also found odd as  most are not specific to Cloud computing. Latency is a concern wherever an application is hosted and when designing for the cloud measures to mitigate against latency should be taken into account. One thing you can do is place your clients closer by putting them into the cloud too just a thought plus the fact we are all getting used to the whole latency issue what with  the ever moving march of technology introducing gadgets like smartphones  etc . Network dependencies well I don’t even know where to start with this one every organisation experiences some sort of outage during the course of their business and there is a fundamental reliance on the network cloud or not.

My recommendation would have been look at you internal uptime and reliability, ask yourself how do you scale today when you need extra compute power  and then use these answers  when making decisions.

The problem with generalisations is the very fact they are generalisations.

I do like the concept of having a  standard format for SlA’s which could be use in competitive tenders as I have spent far too much time in the past comparing SLA’s etc. The problem with this though is that no cloud providers are alike in what services they offer.  Whereas if you’re looking for a traditional Data centre hoster it’s easy to compare that isn’t so easy today. Nice idea though.

The portability of workloads is I feel over stated it’s a matter of design if you want absolute portability then don’t use any of the non portable features which will mean you have to expend effort in not doing so and you really do need to think if that makes sense not to take advantage of what are some pretty cool albeit specific to a particular providers service. You could save development time , get access some awesome availability & durability services by deciding not to be ‘totally’ portable but have an exit strategy if you have to.

If you are just using Virtual machines there are already providers who provide the technology to allow you to migrate across clouds so the interopabilty between clouds is another out of date statement.

The other concerns seem to be all to be standard due diligence statements which the established Cloud providers have already addressed in some form or other. I was interested in the support  forensics one ( just because of my interest in It Security).

There are some typical costs included  which I find a strange thing to put in as it really does depend on what you are going to do . There is also an appendix covering roles and responsibilities.

This May have a ‘May 2011’ date on it but it is out of date already and manages to not really understand the market place. It does however have a good description of general cloud models but once it starts talking about SaaS, PaaS and IaaS it is on woollier ground as the market isn’t that clear cut anymore. The disjoin between the General cloud environments and the specific cloud models sections  is confusing. I would  hope that this draft is revisited soon to make it a more relevant guideline else there are going to be some long drawn out difficult conversations if this is where organisations start their journey to the cloud from.

Advertisements