Killing the cloud with success

Today, there are two threats to cloud becoming a reality.  First are the end users.  Second are the vendors. 

End users, especially at the division layer or in remote offices, are driven towards cloud based solutions, especially SaaS, like moths to a flame.  Any program that works on per user per month basis must be better than this old dumpy client /server or host based system.  Look, it has this cool spinning widget and it works on a smart phone.  The attraction is understandable.

At the same time, they often don’t look into core issues like “what is the security model and does it meet corporate requirements”, “does it meet all my functional requirements” and “how does it integrate with my other systems.”  That latter problem is the killer.

While tools like IBM CastIron can solve a lot of problems, most clients don’t get to the integration discussion until after they have already purchased the cloud based solution.  In fact, in the rush to get to the cloud solution, clients are willing to go to much simpler and less rich environments. 

IT departments would be served well to understand how communicate better with their business constituents.  IT departments often take the requirements on face value and then build the 98% solution at 120% of the cost.  Cloud solutions are usually 80% solutions for 50% of the costs often leaving out the hardest and most costly components.  If IT departments took it upon themselves to really partner with the business, maybe they could get to 95% solution at 50% to 70% of the cost.  The key will be identifying the cost driving factors in the solution.

Identifying TCO at a feature / function level is not easy; however, it is critical.  It is the real role of a good architect and especially the solution or application architect.  Simply telling the constituent all the parts they need is not enough.  You have to be able to understand the short term, long term, and cost impacts.

Vendors are not helping either.  Someone referred to the problem as “cloud confusion” in random blog.  Everything that is available on the internet is called a cloud solution.  There is a huge problem with calling backup storage  “cloud storage.”  What is dynamic about it?  What is virtual?  The Apple iCloud is a little better since does let you for FEE use Apple’s copy of your music from their library by just putting a pointer in and avoiding the storage. This is double dipping since they charge you and have to give you less storage, but we also pay $45 to get a better seat on the airline.  PT Barnum said something about that.

Equally confusing is SaaS.  You’d think that SaaS means a software solution that is built on IaaS and PaaS and multi-tenancy, but not always.  You’d even expect it to be multi-tennant.  It turns out that many of the SaaS solutions in the market are really just client/server systems on the internet that are billed by user/month or some similar consumption based model.  Bob Moul wrote Demystifying SaaS vs. Cloud  to help identify a SaaS product vs. a not SaaS products.

Most consumers of cloud are not worried whether it is really cloud.  They only care it gives them flexibility and outcomes they desire.  When designing any solution, keeping flexibility and outcomes in mind is always a good idea.  Too often, we get trapped in the details to the point of making everything too complex.  Worse, the complexity feeds on itself, too.  There are worse things than calling an analog by the wrong name.

Good news is that cloud will go eventually go away.  Not that it will cease to exist, but it will cease to be discussed.  It will be the default architecture.  Today, everyone is designing for the cloud, the true cloud, with all the assumptions of relocation, compression, and smaller virtualized servers.  Until then, there will be a lot of work getting us to that promised land of low cost elastic solutions with high performance and ease of use.  Cloud Encapsulation will let us bring many of those benefits to non-cloud applications, too.