I have talked about in the past that cloud decisions are not made in vacuum, there is a definite tradeoff of pain vs gain.
On the gain side are obvious reductions in capex, opex and even increased business flexibility (by making IT available very easily so that more things get done).
On the pain side are increased requirements for standardization, increased application model change, and risks (perceived or real) that come with increased sharing.
I have also talked of the fact that IaaS, PaaS and SaaS are not one thing. I will elaborate on it in more detail in a later post (gotta write it!), but as I alluded to here. For example, there are three PaaS models I see:
- Pattern based deployment, a la IBM Workload Deployer
- Standardized Shared but conformant to current application structures, such as Relational-Database-as-a-Service
- Standardized Shared but requiring new application structures (i.e. rewrites to take advantage) such as Google App Engine's view of databases.
So the key question for all of us is: how linear is the pain/gain curve? Is it linear, is it above the line, below the line? I would be very much interested in your views here.
Excellent, I am glad that I found this. Certainly there is going to be some pain in moving up the slope, but there is gain to be had too. The trick is to get more gain for the pain, and the way to do that is reduce the pain while preserving or enhancing the gain. Some ways to reduce the pain in moving to SaaS is to migrate your code with minimal changes. If you stay with single tenant software then you have the added pain of virtualization and if you have thousands of tenants the cost and headaches of thousands of instances. If you convert to Multi-Tenancy, your choices are to modify your code to incorporate tenant isolation, or you must convert to one of the Multi-Tenant PaaS like Force.com, or you can use a middleware approach like http://www.corenttech.com does with minimal code changes and maximum standardization.
Posted by: Moliver | June 14, 2011 at 04:15 PM