Telling the difference between cloud and smoke

Returned a few days ago from NRF11. As expected, there were many companies advertising cloud computing, and yet, how disappointing when investigating the case a tiny bit further: it seems that about less than 10% of the companies advertising themselves as cloudy are actually leveraging the cloud.

For 2011, I am predicting there will be a lot of companies disappointed by cloud computing - now apparently widely used a pure marketing buzzword without technological substance to support the claims.

For those of you who might not be too familiar with cloud computing, here is a 3min sanity test to check if an app is cloud-powered or not. Obviously, you also go for a very rigorous in-depth audit, but with this test, you should be able to uncover the vast majority of smoky apps.

 

1. Is there any specific reason why this app is in the cloud?

Bad answer: we strive to deliver next-generation outstanding software solutions, exceeding customer expectations, blah blah blah, insert here more corporate talk ...

A pair of regular servers - typically a web server plus database server - can handle thousands of concurrent users for non-intensive webapps. This is already a lot more users than what most apps of the market will ever face (remember with a high probability you don't need to scale). So there has to be a compelling reason that justify the cloud beside the very hypothetical scenario to grow faster than Facebook.

 

2. Is the underlying infrastructure larger than 100k machines?

Bad answer: well, in fact we are just having our own dedicated servers at DediHost Corp Inc (put here the name of regular hoster).

A key aspect of cloud computing is cost reduction through massification. As of 2011, there are still only a handfew cloud providers available, namely: Amazon WS, Google App Engine, Rackspace Cloud, Salesforce and Windows Azure. Make sure to ask which cloud infrastructure is being used. Also, private clouds are no exceptions, it's not because it's "private" that suddenly massification is achieved with 100 servers. It takes more, a lot more, to build a cloud.

 

3. Can you open an account and get started right from the web, no setup cost?

Bad answer: let's meet and evaluate your requirements first.

Multitenancy is a key aspect to reduce admin costs. In particular, with any reasonable cloud-based architecture there is no reason to have mandatory setup costs (which does not mean that company may not charge some optional onboarding package providing eventually training , dedicated support etc). Setup costs are typically a sign of a non cloud software where each extra deployment takes some amount of gruntwork.

 

4. Is there a public pricing? Typically indexed on usage or user metrics.

Bad answer: pricing really depends on your company.

For cloud-based apps, there are about zero compeling reason not to have a public pricing. Indeed, cloud costs are highly predicable and strictly based on usage, hence, it makes little sense from a market perspective to go for a customized pricing for each client as it increase sales friction providing no added value for the client.

 

5. Can two machines failing bring down the app along with them?

Bad answer: we have backups, don't worry.

In the cloud, the app layer should be properly decoupled from the hardware layer. In particular, hardware failures are accounted for and primarily handled by the cloud fabric which reallocate VMs when facing hardware issues. The cloud does not offer better hardware, just a more resilient way to deal with failures. In this respect, setting-up a backup server for every single production server is a very non-cloud approach. First, it doubles the hardware cost, keeping half of the machine idle about 99% of the time, and second, it proves brittle facing Murphy's law, aka 2 machines failing at the same time.

As a final note, it's rather hard to tell the difference between a well-designed SaaS powered by a regular hoster and the same but powered by a cloud. Although, back to point 1, unless there is a reason to need the cloud, it won't make much difference anyway.

Wish list for Relenta CRM

At Lokad, we have using the Relenta CRM for nearly two years. It's an excellent lean CRM that comes with a core focus on emails which happen to represent about 90% of our interactions with clients and prospects.If you happen to be an ISV, Relenta is worth having a closer look.

Although, I have been missing a few key features in Relenta for a long time. Hence, I taking the time here to post my wish list for Relenta.

1. Accounts

Relenta only deals with Contacts yet, when prospecting larger companies, many contacts are typically involved. It would be much nicer if it was possible to create 1-to-many relationships between Accounts and Contacts. In particular, this would let the Relenta user browse at a glance all the latest interactions related to a particular account, instead of jumping from one contact to the next.

2. Recent updates

One of the feature that I like the most in wikis are their abilities to display the recent changes. Through recent change, you can gain immediate insights in what other people are doing, without having to bother to actually ask them.

Presently, there is no way to easily figure out who has been doing what in Relenta.  It would much nicer if a stream of recent updates was available for browsing. In particular, display could be made more or less compact by aggregating updates per contact (or per account). Eventually, the stream could even be made available as RSS.

3. Activity capture API

The Lead Capture API of Relenta is a killer feature due to its simplicity. For an ISV, it's a super simple way to collect all trial registrations that keeps flowing through our online apps with extremely limited integration grunt-work.

Yet, although it's very simple to automate the Contact creation in Relenta, it's not possible to automate the insertion of Activities later on the very same contact. This feature would be extremely handy to automatically report payments, or any kind of noticable activities (in the case of Lokad that would be large forecasts retrieval for example).

4. Refined tagging

Tagging is one of the best idea of the Web 2.0 wave. It's a great way to organize complex yet little structured content.

Relenta already provide a minimal tagging system, yet there is no tag auto-completion (killer feature) and it's not possible to search against multiple tags. Pushing a bit more work on tags would be a great move forward to make the most of them.

5. iCalendar support

iCalendar is a very nice and popular format to send meeting request. Presently, Relenta does not support .ics attachments and meeting requests appears as completely garbled. It would be really nice if Relenta was support iCalendar with the possibility to acknowledge meeting requests.

Stack Exchange 2.0: epic fail?

It's a sad thing to see a pair of brilliant entrepreneurs going for a probable epic fail with best intentions in mind.

IMHO, the recently announced Stack Exchange 2.0  has a high probability of failure, and worse (as far I am concerned) it might marginally hurt my business due to the lack of ongoing commitment for the forum I did setup for my own company a few months ago.

Let consider the situation:

• Stack Exchange is an excellent Q&A engine, something that the market had been waiting for a long time, as illustrated by the success of Stack Overflow.
• Stack Exchange 1.0 had a very reasonable business model, announced with an entry price of about $120 / month.

Now, Stack Exchange 2.0 for a business plan that urgently reminds me of the 37signals announcement of their $100 billion valuation:

When it comes to valuation, making money is a real obstacle. Our profitability has been a real drag on our valuation.We’ll give away everything for free and let the market speculate about how much money we could make if we wanted to make money. That way, the sky’s the limit!

So let start by discussing the arguments proposed by the SE team to go for a free service:

1. SE had not enough enough beta volunteers. They were expecting "thousands of sites would start to sprout up on every possible topic" (sic)
2. People were prone to create "ghost-town sites that nobody visited" (sic).  "Allowing anyone with a credit card to make a site" (sic) wasn't a good idea.
3. People were prone to "multiple sites on the same topic" (sic).

Expecting an overnight success

Well, as far point 1 is concerned, that was just plain unrealistic expectations. Yes, I am 100% sure that SE 1.0 (Stack Exchange 1.0) could have ultimately had thousands of happily paying customers, but it turns out there is no overnight success. Stack Overflow was a quick success because it benefited from two famous bloggers with huge 100% focused audience.

Yet, SE 1.0 is a B2B product, and needs to be marketed and sold accordingly; and it turns out that the SO (Stack Overflow) is definitively not the right audience to market SE. All the SO folks happen to be software developers: little wonder that you get half a dozen SE spawn focusing on startups (but we will get back to this point).

Hence, SE 1.0 had not even been marketed yet, not to the relevant audience anyway.

Then, the beta branding is sufficient to scare away about 99% of all B2B prospects; software tools are sort of a one-of-a-kind exception here. Thus, to even get a chance for SE to succeed, it would need to branded as v1.0 then start charging for it.

Companies don't trust "gratis" stuff, and rightly so. B2B is the contrary of B2C: you have to start charging for it to succeed (open source entered the business the day people started to charge for it).

What about the ghost sites?

Building a community is a very significant investment. It takes a lot of time, typically years, and thousands of hours of work. SE 1.0 was beta. How could it be expected any reasonable organization to push such a commitment on an unproven solution? For most businesses, a solution becomes proven when someone gets charged for it, and this person claims that is was money profitably spent.

Then, the SE team implicitly assumed that low traffic means implicit failure: those guys with credit cards they don't know what they are doing.

The market gets it wrong, and we are going to do it better.

I am very skeptical when anyone (even bright people) pretend to know more than the market. If somebody is selling Luxury Yatch, then a single answered question might be worth millions of USD if it makes the difference to close the deal.

If people (like me) are ready to be pay $100 / month for low traffic websites, then there might be another explanation than those people don't know how to spent their money.

Pushing the point further, how do ghost sites hurt the SE business in anyway? Companies pay for the websites, nobody looks at those websites, nobody gets hurt by those websites. Take the money and stop whining.

Websites on similar subjects are created

Considering that SE was primarily addressed at a near monolithic audience (software developers), it's little wonder to see that many people had the same idea at the same time.

This is old behavior inherited from Economy 1.0: it's called competition.

And so what? Software editors sell their products to companies who happen to compete against each other. This is a healthy situation. At some point the market may decide to elect a "outstanding" winner, but most of the time, market does not, and competition keeps going.

Again, pretending to know more than the market is a wild assumption.

As final point of the analysis of SE 1.0: the outlook was bright, it needed an official v1.0 release, some meaningful marketing outside the software crowd, and SE 1.0 was very likely to become a profitable business. Dropping the SE 1.0 at this point almost look like a bad case of Fear of Success.

Outlook on Stack Exchange 2.0

The SE 2.0 business model claims that service will be offering for free. Yet, there is nothing as free in business. Most likely SE 2.0 will be paid through the advertising tax which happen to be extremely expensive.

In particular, this business model will be way to expensive for most organization to commit any significant resources.

Basically, SE 2.0 is positioning itself in the attention sharing economy trying to re-introduce the old byzantine usenet rules. The intrinsic problem is that creating a community is very different from actually creating business value.

For example, Wikipedia is a worldwide community success, but it's actual business value is zilch: you might donate to Wikipedia, but you can't invest in Wikipedia and expect any financial reward.

Then, SE 1.0 had low profile unknown competitors; SE 2.0 is getting up ahead a direct confrontation with big guys: Google, Facebook, LinkedIn which will - no doubt - deliver their own variants (if SE 2.0 prove to get some traction) to be marketed much more effectively using their social communities.

As a final note, I am hoping, if the SE team sticks to its plans, that the market will quickly fill the room left empty by the now defunct SE 1.0. Contenders are already in place.

Table Storage gotcha in Azure

Table Storage is a powerful component of the Windows Azure Storage. Yet, I feel that there is quite a significant friction working directly against the Table Storage, and it really calls for more high level patterns.

Recently, I have been toying more with the v1.0 of the Azure tools released in November'09, and I would like to share a couple of gotchas with the community hoping it will save you a couple of hours.

Gotcha 1: no REST level .NET library is provided

Contrary to other storage services, there is no .NET library provided as a wrapper around the raw REST specification of the Table Storage. Hence, you have no choice but to go for ADO.NET.

This situation rather frustrating because ADO.NET does not really reflect the real power of the Table Storage. Intrinsically, there nothing fundamentaly wrong with ADO.NET, it just suffers the law of leaky abstractions, and yes, the table client is leaking.

Gotcha 2: constraints on Table names are specific

I would have expected all the storage units (that is to say queues, containers and tables) in Windows Azure to come with similar naming constraints. Unfortunately it's not the case, as table names do not support hyphens for example.

Gotcha 3: table client performs no client-side validation

If your entity has properties that do not match the set of supported property types then properties get silently ignored. I got burned through a int[] property that I was naively expecting to be supported. Note that I am perfectly fine with the limitations of the Table Storage, yet, I would have expected the table client to throw an exception instead of silently ignoring the problem.

Similarly, since the table client performs no validation, DataServiceContext.SaveChangesWithRetries behaves very poorly with the default retry policy as a failing call due to, say, and entity that already exists in the storage, is going to attempted again and again, as if it was a network failure. In this sort of situation, you really want to fail fast, not to spend 180s re-attempting the operation.

Gotcha 4: no batching by default

By default DataServiceContext.SaveChanges does not save entities in batch, but performs 1 storage call for each entity. Obviously, this is a very inefficient approach if you have many entities. Hence, you should really make sure that SaveChanges is called with the option SaveChangeOptions.Batch.

Gotcha 4: paging takes a lot of plumbing

Contrary to Blob Storage library that abstracts away most nitty-gritty details such as the management of continuation tokens, the table client does not. You are forced into a lot of plumbing to perform something as simple as paging through entities.

Then, back to the method SaveChanges, if you need to save more than 100 entities at once, you will have to deal yourself with the capacity limitations of the Table Storage. Simply put, you will have to split your calls into smaller ones: the table client doesn't do that for you.

Gotcha 5: random access to many entities are once takes even more plumbing

As outlined before, the primary benefit of the Table Storage is to provide a cloud storage much more suited than the Blob Storage for fine-grained data access (up to 100x cheaper actually). Hence, you really want to grab entities by batch of 100 whenever possible.

Turns out that retrieving 100 entities following a random access pattern (within the same partition obviously) is really far from being straightforward. You can check my solution posted on the Azure forums.

Gotcha 6: table client support limited tweaks through events

Although there is no REST level API available in the StorageClient, the ADO.NET table does support limited customization through events: ReadingEntity and WritingEntity.

It took me a while to realize that such customization was possible in the first place as those events feel like outliers in the whole StorageClient design. It's about the only part where events are used, and leveraging side-effects on events is usually considered as really brittle .NET design.

Stay tuned for an O/C mapper to be included in Lokad.Cloud for Table Storage. I am still figuring out how to deal with overflowing entities.

Startup Class '07 and '08 at Telecom ParisTech

In my previous post if been detailing 9 steps to make sure your startup exists. Inspired by an initial idea of Chris Exline, I decided to make a small survey of the startups admitted at the Incubator of Telecom ParisTech in 2007 and 2008 (startups are hosted 18 months by the incubator, and then kicked-out, that's the rule).

To figure out how well the startups of the incubator were doing, I came up with a simple score the startup websites.

Survival test for startup websites:

• +2 if look & fell is GOOD.


• +1 if look & fell is just OK (zero if horrid).


• +2 if benefits of product or service is clear.


• +1 if I must struggle to figure out the benefits.
  (zero if I am still clueless about benefits after struggling)


• +1 if there is no happy talk


• +1 if PageRank is greater than 3 for a B2B company.


• +1 if PageRank is greater than 5 for a B2C company.


• +1 if there is an English version.


• +1 if people can buy or consume right away.


• +1 if there are news.


• +1 if there are forums.

The maximal score for this test is 10. One can argue that this test is very subjective. Frankly, after reviewing 50 companies, I rather think otherwise.

Any website with a decent, professional looking is ranked as GOOD with 2 points - no need for flashy graphics, decent is enough. In the other hand, if the website feels amateurish (colors messed-up, random layout) but still functional, then it's OK, you get 1 point. If the website is utterly broken in design or in navigation, then it's zero point.

Same for the benefits. If I can get a rough idea, in less than a minute, of the added-value of your company, then you get 2 points. I mean no need for detailed ideas, big picture is enough. If I have to struggle for 5 mins to finally guess what could be your added value, then it's 1 point. If after 5 mins, I am still utterly clueless, then it's zero point.

Concerning the PageRank, I am putting a much lower threshold for B2B website, because those folks typically need 100x times less customers than B2C companies to be profitable.

Not having a English version is like shooting yourself a bullet in your feet. The French market is small, so small, compared to USA+UK+Canada+India+Australia. To get 1 point here, you don't need to have translated everything in English, any portion that makes sense is enough.

In my opinion:

• any 6 months old startup should get at least 6/10.


• any 18 months old startup should get 9/10.

I have collected raw data for 52 startups within a Google Spreadsheet, and here are the results at present date 2009-04-21.

Disclaimer: I have a strong bias toward Lokad since it's my own company. Thus, its score is probably the least reliable score of the whole study(*). Concerning the other startups, I am not involved, thus, I feel more objective.

07 class 9 DisMoiOù 9 Lingueo 8 Connecthings 8 Helia 8 La Cartoonerie 8 LivePepper 8 Netineo 8 PREXENS 8 Teacheo 7 FrenchSet 6 Adminext 6 EtherTrust 6 InovaCours 6 Tellus 5 FamilyBy 5 Adipsys 5 Lixys 4 Needer 3 Connect and Go 3 Patent Organizer Software 3 Nexess 2 MobiNear 1 Alphacode 1 Système Polaire 0 Takys Average score: 5.5

'08 Class 9 OOdesk 9 Lokad 8 Accessif 8 Haploid 8 Hellocoton 8 PlayAdz 7 CapAngel 7 Jaxio 7 OhMyMode 6 Ecce Vino 6 Quelle Energie 6 Actimos 6 Kwaga 5 Ineovation 4 Eyes Triple Shut 4 Hedera Technology 4 Plugnsurf 3 Absysseo 3 Aquilant Technologies 3 Faveod 3 The Metrics Factory 2 FI Technologies 2 Media Mobility 2 nYouLinK 2 SeQureNet Average score: 5.3

 
To be honest, those results look rather poor to me.

• Two thirds of those startups don't offer any chance to their customer to buy or consume the product or service online.


• Roughly one third of those startups are not able to express the benefits they could bring to their customers.


• More than half of the startups can't get even a limited English version of their website.

Moreover, startups do not improve much over time. Considering 2007 vs 2008, if feel like if there were two categories of startups:

• the ones that got a good website right from the start.


• the ones that will never get a good one.

Yet, my own experience told me it's so obviously not true. Just have a look at the first version of the Lokad website (score: 4) and compare with the current one. Granted, I am still far from what Branding Geniuses could produce, but still.

I would be interested to see how other incubators are doing on their own.

(*) Feel free to give us a score of zero if you think the Lokad website is damn broken - but please leave a comment so that we can improve :-) .