I'd like to see a comprehensive list (or decision-tree?) of what ideal application properties pre-dispose apps for being well-suited to run in a cloud. And, for that matter, what qualities might potentially disqualify apps from running in a cloud as well. (BTW, a great Blog by John Willis, Top 10 reasons for not using a cloud, was another initiator of my thought process)
Customers of mine are attracted to the value prop of a cloud (or a "utility" infrastructure)... but need guidance regarding what apps (or components) should be candidates for these environments. And recent conversations with prominent analysts haven't helped me... yet.
I'm also surprised that consulting/service companies aren't all over this issue... offering advice, analysis and infrastructure "profiling" for enterprises considering using clouds. Or am I missing something?
So, with no further ado, I've begun to jot down thoughts toward a comprehensive list of application properties/qualities where we could "rank" an application for its appropriateness to be "outsourced" to a cloud. I've chosen to annotate each factor with a "Y" if the app is appropriate for an external cloud, a "N" if not, and a "M" if maybe.
- Y Apps with highly dynamic (hourly/daily/etc.) or unpredictable in compute demand.
A cloud's elasticity ensures that only enough capacity is allotted at any given time, and release when not needed. This avoids having to buy excess capital for "peak" periods.
- M Apps where compute demand is "flat" and/or constant.
Not clear to me if it makes sense to outsource an app if it's demand is "steady-state" - maybe just keep it in-house and purring along?
- M Apps where demand is highly counter-cyclical with other applications
In other words, if an application runs out-of-phase with other apps in-house (say, backup apps that run in the middle of the night when other apps are quiescent) then it might make sense to keep in-house... they make better use of existing capital, assuming that capital can be re-purposed.
- Y Apps that are very "big" in terms of compute need, but which "go away" after a period of time
Such as classic "batch jobs", whether they're daily trade reconciliations, data mining projects, scientific/computational, etc.
- N Apps that are "small" and constant in nature
Apps such as Edge apps like print services, monitoring services etc.
- Y Apps that are part of test environments
Apps - and even entire environments - which are being tested prior to roll-out in production. This approach eliminates costly/redundant staging environments
- M Apps for dev and test uses
For example, where environment and regression testing is concerned, and environments are built and torn-down frequently. However, certain environments are inherently bound to hardware and/or tested for performance, and these may need to remain "in-house" on specific hardware (see below)
- N Apps that are inherently "internal"
Such as internal back-up software, "edge" applications like printer servers, etc.
- N Apps that are inherently bound to hardware
Such as physical instances of software for specific (e.g. high-performance) hardware, or physical instances remaining so for scale-out reasons. Also, physical instances on ultra-high-reliability hardware (e.g. carrier-grade servers) .
- N Apps needing high-performance, and/or time-bound requirements
such as exchange trading algorithms, where response and deleay (even down to microseconds) is critical, and needs to be tightly monitored, controlled and optimized
NB: Also see an excellent Blog by James Urquhart on regulatory issues in this space.
- M Apps where data must be maintained within (or outside of) specific county borders
Data within certain borders may be subject to search/access by the government (e.g. Patriot Act). Data may be required to be maintained within sovereign borders... or it may be preferred that the data explicitly be maintained outside of sovereign borders to avoid such searches.
- M Apps requiring tight compliance/auditability trails
Ordinarily, I'd give this a "N", but some tools are coming out that help ensure compliance for apps that exist in the cloud. Apparently HIPAA regulations essentially prohibit use of clouds right now. Stay tuned here.
- N Apps manipulating government data, e.g., where laws require direct data oversight
Many government databases are required to be maintained within government facilities behind government firewalls.
- N Apps where software licensing prohibits cloud
e.g. some software licensing may be tied to specific CPUs; some licensing may not permit virtualization (as is found in most clouds); certain licensing may not permit use outside of specific physical domains.