Posted by Paul Armstrong in Internet on Monday, March 2nd, 2009

Could this be the year that cloud computing becomes important to your business?

This year is the Chinese Year of the Ox, some are also saying that this year will be the year of the cloud. If you want to confirm who some are then go no further than a Google of “year of the cloud”. For many however, the technology, along with the term, is still maturing, and the thought that it could define their year is the farthest thing from their mind.

If we accept that the cloud offers all that we might expect in terms of a computing platform (ie, computing, storage, network, and even functionality when we consider SaaS (Software-as-a-Service)) then by trying to understand some of the contextual characteristics we might better understand if the cloud can offer value for money. To paraphrase another part of Chinese culture we live in interesting times and while the cloud may not define our year, the economic crisis for many already has. As such, value for money is a quality that we and our customers will increasingly look for in solutions.

The remainer of this article identifies the contextual characteristics of the cloud, and then ends by determining whether these might offer value for money.

Contextual characteristics of the cloud

If you want a definition then these days we turn to Wikipedia. We must always read anything on the web with caution. However the work I and others have been doing with the cloud and SaaS means that the cloud computing entry, for us, defines what cloud computing is nicely.

Beyond being a computing platform accessible over the internet, below are what we think are the defining characteristics of the cloud at this point in time. Noting that the last one (portability) may define more what the cloud is currently not, but it is highlighted because it is important to understand when trying to determine the value of the cloud.

Real time scalability

To explain this term we can go straight to the name of one cloud vendor product: Amazon Elastic Compute Cloud (Amazon EC2). The elastic part of the name captures this cloud defining aspect well. As your need grows, so too does the computing resource allocated to you and, conversely, shrinks when it is not required. The benefits here are obvious under the right circumstances. Consider the start-up that thinks it has a good idea but cannot afford a significant investment in processing and storage until it has a comparable user base. With real time scalability characteristics they don’t need to worry. Instead they define the boundaries of how big and small they want their system to be and only when their user base grows does the system scale out.

To people that have thought that the cloud is ASP (Application Service Provider) or FM (Facility Management) by another name, then they should be made aware of the real time scalability or elastic characteristic of true cloud offerings.

Our partner Google has a cloud with real time scalability, as will the Microsoft Azure platform when it becomes available.

Defined by contract

Wikipedia notes that cloud computing resources are provided as a service. To me this understates an important cloud defining aspect which is that access to cloud resources will be defined by contract. Furthermore, for many cloud users, especially domestic and small to medium business users, human interaction with the cloud vendor is unlikely with most contracts being completed on line.

Whether this is an issue or not will be down to the client organisation. Outsourcing is not inherently evil. Noting that outsourcing was popularised in the early 90’s by organisations wishing to get better service and value than they perceived they were getting from internal IT departments. However, with a relationship defined by contract, when times get tough there is no ability to evoke mottos like work like you own the company and one for all and all for one.

Remote in many ways

Being defined by contract underlines and promotes the remoteness of the cloud. Important implementation detail that supports non-functional requirements, such as scalability and reliability, are presented to the client as attributes of the service level agreement. Users of the cloud are unlikely to be aware of how such features are implemented technically. As Wikipedia notes, knowledge of, expertise in, and control over the technology are not features of the cloud for the client. This also extends to the geographical location of the cloud service. None of which are details that the cloud vendor is inclined to expose unless it serves them as well as their clients.

Again this is not evil. Indeed many clients may dream of a relationship with an IT provider that has its non-functional requirements defined in terms that the business can understand (“it needs to be running all of the time”) rather than what an IT department might tell them (“the high mean time between failure (MTBF) of the hardware coupled with our redundant, N+1, design means that the failure you experienced was outside of our expectation”).

However, geographical location may become a sticking point for some. The additional latency for New Zealand users accessing a cloud in Australia, US or even Europe may be unacceptable.  Not to mention issues of sovereignty and privacy that may alone be enough to remove the cloud from any short list of possibilities.

Portability, or not

To describe portability, think of a nirvana cloud computing world where all cloud services can be used interchangeably. If one cloud vendor is not available, or not efficient enough, a system would simply and automatically move to a second cloud provider, seamlessly and while we sleep.

The reality here is that a system built and deployed to one cloud is unlikely to be immediately portable to another cloud. The effort required might be analogous to moving from a Microsoft SQL Server database to an Oracle database. Both implement ANSI standard SQL and the salient concepts of relational databases. However don’t underestimate the cost and effort of such a move. The same is currently true of a move between cloud vendors. Some deployment switches will be easier than others, but just like a database vendor you may choose one cloud over another because of its proprietary features, not in spite of them.

Value for money?

The real time scalability characteristic may be a killer feature for some organisations. In the cloud world, deploying and starting up a small application can be measured in 10’s of dollars. Compare that to the old fashioned way of buying a server, connecting it to the internet, and sourcing and employing the expertise to do so. Real time scalability can offer true value for money to entrepreneurial organisations that are interested in testing their business ideas. At the other end of the spectrum are organisations that wish to deploy a fully featured and fully utilised system on day one of its life. Organisations like this are likely to be intimate with their user base and understand their projected growth and, as such, scalability requirements. In these cases they may find that they can provide their own economies; virtualisation being applied to in house application deployments would be one example.

As already explained, having a relationship to your IT provider defined by contract may be ideal for some customers. Today businesses can be just as much about information technology as they are about their core business. Banks are a good example of this, employing as many IT professionals, if not more, than they do tellers or traders. However, that has partly been driven out of necessity rather than desire. Consider the number of organisations that also house their own basement boiler. They don’t want a reputation as a power generator. They have just found it more efficient to in-source that aspect of their power needs. Given the availability of cheap, reliable, and, if necessary, real time scalable power today, however, I think any organisation would assign the boiler room to the scrap heap in favour of getting on with their core business.

Being remote, as highlighted, can cause issues. However, for every problem there is an opportunity. While an application might exhibit some additional latency to New Zealand users, it may be that the target audience of a New Zealand owned application is the larger markets of the US and Asia. The same is true of sovereignty. Banks don’t just house data centres in the Channel and Cayman isles because they think their staff will like the weather. There can be legitimate reasons for wanting your data to fall under the jurisdiction of other countries’ laws.

Portability, or lack of it, may also be a value for money issue in the longer term. However, choosing a cloud provider is much like choosing an operating system; something that organisations do every time they deploy an application. Just as we can design and build for operating system portability, there are patterns and techniques that can be applied to make systems more portable across the cloud.

In summary

The cloud has arrived and has defining characteristics. If all that happens this year is that people learn this, then that may be enough to make it the year of the cloud. In learning about the defining characteristics, many may immediately dismiss it, knowing, or feeling, that it could not be appropriate for their organisation. Others, however, may find that the issues identified are not applicable to their application or are out-weighed by the benefits and even the value for money proposition. This year they may consider the possibility of using services in the cloud or even building and deploying applications in the cloud. If that happens, and they have never done this before, I think they would reflect that this was the year of the cloud.