Friday, 17 December 2010

Cloud Computing Does Not Compute

Two articles that attempt to show that Cloud Computing is gaining acceptance.  But one problem I have not seen adequately explained is one of access and inter-connectivity.

The first article linked (the easy migration of VMWare images to Amazon article) has a hint of what a major Cloud Computing impediment is: "The length of time to import a virtual machine depends on the size of the disk image and your network connection speed. For example, a 10GB image takes about two hours to import over a 10M-bps broadband connection. The conversion process is free of charge. But users have to pay for bandwidth for the upload as well as for storage and computing capacity, which are all charged at Amazon's usual rates."

There is a reason why companies continue to have all of their major applications installed in a centrally managed Data Centre.  Other than the obvious nature of central management, shared resources, leveraging infrastructure investment etc. etc. there is another reason to consolidate applications to a single Data Centre.  Inter-connectivity.  It is the rare application that is 100% stand-alone.  As a rule of thumb, the more important the database to the company, the more applications there are that interconnect with it.  To deliver a best experience that meets many diverse needs, what many people refer to as the ERP or accounting system (as an example) is usually a hodge-podge of different systems all working together.  Yes there may be a JD Edwards or SAP implementation that does 90% of the work, but that last 10% may be done by 30 or more other applications installed on other servers, and this 10% can be critical, like say the customer facing online shopping interface.

The more you try to tease out all of the tendrils that connect into your database, the more you realize how interwoven and interdependent all of the systems are.  Moving a central database to the cloud is like ripping out your spinal cord and putting it in a jar somewhere.  That will cause obvious issues to the original host.  So, if you truly need to maintain full functionality, then you have to move damn near everything to the cloud.

Well about just moving the big stuff, and setting up connectivity for the rest?  Well that ties into the second problem.  Bandwidth and connectivity.  Corporations pour a lot of money into their communication infrastructure to ensure application performance adequately meets the needs of the organization.  You may complain that what you have is slow, and that the company should make it better, but trust me it probably can be a lot worse.

A company controlled Data Centre will have a 1 GB or 10 GB backbone, or some variant in between that allows for high speed communication between applications, the interconnectivity aspect.  I do not want to know how much a 1 GB Internet connection would cost me to keep the performance the same, I already know astronomical is the description of the quote for that kind of service.  So if some apps are moved to the cloud, and the other apps are only connecting at 10 MB over the Internet instead of 1 GB over the local LAN, then application performance will suffer. The Cloud provider will likely offer 1 GB interconnectivity between the applications hosted (I would hope!), so therefore a kitchen sink approach migration is the only way to keep interconnectivity performance the same.

Now consider a company where the bulk of the users are local to the Data Centre.  Again, they will be accessing the locally hosted applications over a 1 GB connection.  Migrating those applications to the cloud and hosting them at the other end of a 10 MB Internet connection does not compute.  How can you do that and not severely affect response time?  It is going to be very app dependant on whether that drop in connectivity matters.  Just off the top of my head, I think it will.  A lot.  And I am completely ignoring the reliability of the Internet at large where large segments of the Net can drop off-line at random, with huge service availability implications.  Not even factoring that in.  I am assuming for the purposes of this post that the Internet is 100% reliable with no service affecting issues at all.

I will grant that deployments that utilize Citrix XenApp are less likely to have these users connectivity concerns, as the whole purpose of XenApp is to give high-speed LAN like performance to users connected over low-speed links.  But you have to be nearly 100% deployed on XenApp. But if you are not, then going to the Cloud involves two migration not just one.

And you know what?  The Cloud has to offer massive savings of 300-400% over existing (sunk, already paid) costs to justify re-architecting an entire organization's technology deployment.

Colour me doubtful that such savings could be realistically achieved while keeping performance the same or better.  Looking at my organization (and that we ain't that unique), I see such promises as entirely in the clouds.

No comments: