As I will begin doing more posts on and around cloud computing in general, and Windows Azure in particular, I’d first like to give my view on when something is cloud and not.
Why? Well, it’s not the first time a word gets status. It gets hot. It gets overused, overloaded and obfuscated. Vendors, consumers, service providers and others might not always agree what cloud is. It will get slapped on, belted down or fuzzily added to an existing product or service to make it more “today”. I might not agree. Others in turn may think I’m wrong. It will add to the overall confusion. So, to hopefully help provide clarity (but potentially adding to the confusion), when do I consider something to be “cloud”?
There are a couple of characteristics that I would look for when it comes to cloud.
Or On-Demand. I would assume that I could scale up and down. At any time. I would assume that the procurement process for another server, piece of service (accounts, users, databases etc) is immediate (or next to). Same when scaling down. I would expect to be able to manage this elasticity myself.
Elasticity is not “I have a cold stand by server I can bring online”. Elasticity is “I need 10, 20, or 100 new instances and I need them for two days”. The dynamic capacity does not have a defined limit.
I would expect that the service uses some kind of pay-per-use charge model. How I use the service would be measured. How many hours have I been using it? How many GB of storage? How many MB transferred? How many connections opened? How many customers on boarded? How many users? – That sort of thing.
I would hope not (and this one is on the fence) to have to pay for underlying software in the form of procurement or running licensing. It would be included in the service. However this very much plays to the Software-as-a-Service or Platform-as-a-Service (PaaS) rather that say Infrastructure-as-a-Service (IaaS). In the latter I would of course have to handle licenses myself.
I would expect that I do not need to care about underlying hardware. I wouldn’t need to know the cost of purchasing it nor how it is set-up or configured. I wouldn’t need to specify how my machine is built. Even if I do choose the size of the machine, that’s not really my machine, and I can change that at any time.
I would expect the environment, as far as the service or servers go, to be fault tolerant. If hardware fails, or some service needs to be performed, I would assume it to be transparent to me and not effect me or my service.
If someone calls their offering a cloud service, and it does not fulfill these things I would think twice before considering it a cloud offering. The service offered might be just what I want and need, but I wouldn’t consider it “cloud”. Windows Azure fulfill all these.
This is not an exhaustive list of what I would expect, nor of the capabilities or limitations of Windows Azure or any other platform, though it is what I would say raises cloud above hosting.
The term private cloud is often mentioned by hosting providers that would like to compete (at least marketing wise) with the bigger cloud offerings like Windows Azure. In my experience, localized as it might be, they fulfill some of the tenants I hold to, but they often fail on things like rapid (and self-serviced) procurement of a new resource (like a server) or on the metered pay per use model – where often you are expected to pay for something based on your time of pre-determined need of availability to that resource - like a month, if not a year.
Also, for the something in the cloud to be usable for a business that will likely have parts of their business, but not all of it, in the cloud I would look for it to be
Since the cloud is not on-premise I would expect there to be a solution available for how do I, in a secure manner, connect what I almost certainly still have on-premise with what I have off-premise – in the cloud. I would hope this to be based on some kind of federated security model, and not by leasing a land line, using VPN, connecting to the existing Active Directory domain or setting up a trust. Though I’ll settle for tried and proven solution.
Continuing on with additional Azure posts I’ll try and link back to these pillars, if possible. With pure how-to technology posts that might not always be applicable, but keep these base concepts in mind anyway so that you architect and build your solutions to support them.