In my discussion of the Whole Cloud, I assumed as fact that a mature cloud computing infrastructure leverages all kinds of clouds—SaaS, PaaS, and IaaS; public and private; external and internal. Given the amount of energy put into arguments on the subject, it's obviously not a given to most people. Today, I want to talk about how these different "pieces of cloud" can be integrated together from a decision-making perspective.
First, a pre-requisite to this article is Simon Wardley's presentation, "Why It Matters". If you have not yet seen it, you should watch it before reading the rest of this article. I firmly believe in his argument around the inevitability of cloud computing for the enterprise, in particular public, external cloud computing.
As Simon notes in his presentation, however, not all IT functions are yet suitable for commoditization. Among those that are suitable, some are more suitable than others. It's this range of suitability that demands a range of "cloud" solutions. I put "cloud" in quotes because we can debate just how cloudy different components of the Whole Cloud are until we are blue in the face. In fact, I have always argued that a private, internal cloud is not really a cloud at all. Nevertheless, I still consider it part of the Whole Cloud.
The Range of Suitability
The most cloudy and best-understood form of cloud computing is public cloud software as a service (SaaS). These are pre-packaged software components like Salesforce.com and Xero that are delivered entirely over the Internet. You go to their web sites, sign up, and start using them right away. Most IT activities, however, are not so well defined as to be supportable by a SaaS model. That's why IT spends so much time crafting custom software solutions.
The least cloudy form of cloud computing is the private, internal cloud. Running on dedicated hardware within your own data center, the private, internal cloud attempts to give a cloud-like experience to internal stakeholders while maintaining the control inherent in internally managed systems. Any IT activity is suitable for the private, internal cloud. It's extraordinarily inefficient, however, to execute most IT activities in such cloud.
That means most projects fit somewhere in between.
There are three basic factors (each with many nuances) that dictate the suitability of a project to a specific cloud service and deployment model:
- Compliance and risk management
- Strategic value of customizations
- Integration options for external dependencies
Compliance and Risk Management
The functions supported in your system may carry with them external compliance requirements. If peripheral application functionality is what brings the system under the domain of some external compliance, you may want to strongly consider dumping that functionality. With many systems, however, you simply must adhere to an external compliance framework and that means the demands of the compliance framework place the primary constraints around how and where you can deploy an application.
Being subject to some external compliance framework, however, does not inherently mandate deployment into an internal data center. Some frameworks specifically require deployment on bare metal that you own; most can actually be addressed in a cloud environment—even a public cloud environment—with proper controls in place. One thing to worry about, however, is that lawyers will almost invariably say "no" wherever there is not total clarity. Don't let lawyers drive your business decisions.
Risk management is another aspect of compliance because it is often represented through internal compliance frameworks. In addition, any external environment—public or private—is inherently riskier for the deployment of any application because there's greater uncertainty about how the third-party is managing the system. Internal compliance frameworks must be flexible enough to adapt to changing business needs without introducing unnecessary risk. The inherent risk associated with external deployments must also be taken into account with controls put into place to mitigate those risks.
Strategic Value of Customizations
The more "custom" a solution is for your business, the less suitable it is for any kind of utility computing. The more customizations you introduce, the more expensive the project is both in development and ongoing operational costs. A CRM system is a perfect example of a system that should almost never be customized. It's a very well understood problem and if you are doing it different from everyone else, chances are you are just doing it wrong. There are times, however, when introducing a customization represents a competitive advantage for your business. When evaluating features for a project, you should therefore view anything that is specific to your business with suspicion. If you accept the customization, you should know exactly how it gives your organization a competitive advantage.
Integration Options for External Dependencies
Sometimes you need to get data from or provide data to an external dependency (external meaning another system, not external in the cloud context). When that system is based on a services-oriented architecture, you don't have any integration issues. In many cases, however, you'll have to integrate with systems that weren't designed to be exposed to the Internet or easily support external integration. Those systems will naturally constrain your cloud options and increase the tendency towards custom solutions even when business needs don't require it.
Where Should My Project Be Deployed?
The ideal cloud deployment is external, public, SaaS; the last choice is an internal, private, non-cloud bare metal or virtualized data center (VDC) solution. Based on customization and integration needs, you should look first to SaaS, then PaaS, then IaaS. Based on compliance, risk, and integration requirements, you'll look first to public+external, then private+external, then private+internal. Drop the VDC altogether and limit bare metal deployments.
On other words, I am saying that your default position when faced with a new project is to look for a SaaS solution. If no SaaS solution exists or you require customizations that provide true competitive advantage, look next to PaaS. Finally, if PaaS still isn't cutting it (and more often than not, it doesn't), drop down to IaaS.