Stakeholder: We will definitely not accept a solution in "the cloud".
Me: What about a private cloud?
Stakeholder: What's the difference? There is no difference...
Me: The difference comes down to factors like ownership, legalities and support model. Can you help me understand which parts of 'being in the cloud' your company's policies don't allow so I know what the restrictions on the solution might be?
After reading an article called Cloud Concepts and the Impact on Business Analysts today, the above excerpt of a conversation I had with a stakeholder in a recent project came back to me.
For background: In this project I was performing a combined business analysis and project management role for the scoping and development of a Request for Proposal (RFP) - this project in particular was really interesting and challenging because it involved fifteen different companies and facilitating the agreement of a unified solution approach for a middleware platform. And I love interesting and challenging!
In this scenario certain decisions had to be made and agreed upon by all before the RFP could be released - an objection by even a single company could essentially place the entire RFP project at a standstill. One of these decisions was 'where' the data would be hosted - in the cloud, at a T1 level hosting provider or across all fifteen sites' existing data centres (eeek!!!).
During requirements gathering I sat down with various technical stakeholders to better understand any corporate policies around cloud computing and/or hosting requirements that might be show-stoppers.
The conversation excerpt above was with one of the stakeholders that had very strict policies on where data and infrastructure would reside. It struck me that the Stakeholder (a person well-versed in technical aspects) didn't understand the difference between a public and a private cloud and I thought it might help other project managers or business people, who are just delving into a cloud based project, to understand the key differences so they can help faciliate a decision on using one cloud deployment model over another.
What is a Private Cloud and what is a Public Cloud?
First up a quick summary of what private and public clouds are for the purposes of this post:
- Private Clouds are technology solutions owned by and services provided by your own organisation (or parts thereof), that may be hosted internally i.e. in your own data centre, or externally i.e. hosted by a third party but you retain all rights to its use, except those governed by the third party's own terms of service for the infrastructure/services they provide as part of the solution.
- Public Clouds are technology solutions and services owned and provided by a third party. Usually within this service provision you only have ownership rights to the data that you submit to the service.
Note that these statements are fairly generic and may not apply across all solutions, but we'll use those concepts as the baseline for this blog post.
Cloud Selection Factor # 1 - Legal
If there is anything that can stop a project faster than the speed of light its the legal team. In a public cloud scenario you are generally signing up to a generic terms of service that is legally binding - to you and to the provider (but usually more in favour of the provider than you!). Now I am not a lawyer in any sense but for most RFP projects I have to keep a keen eye out for, and identify, anything that may cause the project to fail before the draft RFP even gets to the legal department for review.
One great recent example of legal terms skewed towards the cloud service provider was the change of Terms of Service (ToS) by Dropbox in February 2014 - (Dropbox is a cloud based file sharing service). They changed their terms of service to include a binding arbitration rule that you could only exit out of if you submitted a separate form within the first 30 days of accepting the terms. Essentially they say that by agreeing to the ToS (i.e. using their service) there are no class actions allowed and you agree to abitrate using the American Arbitration Association (where does that leave international customers?) in a small claims court. There is a good non-legalese summary of this issue on Legal Geneaologist site if you're interested.
Obviously if you setup a similar file sharing service for your company in a 'private' cloud then this issue is a non-issue. But it will generally cost more on a per-user basis than the efficiencies created by hundreds of thousands of people using the same service in a public cloud scenario.
Cloud Selection Factor # 2 - Ownership
Ownership is a big one in this world of IP, trademarks and lawsuits to boot!
Below is a diagram developed by the US National Institute of and Technology (NIST) which demonstrates their proposed typical cloud architecture model (download the full PDF document "NIST Cloud Computing Reference Architecture"):
In a private cloud there are different ways ownership could be sliced and diced. For example:
- Cloud Consumer - these are your staff, contractors and any other authorised personnel that use the solution so the 'owner' would usually be your company
- Cloud Audit - your company or maybe an independent third party that you employ to audit the solution regularly
- Cloud Provider - you might outsource Cloud Service Management or your IT team manages it. You might split responsibilities depending on your IT operations model e.g. Cloud Service Management to the outsourcer and security/privacy to your architecture team.
- Cloud Carrier - this could be a private network link between sites and the data centre where the solution is hosted, or a public link to the solution accessible from any internet connection for example.
- Cloud Broker - like the provider you can slice this to internal or third parties as you like, for performance and cloud delivery.
In drastic contrast, in a public cloud everything except Cloud Consumer would be more likely under the ownership and control of the third party service provider (or multiple third party services providers - some of whom you have no idea who they are).
For example, cloud providers almost always have a clause in their T&Cs that says they can terminate your access at their discretion or for breaking rules 1,2,3. Does anyone ask what happens to your data when this happens? Can you extract all those emails or financial records and export it into a reasonable, accessible format for legal accounting purposes?
The interesting part here is data ownership - typically in any cloud deployment model you send/upload/import/create data within the Cloud Provider's environment. In a public cloud you usually retain ownership of that data but often have little to no control over where they store it - remembering that data can 'exist' in mutliple forms including in-use data, backup data and replica data for example.
Add to this different laws for different jurisdictions - for example in the EU, formal requests for data access must be made by law enforcement agencies. In the US they hark back to the days of cowboys where law enforcement can essentially stroll on in and then trot on out with the servers your data is stored on.
The control over where the data is stored is often a sticking point for government agencies and larger enterprises with strict policies around their IP.
However, contrary to popular opinion in government, it isn't expressly forbidden (at least at a federal level) for government agencies to use cloud services. It depends on numerous factors though - there is a great document called Privacy and Cloud Computing for Australian Government Agencies (.doc) that summarises the key boundaries and issues to overcome.
Likewise in a corporate environment, the first answer you get might be 'no way, no cloud' but when you dig further and identify the specific blockers you can develop a case around the most appropriate cloud model, not just the solution 'we've always stuck to because someone said no cloud'.
Cloud Selection Factor # 3 - Support Model
On the surface this one is pretty simple - who owns support of the solution, who provides support and what types, and under what service level agreement does it sit.
Support is a bit like Jaws though...dah-dum, dah-dum, dah-dum...it creeps up on you when you least expect it ;)
In a private cloud you can essentially, within the limits of cost, staff and corporate service level standards, set your own support model.
In the public cloud you are usually at the mercy of a generic support model based under set scopes unless you pay for premium support or a higher monthly/user cost. For a simple 'service availability' example:
- Telstra's Office 365 service - has three service levels (Gold, Silver, Bronze). At the Bronze level they allow for approx 8.76 hours of downtime per year (99.9% service availability) versus 52.56 minutes at the Gold level (99.99% service availability).
- Amazon EC2 - has one level of service availability they use "commercially reasonable efforts" to stick to - 99.95% (approx 4.38 hours).
- Google Apps - similar to Amazon with a single service availability level of 99.9%.
But the Jaws part comes in when dealing with support - what documentation is available, how responsive is the service centre, can you escalate issues (for free or for a fee) to get priority attention - and so forth.
What do you think - are there are other key differences you have encountered in a private Vs public cloud project decision?