Fishpool

My MySQL Conference presentation on Tuesday discussed my practical findings on how Infobright's technology works in developing a MySQL-based data warehouse. I also touched on a more high-level question of how to select a technology for a different kinds of data-related problem areas, and this article expands on that discussion.

So, waking up this morning to prepare for the first day of the MySQL Conference, the first news I pick up is that it's now Oracle Conference instead. Been speaking with a few people through the day and confusion as to how this is going to impact the company, development community, users or customers reigns. Personally, I'm more apprehensive than excited about it at this point - but frankly, I've spent more time thinking of how to apply MapReduce to large-scale ETL processes than about the acquisition today.

However, I'll keep digesting this for a while, and hopefully after a couple of days of discussing it with people here I can form a better opinion. I don't know Oracle that well - it never seemed like a very easily approachable company to me, and what connection I've had with the technology its felt a bit baroque and legacy, but I haven't even looked at it in a few years. It is interesting though - Oracle's acquisition of InnoDB a couple of years back was certainly one reason why there's today a number of development projects for other transactional storage engines for MySQL. Sun has been an active corporate sponsor to a number of such projects, and it doesn't seem very likely that Oracle would want to continue that. Dunno.

I wrote last fall about the "sweet spot" in pricing and spending patterns for a microtransaction-based service and business model, where I posited that given flexible consumption, revenue could be maximized by ensuring the lowest possible minimum price point; one which is preferably closer to 1 cent than one 1 euro. Depending on the goods sold and amount of logistics overhead, the minimum profitable price may of course be much higher, and depending on the payment mechanisms available, the minimum price for which the consumers effort overhead exceeds the cost of the good may also be fairly significant. A chocolate bar may be sellable for 40 cents, while few durable goods can achieve a price point lower than a few euros. For virtual goods, the minimum pricing is mostly a question of efficient mechanism for transferring low amounts of money, because the minimum "size" of the good sold can be in theory reduced ad infinitum, and distribution costs are a non-issue.

Last week there was a Facebook Developer Garage day in San Francisco where a couple of interesting presentations were given. I wasn't there, but browsing through the material I found this slide about the distribution of order sizes among Amazon customers (slide 10 in the deck):

It's interesting to see the similarities on this chart to the behavior in virtual goods. In this data, the observed behavior follows the power law model in an ideal fashion at price points over $25, but the drop-off below that order size is remarkably fast. This is the result of primarily the goods sold and the logistical overheads implicit in that; it just doesn't make much sense for someone to order $5 worth of goods from Amazon given the shipping costs and delays incurred on top of the purchase.

For virtual goods, the drop-off point can be much lower, but still, a similar drop off does happen - again because below a certain price point and transactional overhead level, neither the consumer of the good nor its producer see value in the market. At prices above that, the transactional model does however exhibit the power law distribution. Again, by reducing the minimum marketable and profitable price point, there is a big potential customer base to be gained at the bottom end of the pricing scale. Most companies leave an amazing amount of revenue on the table by not addressing this issue.

Among the things announced this week in GDC were two developments in entirely different directions on a particular axis of games technology: first, the OnLive network of thin clients showing network-streamed video games rendered on a server cluster somewhere, and second, the Mozilla/Khronos Group initiative to develop an OpenGL-accelerated, JavaScript-programmed 3D canvas in a web browser. Both have one thing in common: make it possible to run 3D apps (games) on standard devices without prior installations. How they go about that goal is radically different. One of them will fail.

OnLive is not the first company to attempt their idea. It's a basic extension to the same theme that has been around since at least the inception of the X Window System and Sun NeWS in early 80s - graphical thin clients showing applications running somewhere in the network. Further, the idea was explored for 3D games in the late 90s by G-Cluster, which apparently is still around in Japan in some form or another. In my opinion, it's a misguided approach. Certainly there's value to server-side processing, even of graphics, but the final rendering just makes so much more sense to be done on the client even when all of the application logic is remote.

What kind of client? Well, anything that can run a high-performance VM for Java or JavaScript (ie, a modern browser), and has 3D acceleration functionalities built into the graphics pipeline. This includes basically every network-connected device from the cost of $200 upwards: all smart phones, all netbooks, all laptops, all games consoles, and so on. Some of those devices are still intentionally crippled by their manufacturers in terms of operating system support for the required features, and clearly the 3D Canvas development hasn't been finished yet. The hardware capabilities, however, are already deployed to hundreds of millions of consumers.

Ignoring that deployed base and trying to scale a server-side rendering solution to the same figures is just mad. And that's not even considering the framerate and responsiveness constraints that are inescapable simply because of the round-trip network latency of such a system: on a high-bandwidth wired network 10s of milliseconds (not everyone can be situated within a few kilometers of the server cluster), and on radio networks, 100s of ms. Developing high-framerate games under those circumstances is hard enough when you only need to deal within transmitting positional data and adjusting for lag and jitter in both ends - making the games playable when every action made by the player needs to go to the server and back before it shows up is practically speaking impossible.

(Update an hour later) I suppose I should acknowledge that clearly the OnLive approach does have certain benefits to it: no piracy, little hacking of the typical kinds, little opportunity to cheat, and no need for investing in PunkBuster-type technology in the game clients, since none of that is running locally. However, all that just simply will not matter when weighed against the enormous brunt of having to run all that rendering in the wrong end of the MMO network and ignoring the opportunities to disperse so much of the investment and energy requirements to the gamers.