Will Reasonably Smart be cheaper than EC2?

In response to James's post Ning shuts down WidgetLaboratory, Chris Holland asked if the Reasonably Smart Platform (RSP) would be cheaper than Amazon's EC2. It's a valid question that deserved its own blog post as a response.

So, will RSP be cheaper than EC2? The short answer is maybe.

The long answer needs to be looked at from a couple different angles.

1. Should the pricing of the two companies even be compared given the businesses they are in?
2. If they are in the same business will Reasonably Smart be cheaper than EC2?

In their own words, Amazon, through EC2, delivers a true virtual computing environment, allowing you to use web service interfaces to requisition machines for use, load them with your custom application environment, manage your network's access permissions, and run your image using as many or few systems as you desire.

In other words, they let you rent servers and bandwidth in shorter time frames then what was available from traditional hosting companies. Plus they make it "easy" to increase and/or decrease the number of machines you are renting quickly.

In our words, Reasonably Smart's mission is to develop and manage the open source Platform-as-a-Service that enables web application development in a Peer-to-Peer cloud/utility computing environment and empowers collaborative, efficient, industry transforming web application creation.

In other words, we provide an environment for you to develop and execute web applications.

The major differences between the two being that on our platform you can develop your web application without concerning yourself with:

• Creating, managing and scaling a database
• Creating back-up routines and load balancing between servers
• Developing an execution environment
• Managing security patches
• Hiring and managing system administrators
• Engaging (and paying) cloud computing management system providers
• Figuring out how to be "at the edges of the network"

A couple of other pieces of added value within the RSP platform over and above EC2 are the integrated distributed version control and the core philosophy of open source.

So the first answer to the question "will RSP be cheaper than EC2?" is that they are difficult to compare because there is much more value being provided by RSP than EC2.

Now, if you completely discount the Platform as a Service (PaaS) value proposition then the question of who will be cheaper comes down to the vision of the two companies for the (hardware) cloud.

Amazon has huge buying power, and can reach economies of scale that are difficult for others to attain. However, the RSP has been designed to be completely hardware-provider agnostic. Therefore, our hardware layer options could include EC2, IBM, Dell, EMC, any hosting company, our own datacentre, the server under your desk or all of the above. This makes the answer to the question most easily broken down like this:

1. If RSP utilizes EC2 as its hardware layer then RSP will not be cheaper than EC2
2. If RSP utilizes several data centres (EC2, EMC, IBM, Opsource) then RSP might be cheaper than EC2
3. If RSP reaches its "blue sky vision" of leveraging the world's excess server capacity then it is likely that RSP will be cheaper than EC2

Fundementally we believe that someone needs to start identifying the difference between a hosting provider and a cloud computing environment in light of all of the misrepresentation in the market and media. What Amazon are doing with EC2 is fantastic, and makes renting computing power more straightforward than ever before. They are, undoubtedly taking away the need to plug in server, and wire it up to the network. But don't forget, there is a difference between being in the cloud and being the cloud.

Hopefully this addresses both the question about who will be cheaper and starts to illustrate more clearly some of the differences between ourselves, and other "cloud" computing companies.

TraceMonkey

A decision that I made early in the development of Reasonably Smart was to completely ditch the idea of building my own, hardened version of various languages for the runtime engine.  Instead we embedded Mozilla's SpiderMonkey engine. 

We've fielded questions on this a number of times, so I thought I'd write a little about the decision here.

Firstly, we don't have an infinite number of engineering hours.  We're not language builders, and we need to focus very clearly on building the datastore, machine infrastructure and management tools that benefits our customers.  Secondly, the Mozilla team are going to be building around SpiderMonkey for the forceeable future. Improvements like Tamarin only benefit us (and projects like IronMonkey may allow us to run Ruby, Python & PHP code in a hardened environment too).  While we'd love to be able to contribute back to Mozilla eventually, right now we can't afford to.

Announcements like today's about TraceMonkey validate this decision further.  We'll be able to benefit from this change very quickly -- we've already got a version built in development, and as soon as it hits a stable point, we'll be able to roll the change up very quickly.

Ning shuts down WidgetLaboratory

This morning Ning removed WidgetLaboratory's account and service.  While I'm sure they had what they think is a good reason for doing so this sort of thing is exactly the reason that Platform-as-a-Service providers must be open source.

WidgetLaboratory, for those of you who don't know, makes widgets that other Ning network creators could plug into their own sites.  These widgets of course were things that Ning didn't provide themselves, and a lot of people are very upset about this.

As I see it there are four outcomes here: WidgetLaboratory's service is restored, the people who are upset build their own replacements, the people who are upset stay upset, or Ning provide alternatives.  Of the four, I think the best possible outcome for Ning will be if they follow the first path -- if there was a ToS violation, fix it, restore the service, and move on.

 

We feel that the worst outcome would be if Ning went down the route of providing replacements.  The idea has already been floated by others that perhaps WidgetLaboratory's widgets were somehow encroaching on Ning's revenue.  If Ning recreate the widgets then fuel will merely be added to that fire.  Of course, it's only a possibility at this time, but it highlights something else we strongly believe.

We think a Platform-as-a-Service must be charged on a utility basis.  We don't think freemium models can work, because the provider will always be looking to expand their premium offering and sooner or later these will collide with those of their customers.  When that happens, sparks will fly, and fires will start.

Fundamental to everything we're doing is the belief that a utility model works for everybody - the customer wins because utility models are more fair, and the PaaS provider wins because more usage from your customer's customers means more revenue for you -- never less.  As a business-to-business software service, we believe there needs to be clear blue sky between what we offer, and what our customers offer.  That's very hard, and will continuously get harder, with a freemium model.

Reasonably Smart is open source, and is going to operate under a utility model.  We'll charge for bandwidth, storage, and operations in the VM.  You can build what you want, and if you don't like how we operate, or feel our charges are unfair, you'll have the ability to take not only your code, but our code as well, and it run elsewhere.

Thoughts?

Good to be on the Receiving end of Patches

It's especially good when a lot of your time is being used by working on the business itself.

On that front, I have to thank two people especially.  Firstly, Claes Jakobsson, creator of JavaScript.pm, and without whom RSP would not exist.  Claes has been incredibly helpful, working on ironing out a few bugs in JavaScript.pm, and introducing a couple of new capabilities that are needed to push what the RSP is doing to another level.

Secondly, Hans Dieter Pearcey sent me a few patches for the RSP itself.  One of them was on my todo list, so I'm incredibly happy to apply it into my working tree.  HDP also fixed up my Makefile.PL so that it has all the correct prereqs in there.  Another win!

I'm also trying to track down what is stopping ClaimID OpenID's from working, reported in our Google group.

So a huge thank you to everybody who has taken the time to look at, fix, and report problems and, even better, come up with solutions!

VC Financing - the Certainty and the Uncertainty

We at Reasonably Smart (James and I) are now fully engaged with the VC community. Since last Wednesday, we have had 5 meetings with various potential partners. The discussions included potential partners Storm Ventures, Montreal Start-up, Neotech Ventures and Desjardins. This week we are talking to OATV and JLA Ventures. I know, we are all over the place.

Obviously, these discussions are not the result of a well thought through plan but more a result of the significant positive PR received so far and leveraging our network. This is both good and bad...

In my previous life, I has the opportunity go through the funding exercise on 3 occasions. This experience exposed my to all types of organizations all over North America, including VCs, Investment Banks, Sub-debt lenders and the advisors. Although I talked to several North American VCs, the VCs I became close to were mostly Montreal based. To be truthful, I have little experience with the "valley" based organizations. With Reasonably Smart, this is changing quickly...

The current business is much more "technical" than the last business. It does not have as big a service component so it fits very well into the VC sweet spot. Which is great because everyone we contact is somewhat interested. The downside of this is, everyone is interested. Combine this with the fact that we are being contacted because to of the PR and it's obvious that targeting and keeping focus are going to be key challenges we need to navigate.

With my somewhat limited experience I am pretty sure of some things and unsure about many other things when it comes to raising money. Here's the summary:

Certainty:

• Conceptually, raising equity is straightforward
• In reality, raising capital is often affected by factors beyond your control
• The Canadian VC market is stagnant
• A couple of Canadian VCs still invest in good businesses so they can't be ignored
• Referrals really help
• Advisors are usually overrated, viewed negatively by the VCs and unnecessary for early round funding projects
• Fund raising without a targeting strategy causes inefficiency
• A VC's deal flow and timing can and does affect whether a good idea gets funded with them

Uncertainty

• Do you ever submit an Executive Summary via a VCs website?
• How do you really target the "best VCs" for your business?
• When is a VC just saying nice things and when does what they say really mean they want to invest?
• Is a California (valley) based VC really the be-all and end-all for a software company?
• How much does an strong advisory board help?

With these ideas and questions in mind we are now both reacting to the interest and approaching "target" VCs. We are absorbing all the advice that comes our way and we are hopeful that we make the best decisions for this business. Ultimately, we are not looking for the "perfect deal", just a good deal with strong partners to help us get this venture growing.

If we accomplish this reasonablysmart.com is on its way!