Thursday, December 11, 2008

The Cloudy Bit

Remember the first time you drew this on the whiteboard (obviously in your own hand drawn style)?








What exactly did you mean by that cloudy bit? Well, what I usually meant was, a place where stuff that I needed to get done, would get done, without me knowing exactly how. I guess I mostly meant the Internet.

Move ahead until today and now hundreds, if not thousands of people (and companies) have tried to define the “cloud”. One company even tried to trademark it. The problem is, what many of these definers fail to remember is the basic premise of the cloudy bit - automatic satisfaction.

Here’s what I mean by that. Today, most of the cloud definitions that I read seem to define something more like this.






Unfortunately, a large majority of today’s definitions of the cloud are basically defining are a new form of hosting environment where the major innovation is “infinite” capacity, that you can enable in a very short time period, and that you pay for by the hour versus by the month. It is an new hosting environment where people and management software must still by employed to make the "cloud" operate.

What these definitions absolutely do not describe is a reality where “hardware need satisfaction” happens automatically. And, they certainly do not reflect my first notion of the cloudy bit. If you want to check out another (fun) perspective on today’s definitions for the "cloud" check out James Governor’s, 15 Ways to Tell Its Not Cloud Computing.

The question for me is why this new form of hosting is being passed off as cloud computing when the promise of the cloudy bit is, things you need to happen, happen automatically?

The short answer is hype.

So, since the hype is already overwhelming and many people and companies have defined the “Cloud”, what I want to do instead is define the “Cloudy Bit”.

James Duncan and I, mostly because of developing the
Reasonably Smart business plus James’s past experience with the zimki platform, have spent a great deal of time thinking and talking about the “what exactly is the cloudy bit”. The purest example we have come up with is a SaaS application.

Applications like Salesforce.com’s CRM system or Google Docs are truly delivering functionality and real value based on an architecture diagram I first drew on the whiteboard. The user accesses the functionality and data on their computer and the things that make the application work really happen in the cloudy bit. No investment of effort or time on the user’s side is required. The user can make assumptions about where the data is housed, where the application is being served from and how the hardware is configured but, more and more, they would be wrong (especially when it comes to SaaS applications provided by today’s smaller companies and start-ups).

If you look at the components of a SaaS application (from the simplistic perspective) you will see that the “cloudy bit” looks like this:


The application code is the part that links the user to the functionality and enables the usable transfer of data.

At the platform level exist the operational components, including things like the load balancer, web server, virtual machine, message queue and data store, that make the application run (and scale). The operational platform handles things like security, session management, information distribution and interacts with the servers.

And, then there is the hardware which is basically the OS, machines and infrastructure pipes that provide the power and store the data.

The entire stack is the “Cloudy Bit”. Why? Because the user operates the software without ever considering any of the layers in the stack.

So to be a true "Cloudy Bit" provider you really need to be providing the entire stack. More precisely you need to have the capability to run an application (yours or the customer’s) without the customer having to do anything to make it run – at any point of the application’s life cycle.

So far my point is that SaaS applications are truly representative of the cloudy bit and hardware providers, unless they can automatically scale machines as an application’s consumption requirements change, are not.

Now, let’s look at where Platform as a Service companies like Reasonably Smart, Google App Engine or Force.com fit in. Is a PaaS company a cloud provider?

To analyze we can start at the bottom of the stack. What needs to be asked here is do these companies provide the hardware required by their customers automatically? The answer is yes. A person running an application on Reasonably Smart, Force.com or Google App Engine never needs to ask the provider to add or subtract machines to meet their requirements - it happens automatically (from the user's perspective).

Moving up the stack, the second question is, do PaaS companies provide the operating platform in a way that the customer does not worry about it? And again, the answer is yes. A developer creating on any of the aforementioned platforms does need to know how the platform is structured or what component parts are used. In the case of Reasonably Smart, the developer can know because of its open source model but needs to do nothing with this knowledge to make their application run.

Where it gets interesting is when you ask, do these companies provide the code that enables the application to function – the last piece to the cloudy bit definition. In this case, the answer is no. However, what the PaaS providers do give the developer is the foundation on which to create the entire cloudy bit by offering the environment where they can write code and once finished the result is a full blown SaaS application - without any investment in building the platform or hardware infrastructure layer.

And the really exciting part about this is the developer has just leapfrogged traditional SaaS providers like Salesforce for their CRM solution and Google for Docs because today's SaaS companies actually have to manage their infrastructure everyday - regardless if they run on their own hardware or if they run it in the "cloud". If you write on a platform you never will.

So, when you are considering building an app that leverages a cloudy bit architecture you may want to consider a Platform as a Service to minimize your long term costs and potentially out smart your competition.


If you need more information on this topic we would be more than happy to discuss it further.

Wednesday, December 10, 2008

Wishing Brainpark Good Luck!

I went to Guelph Ontario last Wednesday for a party. No really, I did. It is something I haven't done since my days at Wilfrid Laurier U. And even back then I am not really sure I ever went there on a Wednesday.

The reason I decided to make the trip from Montreal was to support the Brainpark launch and to see how Mark Dowds, a master promoter in his own right, and his team would introduce the new company to the world.

I have to say, I was impressed. The turnout was great. People had come in from all over. The mood was light but had a underlying sense of purpose. It was a very good mixture of networking, demo, interaction and partying. The open bar never hurts.

In the end it was both informative and very fun. Well worth the trek from Montreal.

Good Luck to the Brainpark Team!