You Are Not Even Wrong About the Cloud - Part 3
By RickG on Mar 21, 2014
The next area of Cloud computing subject to the distorting effect of orthogonality has to do with the way many people want to start to use the Cloud. The most common starting place is to try to move existing applications to the Cloud.
People want to migrate an existing application to a new environment. Migration, by its very nature, is orthogonal. In a migration effort, you invest effort and resources and take on risk to achieve the goal of having the same application you used to have. So there are costs for the migration effort, without an direct benefit over what you have now from that effort. Of course, there are other benefits that come from a migration, such as a simpler or most cost-effective environment, but these are not directly related to the migration itself. This is the definition of orthogonality – benefits from one area and costs from another.
However, the hope that a migration to the Cloud will be effortless is founded on a basic misconception about the Cloud. The Cloud is not magic – reduced costs are not suddenly available through magic Cloud pixie dust. Although Cloud vendors may get their underlying components at a bigger discount because they buy larger quantities, this savings is offset by the need for these companies to make a profit on their services.
The way the Cloud saves money is through automation. Cloud vendors automate various IT maintenance tasks and operations, and, by doing so, can scale with less expense. Pretty much all the cost benefits from the Cloud stem from this core fact. Even a technical feature like multi-tenancy is a way to automate the support of many individual tenants on a fixed pool of IT resources.
The use of automation comes with a corresponding loss of flexibility. Automated procedures expect fairly standardized environments, or they may not work properly. The more productivity that a Cloud offering provides, the more automation, the greater the loss of flexibility.
Take something like database backups. Although both your Cloud vendor and your IT staff could do backups, backups have to be a consistent in order to properly restore the database, so only 1 set will be useful. And since your Cloud vendor has automated processes in place to perform the restore in the event of a failure, your backups are not useful if you want to take advantage of the productivity increase brought based on eliminating this maintenance task.
Not having to do backups may not sound like a loss of flexibility, but, in order for the automated backups to work, you will have to give up control of some facets of the environment that must be consistent for these automated backups (and restores) to work. You will no longer have unfettered DBA access. (You probably won’t need it, but you almost definitely want it as a broad philosophical requirement.)
There are many other tradeoffs, and the more automation involved – the greater the productivity benefits for you – the greater the loss of flexibility.
It is important to realize that there is nothing inherently wrong with the reduced level of flexibility. It’s not functionality that is limited – it’s how you implement that functionality. You may have to go a slightly different path to get to the same result.
That last sentence brings home the almost inevitable pain (and failure) in starting your journey to the Cloud with a migratoin. You didn’t design your system with the standardized cloud platform in mind, so the way you implemented your application very well may not match the choices you have in the Cloud.
OK, that was too kind. If you are looking to get the most in terms of benefits from the Cloud, you will also get the greatest limitations, requiring the most modification. You have an unpleasant choice between a more significant migration effort or choosing a level of Cloud computing with fewer productivity benefits, such as Infrastructure-as-a-Service. The less productivity, the more this newfangled Cloud looks a whole lot like the decades-old option of hosting. And if you didn’t go to hosting in the past 20 years, tacking the word “Cloud” on it probably won’t change the outcome of your consideration.
It’s a trade-off, as are so many things in life. Not necessarily a bad one, as with the move to GUIs more than 20 years ago, but one with benefits and costs, like all tradeoffs. And remember what ended up happening in that sea change brought on by GUIs. The overwhelming majority of applications did not simply get a ‘pretty face’, with green screen fields being replaced by text entry boxes.
In the end, people didn’t migrate applications – they replaced them. Of course, in this process of replacement, developers could make all kinds of other improvements, so the end result was better applications for the GUI environment and better applications in general. And we haven’t looked back. So the initial orthogonality – mismatch between user desires and IT pain – resolved into a better overall environment.
But there is an even more fundamental orthogonal situation, having to do with costs. The good news is that yes, most organizations can reduce costs with Cloud computing. The bad news is that the savings do not come in the way that most companies expect, creating another gap which will be explored in the next blog post.