Did Amazon just enter the desktop virtualization space with their Silk web browser?

Yesterday Amazon announced a new tablet device (called the Kindle Fire) which will be a 7-inch tablet running Android. They also announced a new web browser for the device called Amazon Silk.

Yesterday Amazon announced a new tablet device (called the Kindle Fire) which will be a 7-inch tablet running Android. They also announced a new web browser for the device called Amazon Silk. But unlike regular browsers which run locally on the device and process and render HTML, Javascript, images, and everything else locally, Silk is what Amazon is calling a "spilt browser." All the heaving lifting is done in Amazon's EC2 cloud.

Here's a video from a bunch of Amazon engineers explaining it:

In other words, Amazon Silk is kinda-sorta like running a web browser through a remoting protocol, (except Silk will likely provide a better experience since it will be able to split which content needs to go directly to the device versus which content can come from EC2).

So imagine that you combine:

  • Really fast HTML/CSS/JS engine that can render pages way faster on the remote end than on your device.
  • Client device awareness, so the remote end knows your pixel depth, screen size, etc. (so it doesn't have to send you a full size image if your device's screen is just going to shrink it down).
  • WAN accelerator, with benefits like TCP session combining, connection persistence, compression, caching, and prioritization.
  • Remoting Protocols' multimedia redirection, where you send some content to the client to handle and some you render and scrape on the server.

Citrix always talks about how cool NetScalers are in front of web servers. Well this is like the inverse of that, putting all those capabilities at the browser side instead of the server side.

What does silk mean for desktop virtualization?

At first glance, it would seem that Amazon Silk is similar to the Opera Mini or Skyfire browser, and therefore not really relevant to the desktop virtualization space. But both those browsers are really about about browsers on tiny mobile devices. With Amazon Silk, it seems that it's designed to ultimately deliver a better web browsing experience to any device (even if the early versions will just be for the Kindle Fire.)

Since more apps are moving towards web platforms, those apps can now run faster yet still feel like "real" local apps (rather than the "picture" of the web app you get with HDX/RDP/PCoIP).

This is like Chetan's view that most instances of Windows will ultimately move to the cloud. (Except in this case we don't need Windows. But this is the "browser in the cloud.")

What if...

While Silk will initially only be available for the Amazon Kindle Fire tablet, we have to assume it will eventually be available for all platforms, including full laptops. Does this mean that in a few years, all browsers are cloud-backed? Is this the SaaS version of moving the processing to the storage tier?

Maybe there's something here for VMware and Citrix to do as part of their Post-PC end-to-end integration offerings? Perhaps they could build Silk-like (or even Silk) components into their cloud stacks so that companies could use Silk to deliver web apps (internal and external) from their own clouds or from their cloud provider of choice. This would alleviate many of the privacy concerns people have around accessing the web through Amazon.

Because the Silk system takes the client device's characteristics into consideration before sending the content to the client, I wonder if this could also be used to "translate" old apps into new web pages?

What do you think about Silk?


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Need to try it before I'm ready to judge but my first reaction is... sounds like "Internet browsing on AOL"

I used to work at Inktomi. We built these amazingly scalable cache/proxy servers for content delivery networks. Inktomi Traffic Server software  was the service providers answer to Akamai. Back in those days when T1s cost $2k/month and when consumers used dial-up modems to get on the Internet, AOL was the king. AOL was one of Inktomi's largest customers. One of the reasons AOL was king was they delivered the "best user experience" for the masses at that early time of Internet usage.

One of the tricks AOL did was to keep you on their network with tons of caching and tons of customized portal delivery.  They owned the backend, they owned the front-end, and they did a great deal of content prefetching/caching via Inktomi Traffic Server. And to the average user, the Internet from AOL was faster and better than just using a regular Mozilla, NetScape browser from most other dial-up providers.

Again, hard to judge without using it first but seems like an AOL redux moment? Thoughts?





So, I was all primed to read this article and get a comment stream going, but after reading it and watching the video, I'm thinking "great…I guess we'll see."

Brian said it's the opposite of a NetScaler, and I'm not so sure of that. It seems to me like it's a lot like a NetScaler, because EC2 is making the real web requests and then optimizing that for the browser, which is quite similar.

I think some of the numbers used in the video are a bit of hyperbole, which by itself makes me leery. 100ms round trip for each request? That seems high (although maybe not for WiFi? We're not talking about 3G or 4G here, though, since the Fire is WiFi only). I get the fact that EC2 is hooked up with a fat pipe to the internet, though, and that if it makes the bulk of the requests to sites instead of the local browser, that should increase speed. Still, I wonder how much of an issue that really is. I mean, if a site was already optimized, then maybe it's not that bad. Then again, I hardly think this is a solution to make bad coding look good on the web, so there must be something to it (again....guess we'll see).

The most intriguing part to me is the relationship that the browser will have with EC2, which they call Dynamic Split Browsing. There was a diagram that showed sliders meant to give the impression that processing can be dynamically assigned to the local browser or to EC2. So, for instance, JavaScript can be handled 70% locally, 30% in EC2, while Layout can be handled 85% in EC2 and 15% locally (I made those numbers up, which is ok because I'm not trying sell something…it's just an example). That kind of thing seems like a good idea, because we've learned these past years that when we can do something locally, we should. If Dynamic Split Browsing can help determine that, then good for Amazon for figuring that out.

Ultimately, I guess it boils down to my first thought - I guess we'll see. I have nothing if not an open mind...Mine will be here 11/16.


An end to end stack that is designed to lock you into apps that Amazon would like to retail to you. If the developers can make money easily then this may be the version of Android they bet on as a viable alternative distribution channel to Apple for their wares.

Apple locks you in end to end.

Amazon is trying

Microsoft with Windows 8 will try to do the same.

Key is where will the developers go? Will they pick 1/2 or 3 platforms. What this all about is the application distribution model and controlling it as best as you can. Nothing here will help the enterprise.......