Part 2 - Your application would be a GREAT FIT in the Cloud if...

1. Your application is fairly isolated from other applications

Typical examples of isolated applications are CRM, messaging, and other custom built applications.  On the other hand, traditional ERP applications are tightly woven with others and hence might require re-architecting the application to fit the cloud.

Alternative: In most cases your application is probably somewhere between isolated and completely integrated with other applications.  In this case, here are some options based on the nature of the dependency:

1. Communication channel dependency - Create a distributable communication channel that is secure
2. Architecture dependency - Make a copy of the shared layer for the cloud
3. Single sign-on security - Upgrade single sign-on to support remote sign-on

If none of these options are feasible, then either both applications would need to be migrated to the cloud or both should remain as is.

2. Your application architecture is cloud friendly

Any application on an x86 platform would work well in the cloud regardless of the operating system.  If the application is on some platform other than x86 and you still want to go cloud, then you would need to re-architect the application to the x86 platform before you begin migration.

Also, if the online-architecture is web based or client server, then your application is more cloud friendly.  Moreover, if the online-architecture is heterogeneous from the batch-architecture, then your application is even more cloud friendly.

Alternative: If your application is on any other platform (such as Sun Sparc, Power PC, or Mainframe), then it might be a better candidate for managed hosting.  Another reason to opt for managed hosting is if your servers require software licenses that can only be tied to physical cores.

3. Your application security requirements are satisfied by FISMA compliance

Some cloud providers are FISMA (Federal Information Security Management Act) certified which ensures they are satisfying all the Federal security standards as measured by NIST.  In addition to FISMA compliance, security can be further enhanced by engaging managed services for security on the cloud (like netForensics).

Alternative: If it is necessary for all the data and/or hardware to be located on-site, then a private cloud or a public/private hybrid may be an option.

<- Back to Part 1 - Your application may NOT YET be ready for the Public Commodity Cloud if...

Part 1 - Your application may NOT YET be ready for the Public CommodityCloud if...

1. Your application demand is very stable and doesn't fluctuate much
If your servers are not under utilized, then you are better off keeping things the way they are, unless you want to plan for disasters or other unplanned events.  This is because cloud pricing models are geared for elastic computing. It would be more expensive to provision 4 VMs than to run 4 servers in-house.  The benefits of provisioning fewer VMs and using burst capabilities will only be realized if such demand fluctuations are expected.

Alternative: Look for cloud providers (like Terremark) that price by usage (regardless of the number of VMs provisioned).

2. Your application's licenses can only be tied to physical cores
Many software licenses have not yet made the shift to the world of virtual machines.  For example, Oracle licenses can only operate on a fixed physical core, whereas virtualization technology was developed precisely to separate the physical layer from the software layer.  If Oracle is installed on a VM, the VM would be assigned to certain physical core(s) at one point in time and some other core(s) at some other point in time, which would violate Oracle licensing rules.

Alternative: Look for cloud providers (like Savvis) that have managed hosting servers which share a VLAN with their cloud.  In this way, Oracle can be installed on the managed hosting server while the rest of the application can be deployed on the cloud.

3. Your application stores a very large amount of data on the cloudWith storage disks getting cheaper by the day (1TB for $80), it is becoming increasingly cheaper to store large amounts of data in-house rather than pay for cloud storage every month.  This is because cloud storage is typically priced per GB per hour.


Alternative: Share data storage with other customers using Symform (or any other similar technology) that breaks up the data into a number of encrypted parts and then stores them in the other customer's data centers.  This gives the benefits of elasticity without paying too much for it.  It also increases security of data in the cloud because no one can use the data without having all the parts and being able to decrypt all of them.

4. Your application transfers a large amount of data in or out of the cloudMost cloud providers price their bandwidth by GBs transferred per month.  This would be very costly for applications that stream large data files on a regular basis.

Alternative: Look for cloud providers that price by Mbps of dedicated network throughput.  This is typically found in enterprise cloud providers like Savvis and Terremark.

5. You do not have the capability of managing your VMs any better than you do your serversThe ease of provisioning VMs as and when necessary can also lead to VM sprawl if not managed appropriately.

Alternative: Subscribe to a cloud management console that can not only auto provision VMs when necessary, but also schedule VMs to be turned off after use.  Gravitant's cloudMatrix uses predictive analytics to create dynamic workload schedules that change over time based on historic demand trends.

Go to -> Part 2 - Your application would be a GREAT FIT in the Cloud if...