Error getting theme layout

Being Cloud

Posted @ 4:52 pm by Kent Langley | Category: Technology | 0 Comments

I often find myself discussing what it means to be a Cloud computing infrastructure, application, platform, or framework with clients and colleagues.  What it takes to be Cloud has changed rapidly, and continues to do so.  Today, in my opinion, the following “features” are required for something to really be Cloud.  Each of these can be (and has been) written about, at length, all over the Internet.  Then again, the magic of the Cloud is all about putting them together!

On-Demand Business Model (Utility Model) — No one should be asking you for multi-year/month up front payments and pushing complex contracts (or any contract) who truly wants to be providing a Cloud computing service.  A reasonably granularity with today’s models is monthly. Now, there is one caveat here: when a company wants invoicing or price breaks.  In that case it can be reasonable to ask for a pre-pay to keep the provider from becoming the banker, as that is generally unfair.

On-Demand Consumption Model — The user of the service should be able to consume what they want and need when they need it from the cloud service, at a reasonable granularity.  This is true if they want to consume more or less at any given point.

Highly Available — This part is required, but is also contextual to the layer of service.  For example, at the IaaS level it’s not necessary for every competent to be highly available; a single Amazon AMI or RackspaceCloud server running on a single hardware node with a single power supply is certainly not highly available.  However, moving up the stack to PaaS and SaaS, the expectation of high availability is reasonable and required to really be a cloud service.  It should be noted that some providers do offer high availability at the IaaS level in various forms, but that comes with the cost of requiring at least 2x the resources at some level.

Elastic — Services must be able to scale up or scale down on-demand without the need for calling up a person to do it.  This is a function of the service being elastic.  The administrator of the service should have the necessary controls and access to be able to grow or shrink the service when they want or need to do so.  This administrator most definitely should not needed to call up the provider and ask permission or to be granted the rights to do so.  Otherwise, most benefit is lost.  The time frame should be single digits of minutes to scale up or down, so it must have the capability to be scalable up OR down on whim really.

Programmatic API — This one will be controversial, since there are several very well established cloud computing players on the market that do not offer a reasonable programmatic API to their user base, or only keep it under the hood for their own internal use, or don’t have it at all.  I would argue that most of these services are, in a way, still in beta — at least when it comes to their Cloud approach.  Not providing at least the basic start, stop, reboot, bootstrap, etc. type commands via a programmatic API model is simply not appropriate.  If a service does so, then it loses competitiveness as a clients site grows over time.  A lack of ability to automate in complex scenarios will becomes unwieldy at scale.

Distributable —  Some call this SOA, asynchronous, loosely coupled, MPI, and probably tons of other descriptions and acronyms.  It comes down to this: Whatever service you are providing must be able to be broken down in distinct components and spread across processes, servers, data centers, and continents if it is truly to be considered Cloud.

Scalability — The cloud doesn’t give you scalability for free (not even the fancy PaaS services out there today), just promises that you will be able to scale at a more reasonable cost over time than ever before. This promise is, and must be, fulfilled. It requires that you do things smart up front.  You services, whatever they are, must be designed to scale, or they most certainly will not be scalable.  Creating a system that is able to scale requires a mix of all the of the above to be in place and even more that hasn’t been discussed in this post.

Those are some of the features that I think must be present if you’re going to say you’ve moved beyond dedicated or shared hosting models and deployed something that is being Cloud-y.

It is still not easy to deploy what I’d call a cloud computing application today.  It’s getting better all the time, though, as evidenced by recent news such as AWS Elastic Beanstalk and the advancements of various PaaS providers in particular.

Just remember, no matter what, being Cloud is up to how well the developers and the systems engineers do things.  In most cases, this still means working from scratch, since almost all commercially available or open-source applications lack any Cloud functionality at all, let alone out-of-the-box cloud-style computing.

Leave a reply

Error getting theme layout