## Democratizing the Cloud using Microsoft Live Labs Volta

Nearly two years ago I posted Beyond LINQ: A Manifesto For Distributed Data-Intensive Programming on this forum. Now, within a period of a few weeks, both LINQ as well as a rather different realization of my original post-LINQ plans are shipping. I am particularly proud to announce that a community preview of Volta is available for immediate download from http://labs.live.com/volta/.

Volta is a collection of tools that enable programmers to develop asynchronous and distributed (including but not limited to AJAX) applications by successive refactoring of normal, sequential, programs written in standard .NET languages (this CTP requires Visual Studio 2008) and deploy the resulting applications on a wide variety of target platforms (this CTP supports Internet Explorer and FireFox). Or as I sometimes say when I am trying to sound like a marketing person â€œ Volta stretches the .NET platform to cover the Cloud.â€ Volta allows programmers to concentrate on the essential complexity involved in building AJAX application and have our tools take care of the gory details and accidental complexity.

When using Volta, programmers can specify their intent of running certain classes on the server by decorating the class declaration using a [RunAtOrigin()] attribute. The Volta post-compiler then weaves in (you never heard me say that I thought AOP was a bad idea did you :-) all the necessary boilerplate code to partition the original program to run across multiple tiers. Similarly, programmers can create an asynchronous version of a method by decorating an empty method declaration of a related signature with an [Async()] attribute. Again, the Volta post-compiler takes care of all the boilerplate code under the hood to enable asynchronous invocation of the target method. Another pain point in writing AJAX applications is supporting multiple browsers. To ease this pain, Volta includes Scott Isaacâ€™s cross-browser compatibility layer that is also used in Windows Live.

Volta embraces the Lean Programming principle of delaying irreversible decisions until the last possible responsible moment. In particular we want to delay decisions about distribution as long as possible. To help developers make informed decisions about the distribution a program across tiers, the Rotunda profiler from MSR is fully integrated in the Volta toolchain. By automatically injection hooks for all interesting events, Rotunda creates trace information that can be inspected using the standard Service Trace Viewer tool.

When I speak about Volta or show a demo, the best compliment I can get is when people say this is â€œtrivialâ€ or â€œreally straightforwardâ€. The best tools are those that do their work unobtrusive hidden in the background. Anyway, with the holidays around the corner you may have some spare cycles to give Volta a spin and let us know what you think!

## Comment viewing options

### Buzzword bingo

I hate to be negative about a front-page post... especially one that's of potentially interesting technology, and also especially as I don't have a "Real Name" (tm) account (and thus quite intentionally a second-class citizen here) ... but, well, WTF?

With this huge wall of text that focuses exclusively on ends rather than means (the latter is what I come here to learn about), I have now learned that there exists something cool called "Volta" that does some sort of weather control and cloud-cover manipulation, as well as help me to eat healthier at my desk while coding.

How about a mention that Volta compiles MSIL to Javascript & does some stuff to make the code distribution/execution environment transparent, something I had to google to find out? Or a critical comparison --or even a mention-- to the Google web toolkit, which to an outsider, sounds like a quite similar approach?

I suspect I'm in the majority (around here) when I say that I respond better to well-defined language rather than "the cloud". As great or not-great as this might be technically (and there's precious little way to tell from the write-up), the post reeks of marketing.

Disclaimer: This post is not intended as knee-jerk MS-bashing.

### Erik's front-page posts

Erik's front-page posts are often much more like blog entries than typical front-page news. Erik is a guest blogger here.

I agree, though, that the tone of this post is quite different from what I usually expect on LtU. The "official blog announcement" has a somewhat more concise description of the product and its technology.

### Erik is indeed a guest

Erik is indeed a guest blogger, and as such has more lee way. I appreciate his contributions, and take responsibility for inviting him...

But... I would like more technical details as well. Erik, how about jumping in with more of the nitty-gritty?

[On further thought, how about we start the discussion by raising more technical questions? I agree, by the way, that this seems like going after the GWT market (which, contrary to my hopes, does not seem to be spreading like wild fire)].

### Not just GWT ...

Links (Wadler's, not Meijer's) is hanging its hat off many of the same ideas, and Joel On Software (does that guy even have a last name?) has Wasabi ... there's also Haxe and OpenLazlo, which I believe have headed to varying degrees down this road. And I'm sure I've missed quite a few others that could be dug up by going back to the threads here about GWT.

So what's new/unique here? From what I can see:

• Bytecode-level, not language-level targeting. (Thus you could use VB or F# or IronPython, presumably.)
• Unified toolchain (debugger, profiler) support. (GWT offers debugging, but maybe not as smoothly integrated?)

Perhaps there's some other aspects that I've missed that are worth getting excited about...

### Links is of course also a

Links is of course also a player in this niche, and was discussed here in this context before. I failed to mention it since it seems to me that it is getting even less traction.

I invite Wadler and Meijer (both honorary members of LtU) as well as anyone from the GWT to contradict me, of course...

### Not sure if its new or unique...

I gathered from looking at the Volta web site, that the novelty of this tool-chain is that you may develop your application as a monolithic whole and then later re-target portions of that application (distributing parts) simply by 'decorating' the code (and I'm sure a whole bunch of heavy magic).

Wasabi and GWT seem to stop at simply being code translators from Wasabi or Java into another language ASP, Javascript.

### I am happy to drill down as deep as you want

I would love to provide technical details at any desired depth. So anyone on this thread that has something in particular that they like to see explained let me know!

### We'll see if we can come up

We'll see if we can come up with some questions... I am too busy at the moment, but others are of course also welcome to ask.

Is there no such information in the linked video and pdf and ... ?

(Not actually a rhetorical question - I haven't followed the links, yet)

### The OOPSLA paper while not

The OOPSLA paper while not that detailed contains a little bit more technical information than the blog post...

### No questions?

I noticed the asynchronous method decoration links to an ajax patterns website, which was a bit puzzling.

I expected this would related to asynchronous methods in polyphonic C#, is it a similar feature, but specialized to ajax?

### Overly chatty?

Is abstracting away the cost of a network message not a double-edged sword? Ought not a networked interface be designed differently than an in-memory interface?

My concern is that if Mort^h^h^h^h Ben is a person who values not learning 'new stuff,' is he really going to understand / appreciate refactoring his "works on my machine" but non-scalable application into a feasible distributed application?

### Volta, GWT, and Jif

In GWT, users write interfaces between the client and server that explicitly capture the partitioning decision. Volta, on the other hand, seems to make tweaking this decision less painful, as you need only add/move around method-level annotations that identify methods that are allowed to run on the server. (This is presumably what Erik means by "lean programming.") However, my understanding is that Volta still requires you to explicitly label everything you want running on the server, and does not attempt automatic partitioning.

I think a more interesting comparison would be with the Jif family, which allows you to label code that you *require* to be running on the server (usually, the reason is of security). With these (minimal) constraints, and the implicit constraints that UI elements must be displayed on the client, Jif performs automatic partitioning by heuristically modeling the communication costs in a graph and finding the proper min-cut/max-flow. Aapparently, this works good enough. The partitioning also happens on a finer-grained, statement-level.

I haven't had time to learn how Links performs partitioning - if anybody has that information, please post! (It would be nice if the related work were presented by the authors rather than by readers....)

### I haven't seen Jif. Thanks

I haven't seen Jif. Thanks for the pointer.

I think that this approach, as you have pointed out, lends itself well to a more automated interpretation (possibly even at request time).

Monolithic apps map pretty well into web apps, although I wonder what could be done to generalize the idea, for example to handle automated deployment and interaction in P2P or XMPP networks.

I hope we can see a decent response to Volta in the open source community sometime soon. Haxe is good, but the lack of support for the JVM and libraries is holding it back from being a serious competitor.

### Automatic partitioning

My gut feeling is that automatic partitioning to client/server requires either a whole program analysis, or a sophisticated type system. I would also bet that almost all of the deployed solutions use the former, while almost all academic ones use the latter.
There is nothing wrong in whole program analysis, if it can be done without sources (using bytecode, for example), and has different options for development (fast analysis, possibly inefficient partitioning) vs. production (slow analysis, optimized partitioning).
It may turn out that no sophistication can reasonably solve this optimization problem offline, so self-tuning at runtime may be the only way to respond to changing database size/hardware capacity/users activity, etc.

### More specific Erik questions

• How exactly does Volta's asynchronous annotation treat exceptions (or timeouts) in asynchronous method calls? As I understand it, you can annotate a method as asynchronous, and then the normal synchronous invocation code will be continuation-split into an implicit callback function (which is how Volta avoids the explicit, GWT-like "remote interface with extra callback arguments" pattern). How then are remote exceptions, communication failures, and other RPC-specific behaviors treated?
• What support does the environment provide for tuning the serialization behavior of objects transmitted from [RunAtServer] classes? The benefit of explicit interfaces is that your serialization points are evident in the code. With [RunAtServer] annotations, it may be a lot easier to suddenly see performance degradation because of unexpectedly many or unexpectedly large network payloads. Does the Volta toolchain currently support profiling of network traffic at the object level?

• how do you debug it all? what kinds of tools exist to gain insight into the system so you can see what performance issues there are and why, or what bugs there are?

### Volta is integrated with VS

Volta is integrated with the Visual Studio toolchain, and works properly with VS profiling (through Rotunda) and debugging.

Volta offers a "debug" mode in which the browser DOM is manipulated directly, allowing logic debugging (watches, breakpoints, etc) in the "real" IL; and a "release" mode, with all code running completely inside the browser. In the "release" mode, the emitted JavaScript can be made terse or verbose, as necessary.

### Volta uses Rotunda

Volta uses Rotunda for profiling. Rotunda profiles the call stack seamlessly across all tiers of the application, making it clear which bits are execution-heavy and which are transport-heavy.

Links allows annotations (client and server) on functions, which insists that the code of that function must run only in that location. Any call to it from the other location is transformed into a remote call; client-to-server calls become AJAX calls and server-to-client calls are tunneled through the AJAX response. This technique is documented in the FMCO '06 paper: http://groups.inf.ed.ac.uk/links/papers/links-fmco06.pdf

Functions that are not annotated are allowed to run anywhere, which allows for the compiler to do something clever; in practice we just run the function in the same place as its callsite. We haven't done any fancy algorithms for partitioning the program.

Our experience has been that programmers have a pretty good intuition about where the code should run, and oftentimes don't care. The win is simply that you can change a function from running on the server to running on the client just by changing a keyword--rather than rewriting the code from the server-side language into JavaScript--which is presumably true of these other systems as well.