After the VMworld 2011 buzz, a look at VMware AppBlast

As usual, I came away from VMworld thinking that VMware really has their act together.

As usual, I came away from VMworld thinking that VMware really has their act together. I was high on AppBlast, Horizon, Persona, and PCoIP offload cards, and for good reason--it's all cool technology that grows their desktop virtualization offering today and establishes a road map for the future. AppBlast in particular had me geeked out, since to me it meant that VMware is finally paying a bit of attention to the group of people they've been alienating by almost completely ignoring RDSH as a solution for deploying Windows apps.

In case you missed it, AppBlast (very scripted VMware TV video from VMworld) is a technology that allows you to send desktops and applications to any HTML5 browser. The demo at VMworld showed Excel being sent to and iPad and running in the local Safari on the device. Essentially, it was a seamless app running via HTML5, coming from somewhere…else.

The thing about AppBlast, though, is that we only know how the client side works, which is essentially the same way the client side works with the other HTML5 clients out there like RemoteSpark SparkView and Ericom AccessNow. Data is sent via WebSockets and rendered on the client side in the browser via JavaScript and Canvas (which allows JavaScript to address each pixel on the screen and "draw" the image). The mystery of AppBlast is in the backend. Here's what we know:

We learned from Warren Ponder at VMworld (listen here - about 23 minutes in) that AppBlast works outside the OS, even going so far as working with Windows, Linux, Mac (and possibly RDSH), so it's quite a bit different than what we've been seeing in other HTML5 thin clients that actually re-encode the remote protocol data into a text stream useable by WebSockets. This implies a low-level implementation, which seems relatively possible when you consider that VMware can watch what is going on in the guest GPU. The thing is, Warren also mentioned that it doesn't require virtualization (gasp, and I mean that!). Just when we think we have it figured out, it turns out we don't have a clue.

Ultimately, we're left with more questions than answers, like why is VMware focusing on deploying local applications/desktops (i.e. NOT things from the cloud) from devices that may or may not be virtualized? It seems very un-VMware-like.

One reason I firmly believe, although I haven't heard this from anyone at VMware, is that this gives them an answer for the people that worry that there's no session-host-like solution coming out of Palo Alto. I think a solution like AppBlast can answer that call, depending on how it works (and especially if it works on RDSH).

Another reason I see is that this is one of many tools that VMware is going to use to help people build a bridge to that Window-less world that they see on the...well...horizon. If they can remove the Windows desktop from the equation and just give access to the app, all while integrating it with their federation/management/provisioning platform (Horizon), that's a win for them. It means people are going to shift their focus from deploying Windows with Applications on it to deploying Applications. From there, the economics of deploying apps from the cloud should take over.

How it works is also of high importance, because if it's just running single instances of Windows and deploying the apps via HTML5, there's already a bunch of ways to do that. Tying it into Horizon is cool, but I'd expect the flexibility of Horizon to accomodate the other methods, too. Solving the mystery of the backend will expose any licensing or infrastructure complications, not to mention allow people to think about if/how/where they'd use this technology. Plus, if it's really as ubiquitous as Warren said, what's the installation process to get it working on Windows, Linux, and Mac? Are there special hardware requirements?

In the video linked to above, Scott Davis (VMware's desktop CTO) mentioned that there is not currently a productized version of AppBlast, instead referring to it as a core technology (of what I'm not sure). My point here is that lots of things have been mentioned at VMworld only to not appear until months later (if at all...CVP :). So, get excited about AppBlast, but don't hold your breath. Maybe we'll learn soon enough how it works, which will allow us to begin to think about how to implement it. In the meantime, anyone care to speculate?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Played with couple of HTML5 solutions most of them actually in Beta... Great for mobility as "any browser" could allow you to get in but... they will probably reproduce the "Java client" sympton on performance.

Something to watch out carefully.


We have recently released information about our upcoming HTML Gateway technology, which has been in development for the last 6 or so months. Unlike VMware, we are (1) aiming to support any HTML 4/5 browser, (2) actually discussing how the technology works, (3) aiming to support a broad range of mobile application access out-of-the-box and (4) provide a very simple and scalable infrastructure that's a bit more advanced than a laptop sitting under the podium. Check it out at and stay tuned for more information.


AppBlast appears to be the successor to the unsuccessful ThinApp story...

Still, I yawn at this because the major value of an application delivery solution is about how it's managed.

This is why ThinApp failed, and also why I am fairly skeptic on how successful AppBlast will actually be...


Until we get our hands on it, we don't know what we don't know. On a conf call earlier this week, we were given assurances from very high up in VMware's organization that we (Cisco) will be getting a copy of AppBlast as soon as possible.

Personally, I'm very excited about it. I don't think VMware will get it perfectly right on the first version out the gate.  But directionally and vision-wise, it very much aligns with our goals of enabling a post-PC era for corporate computing and easing the transition to the cloud.

One of the first applications we'll want to try is Cisco Jabber -- next generation UC client (currently shipping on Mac OS X, coming to Windows end of year, Q1 next year).  Jabber unifies all of Cisco's collaboration, voice, video clients: Webex Connect, CUPC, CIPC, Tandberg MOVI, etc.

What's awesome about Cisco Jabber is that it uses the best interactive voice/video processing engine in the world = PVE (Precision Video Engine) with CSF2G (Client Services Framework 2nd Gen) developed originally by Tandberg.

If AppBlast could make Jabber accessible from any HTML5 browser AND deliver great performance for voice/video, that alone would be groundbreaking.

I talk more about how all of this in my VMworld 2011 recap:

Bottom-line: we applaud VMware for trying to do this. It's not going to be easy but if they pull it off, it's going to be HUGE.



Unless there's some real gee-whiz stuff going on here, I wouldn't count on audio, let alone bidirectional audio. That video with Scott Davis just showed a sound.

The thing about HTML5 clients for me right now is that they're just "good enough"...nowhere near their native counterparts. I'd bet a sack of nickels that Cisco Jabber is almost useless with AppBlast, and will remain that way until the world finds a way to remote desktops/apps with binary data as opposed to text data via HTML5.


@Doug AppBlast is not some kind of tricked out converter to make all of your apps now HTML5 apps. If you have Windows apps, they are made for Windows, just like MAC apps are made for MACs, etc.

The best experience of an app will be what it was developed for. If you want a proper HTML5 app, build it and don't hack it.

This is also the same with the Windows OS. It is being hacked like crazy for VDI and layering for use of a single golden image and it is not purpose built for it. This is where problems will occur.

Given the lack of information it is hard to say, but IMO AppBlast will have a harder time selling the management story than the GUI story. Without single instance management like RDS they will fail.

Single instance management is the key to successful implementations of DevOps and the Cloud.


Our focus with HTMLGW is to provide solutions for key productivity use cases that would normally require a PC, e.g. editing Office documents (without breaking them), using SharePoint, accessing enterprise web applications written in Flash, Silverlight and Java, editing your cloud-hosted documents with real editors, etc.

Sound and full motion video are interesting use-cases, and do make for really nice demos, but I don't really see them as killer use-cases for solving *producivity* problems. Want video? Just use the native video player of your device. Why go through an intermediary?

@Icelus - agree that management is key and that's an area InstallFree is focusing a lot of attention on. Simple infrastructure, out-of-the-box application deployment and update, simple scaling. All the stuff VMware isn't talking about...



The latest version of WebSockets does support binary data (though the released browsers don't provide the APIs for it yet). So while you still won't be able to directly connect a WebSocket client to an RDP/ICA server due to other protocol restrictions, do expect performance to improve. In fact, even without binary, on a WAN AccessNow performance is comparable to, and often exceeds native RDP.

Audio support is also on the way. Chrome 14, for example, supports audio APIs that will enable downstream audio (we are working on it for a future version).

HTML5 clients might be "good enough" now, but they are improving in leaps and bounds. And  with Microsoft, Google, Apple and the Open Source community in a race to create the best browser, and with Google and Microsoft building their future OSs on top of browsers (ChromeOS, and to an extent Windows 8), even greater improvements await in the future.