Wednesday, January 14, 2009
Thursday, December 11, 2008
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
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!
Saturday, November 15, 2008
Saturday, November 1, 2008
The Reasonably Smart project has just crossed into the 9th week of our funding mission. Let me just say, it has just been a fantastic 8 weeks to be raising capital! Especially with all that stability, strength and optimism all around us!
Actually, despite the fact the "sky was falling" over the past two months the response to our company has been generally positive. Many of the VCs that we have talked to have indeed passed – as they do – but a couple are digging in. Unfortunately, we are still a long way from a deal.
On the bright side, one concept that is picking up momentum is one we were aware of but did not immediately pursue. That is the option of strategically and financially partnering with a hosting provider. Originally we did not move in this direction because of the bias we had towards hosting companies generally being "traditional" suppliers to us. However, based on the conversations we have had over the past 2 - 3 weeks, we realized that they could be so much more.
The whole cloud computing evolution has completely changed how innovative hosting companies are viewing the future. Deals are being made all over the industry that are designed to "on ramp" these companies to the cloud. Hosting companies who want to broaden their offering and/or add more depth to their stack are looking at Platform as a Service (PaaS) with great interest. Those providers who are extremely forward thinking and who want to engage the developer directly and/or create a developer ecosystem, are beginning to see how leveraging a PaaS could be a great way to do this.
Fundamentally, with certain providers the realization seems to be that their hardware is the power generation plant, and a PaaS could be the distribution network that links them to the "home and office". This is all good news for Reasonably Smart as our funding options are increasing "in this time of great need" .
So, if you are a hosting/hardware cloud provider who is looking to extend its offering, its reach and embrace the developer directly, have a look at partnering with a PaaS company.
And, more importantly (to us), if you have money to invest and are going in this direction, take a look at Reasonably Smart as we are still looking for our partner.
Wednesday, October 22, 2008
In his post he first mentions some "absolute minimums" that the service must have/be:
- Readable access to all data, code, frameworks and meta data that may have been created as a result of using the service
- Secure, scalable, resilient and charged for on an "as use" basis
- Clearly communicate T&Cs that cannot be changed without reasonable notice, and reasonable alternatives
- Transparent pricing
Rule 1: I want to run the service on my own machine.
This enables me to trial out a service before even considering adopting a cloud version and gives me a last resort fall-back option. I certainly don't want to be in an environment where I can't do this for whatever reason, including vendor failure or discontinuation of a product.
Rule 2: I want to easily migrate the service from my machine to a cloud provider and vice versa with a few clicks of a button.
If the test went well then I'll probably consider dipping my toe in the water. Hence I want an easy to use transfer mechanism for my data (including any code or framework elements) from my machine to an external cloud provider and vice versa. I do not want to learn any specialised skills nor require any technical knowledge beyond pressing a button.
Rule 3: I want to easily migrate the service from one cloud provider to another with a few clicks of a button.
If I'm going to use a cloud service then I want a choice in providers and an easy mechanism of switching between alternatives. I do not want to discover that switching only covers half of the service and fails to cover other elements like the storage subsystem or a messaging service.
He ends his post by saying that, "For these reasons, I'm not very happy with most of the current cloud offerings".
After reading Simon's post there was a sense of validation. His bare minimums and rules are all core to our fundamentals at Reasonably Smart. Portability, transparency, ease of use, reliability, security, scalability are what we are building and delivering with the RSP. The only exception could be meeting the "pricing transparency" requirement but that's only because we aren't charging yet. Once we start billing (launch of v1.0), we are going to be billing for consumption in a utility model (pay for use) and our pricing plan will be clearly explained on our new website. See the post on our pricing model.
We realize we have a ways to go to prove out that the fundamentals are consistently delivered. However, we will continue to build the business based on our core philosophy. The great thing is now we can print out Simon's post and put it on the whiteboard as both a reminder and encouragement.