I have been traveling around California for the last month meeting various vendors up and down the stack trying to convince them of the benefit of activity based costing & metering in the cloud. It is not exactly an easy task especially as it has far reaching consequences up and down stack, across process boundaries & across cloud service interactions.

Maybe the listing of a dtrace benchmark on the site was not favorable to initiating such discussions between us but bear in mind this is in relation to the integration offered by Java runtimes which fortunately do represent a very big part of todays and future enterprise and cloud platforms.

I would love the opportunity to discuss in person how OpenCore explicit metering model could be served by adhoc query diagnostic solutions which can offer up meters (thread counters) which can then be tied to activities closer to the application & business context.

Our plan for OpenCore is to push for standardization w/ language & runtime mappings as well as integration on the wire for metered cloud service interactions.

This is my last week in the bay area but maybe there is still time for us to meet in person and discuss the pro’s and con’s of both of our designs & works.

Correct me if I’m wrong but isn’t your free advertisement comment referring to a technology that is specific to Java and Java-based applications? If not, are there public clouds that currently use this infrastructure?

Enterprise Software Resource Metering & Application Performance Metric Monitoring
http://opencore.jinspired.com/?page_id=38

Before you left Oracle I had requested a meeting with Oracle product management to explore how OpenCore’s activity based costing & metering runtime could be integrated with dtrace which I see offering unlimited meter creation complimenting OpenCore’s application activity analysis.

Unfortunately no one responded.

You should check out the following cloud related articles.
http://williamlouth.wordpress.com/category/cloud-computing/

You are right that no many of the cloud providers are interested in offering insight into the performance, capacity, and cost mgmt of cloud services and applications. But that will change and hopefully our push for a standard metering interface on the wire will pay off in the long run.

Interesting point about node.js “feeling right” to the Unix programmer. I absolutely agree with you, and I think it’s a result of the same kind of minimalism that we saw with Unix. (And after all, if you agree with my potentially absurd claim that JavaScript is the dynamic C that K&R would have intended, it’s not much of a leap to assert that node.js is its Unix.) I have been interested to see some of the arguments against node.js (including a patronizing and relatively content-less screed from Alex Payne) that essentially amount to complaining that the model doesn’t work (or might not work) under all circumstances. To me, this seems to be a classic strawman: I don’t see Ryan or anyone else making the argument that all software should be rewritten in node.js — just that the node.js model seems to be one that works for one (large) class of systems…

The abstraction offered by node.js “feels just right” to a Unix Programmer. Using libev, v8 is a pragmatic choice for performance.

Arguments against event based systems, such as:
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
seem academic. And your arrival on this scene, I hope, will firmly set a clear course for high performance unix server code.

Good Luck with everything !