Being Cloud

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 and continues to change rapidly.  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.  But, it’s putting them together that creates the magic of the cloud.

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) that truly wants to be providing a cloud computing service.  A reasonably granularity with today’s models is monthly. Now, there is one caveat here and that’s 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/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.  For example, 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 does come with a cost as it requires 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.  These folks are generally still in beta in a way when it comes to being cloud.  It’s just not appropriate to not provide at least the basic start, stop, reboot, bootstrap, etc. type commands via a programmatic API model.  If a service does not then it looses 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.  But, what it comes down to is that whatever service you are providing must be able to be broken down in distinct components and be able to be be spread across processes, servers, data centers, and continents if it is truly being cloud.

Scalability - The cloud doesn't give you scalability for free (not even the fancy PaaS services out there today) it is a promise of the cloud that you will be able to scale at a more reasonable cost over time than ever before. This promise is, and must be fulfilled.  That promise 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 cloudy.

It is still not easy to truly deploy what I’ll call a cloud computing application today.  But,it’s getting better all the time 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 the developers and the systems engineers to do things right.  In most cases, this still means doing things from scratch since almost no commercially available or opensource applications are truly being cloud out of the box if they even can at all.