Wednesday, January 14, 2009

Acquisition & Git Repositories

As the last post pointed out Reasonably Smart has been acquired by Joyent which means we're in a bit of a transition here as we move into a heavy product development phase.

During the next couple of months the platform repository is going to be closed so that we can get our heads down on the development, but we'll be opening it up again as soon as we can.  In the mean time if you'd access to your repository, or if you'd like the platform source code where it stood on January 9th, please drop me an email and I'll get it for you.

There's lots of news coming, and I'm excited by some of the things that are going to be coming down the pipe!

Joyent Acquires Reasonably Smart


James and I are very excited to tell you that we are joining forces with highly respected, cloud infrastructure provider, Joyent.

As the press release states, we made the decision to join forces because we are confident that by putting the Reasonably Smart Platform on Joyent's proven infrastructure and joining the incredible team, we have the best chance of making an open PaaS a reality - not to mention, we now have a war chest of other great products to work with.

Alistair Croll, writer for GigaOM (amongst many other things), has posted his views on the deal - views that do a great job summing up the vision we have for the combined entity.

I will be joining the Joyent team as the VP Marketing and James will be heading up the product management for the platform product. We have already moved http://www.reasonablysmart.com/ to Joyent Accelerators. If you would like to be kept informed of our progress to beta or take part in any pre-beta programs please visit the website and sign-up.

If you would like to find out more about Joyent's Infrastructure as a Service products or any of the other tools that they, or more accurately, we provide please contact us.

Finally, from both James, myself and our new team, we remain committed to working with you to make the "cloudy bit" a reality!

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!













Saturday, November 15, 2008

Languages in Reasonably Smart

What I love about JavaScript isn't just that it is the programming language of the web, or it's most elegant object system, or even the functional capabilities that are in SpiderMonkey.  With my platform-provider hat on what I love the most is that it's a hardened language.

JavaScript (or, more properly, ECMAScript)  just doesn't have that many capabilities built in, beyond the basic language mechanisms you find in any other programming language.  Sure, you can allocate memory, or put it into a tight loop, but all of those things are detectable from our perspective - again, that of the platform provider.   The big thing you don't get out of the box of course, is IO.

IO is our job.  Reasonably Smart provides carefully wrapped capabilities to read from disk, write to the datastore, and a whole bunch more.  More importantly, we can do it in a secure, considered manner.  This lets us run many different applications on a machine, or a cloud of machines at the same time, without having to carefully vet each codebase to make sure it's not going to do anything bad.

However, some people react strongly to the idea of Server Side JavaScript, and we realize people do like other languages too, which is why we multiple-language support is on our roadmap.  To shine a little more light on our plans -  it's why we're so keen on seeing Mozilla's IronMonkey project get going, and why we are going to support it in any way that we can.

IronMonkey is a planned development to get IronPython and IronRuby compiling to the Tamarin Virtual Machine (the JITting ECMAScript VM that Adobe open-sourced with Mozilla a couple of years ago).   When the IronMonkey project is complete Reasonably Smart will be able to support any language that compiles to the Tamarin virtual machine. 

Having multiple languages is important to us, but not more important than having a safe, secure environment for our customer's applications to run in.  Thanks to open-source, and Mozilla, IronMonkey will help us get there.  In the meantime, we think JavaScript is great - if you've not programmed JavaScript without all that tedious mucking about in the DOM, try it - you'll be pleasantly surprised!


Saturday, November 1, 2008

Financing the PaaS - A Friendly Host May Be The Answer

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

Agreeing on Cloud/PaaS Principles

Simon Wardley recently posted on his blog, Bits or Pieces?, about his "rules of happiness" when he considers cloud computing. For those of you who do not know, Simon is a pioneer in this space. For several years, he has been thinking, writing and talking about PaaS and the cloud industries. Three or four years ago he and his team at Fotango (which included Reasonably Smart co-founder James Duncan), built what was arguably the world's first Platform as a Service, zimki. Since then Simon has been front and centre in the PaaS/Cloud discussion.

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
Simon then goes on to explain that once a service meets these bare minimum standards in order for him to be happy he applies the following rules (these are direct quotes):

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.

Thanks Simon.