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.
Dynamics/Cyclicality
- 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.
Posts
4 comments:
Ken- thanks for the post. When I worked at VMware, one of the questions we often (always?) heard from customers is "What should I virtualize?" As the cloud computing market develops, customers are asking "What should I host in the cloud?"
I think it's interesting to watch the cloud market develop because there are many parallels w/what we've seen in the development of the virtualization market.
As to your specific points about what should/shouldn't/maybe should be hosted in the cloud, here are some additional thoughts:
For apps where compute demand is flat, cloud may still make sense for a variety of reasons. If you can reduce the total cost of maintaining that system, maybe it's a good move. Going to the cloud also provides some insurance that if (for whatever reason) compute demand increases, you have flexibility to respond.
Another thought: it's important to have some criteria or a decision tree to determine which apps are cloud-worthy, but this implies that a customer has a good handle on the inventory of apps and servers in their environment.
In my experience, many IT organizations may know how many servers they have, but they have little idea as to what apps are running on a large number of them, what other systems they depend on, will something important break if they shut it down, etc
There are companies like CIRBA and VMware who have tools that allow IT to survey an environment and identify systems that could/should be virtualized. The market will need the same kinds of tools for assessment of cloudworthiness.
John -
I agree - in my experience, there is a "larger" initial issue companies frequently have: exactly *what* apps they have in the first place, how many they have, which servers are "orphans" etc. Inventorying the data center(s) are actually the first step in the process. Pathetic, but true :)
Hi! Your blog is simply super. you have create a differentiate. Thanks for the sharing this website. it is very useful professional knowledge. Great idea you know about company background.
Increasing your web traffic and page views Add, add your website in www.itsolusenz.com
Though much insurance software on cloud has been very successful in many places, some place it do get fails and the company sees a major drawback because of it.
Post a Comment