October 4, 2011
My colleague James Staten recently wrote about AutoDesk Cloud as an exemplar of the move toward App Internet, the concept of implementing applications that are distributed between local and cloud resources in a fashion that is transparent to the user except for the improved experience. His analysis is 100% correct, and AutoDesk Cloud represents a major leap in CAD functionality, intelligently offloading the inherently parallel and intensive rendering tasks and facilitating some aspects of collaboration.
But (and there’s always a “but”), having been involved in graphics technology on and off since the '80s, I would say that “cloud” implementation of rendering and analysis is something that has been incrementally evolving for decades, with hundreds of well-documented distributed environments with desktops fluidly shipping their renderings to local rendering and analysis farms that would today be called private clouds, with the results shipped back to the creating workstations. This work was largely developed and paid for either by universities and by media companies as part of major movie production projects. Some of them were of significant scale, such as “Massive,” the rendering and animation farm for "Lord of the Rings" that had approximately 1,500 compute nodes, and a subsequent installation at Weta that may have up to 7,000 nodes. In my, admittedly arguable, opinion, the move to AutoDesk Cloud, while representing a major jump in capabilities by making the cloud accessible to a huge number of users, does not represent a major architectural innovation, but rather an incremental step.
Silk, the new browser in Amazon’s new Fire tablet, is an entirely different kettle of fish, and may represent more of a differentiator than many people realize. Silk is not just another mobile browser, but rather represents a major refactoring of the browser architecture, splitting its functionality between the local device and the cloud. The most significant aspect of Silk is that it offloads the assembly of complex pages to the cloud and then presents the assembled page to the local browser as a single entity. This is significant, since a typical web page may contain upwards of 50 objects, each of which must go through an HTTP get transaction that can take several hundred ms to complete. Obviously local caching and CD networks can reduce the effective time, but it remains an overhead-intensive process. Silk would assemble the web page in the Amazon EC2 cloud, where the distances between Amazon-resident content is, according to Amazon, in the order of 5 ms as opposed to 100+ ms and then ship the result back to the local browser for display. Amazon also makes vague claims about the local and cloud pieces of the browser being able to negotiate the distribution of the work on the fly for even more efficiency.
So how well does this work, and why is it significant? We’ll have to wait to see how it really works in the real world, but the demos of the browser looked exceptional (of course, Mobile Safari does not set a real high bar, IMHO). What is significant is that Silk represents a complete refactoring of the browser functions in a way that has not been attempted before, since it relies on not only owning the browser platform, but in owning a sufficiently ubiquitous and general-purpose cloud capability that could be assumed as an element in the fundamental architecture of the product. In short a new way to skin a very tired cat and one that will probably trigger a fresh look at many applications that were formerly architecturally tied to a single local resource.
I’d like to hear from people as they get their hands on the Fire tablets so you can tell me if I’m on the right track.