Ashutosh Nilkanth's Blog

Today, most of what we use the Web for on a daily basis aren’t just web pages, they are “applications”. These applications, which run inside our Web browsers, are increasingly becoming more advanced in their functionality and more interactive in their usability.

The Web browser acts as the core container for these applications, and it is critical to any Web application in terms of security, stability, speed, and operability. In the Web browsers space, the much speculated launch of a new browser from Google, called Chrome, marks a very important step in “remaking” the Web. I’m overwhelmed with what Google Chrome offers as a product, and excited too, because this will open up doors to even more advancements in the Web application space.

So, what’s so special about Google Chrome, that’s not already there in existing (and time-tested) Web browsers like Firefox, IE, Opera, Safari etc. I downloaded Chrome (it is open source) and played around with it for a bit, and let me put it this way – Google Chrome is not about what’s there, but about what’s not there. For the Google team, the mantra became “Content, not chrome,” which is sort of weird given the name of the browser. It’s incredible that something as potentially game-changing as a Google browser has stayed under wraps for two years.

With Chrome, the Google team has really worked on two most crucial aspects in any piece of computing software: simplicity, and speed. The interface is darn simple, a true minimal design, and streamlined for power usage as well. In terms of speed, Chrome outperforms any modern Web browser. See, today’s Web applications are powered by client-side scripting and asynchronous client-server operations, all utilizing the JavaScript engine (pretty much). Scripting engine performance benchmarks have indicated that Chrome is at least 10 times faster than Firefox and Safari, and a staggering 50+ times faster than Internet Explorer. Chrome’s V8 scripting engine (written by a small team in Denmark) actually complies the JavaScript code to machine code for faster execution. Moreover, every tab or window in Chrome runs isolated (sandboxed) in its own process (not thread), which means that even if a web page crashes, the rest of the web pages in view are not affected. Chrome is secure too. It is based on the Webkit rendering engine, which powers Apple’s Safari browser.

Google amazes me. I sit here and wonder, isn’t this how it all should have been in the first place. Having looked at Chrome for just a few hours, I can easily say that even in its infancy, it is the most promising Web browser aimed towards the future of Web applications.

In the cloud computing space, there’s the SaaS model, its cousin DaaS, and their distant mate – Platform-as-a-Service (PaaS).

All the “XaaS” platforms exist and operate under the same umbrella, so to speak. The “Comparing Amazon’s and Google’s Platform-as-a-Service (PaaS) Offerings” article illustrates a nice graphical overview of the Amazon EC2 and Google App Engine platforms:

The XaaS platforms out there are great for B2C apps, but I still don’t think that they are quite ready for enterprise computing yet. I think Salesforce, with their user base and current platform, has a better chance of leading (and even redefining) the enterprise-level application delivery model.

Update (14th April): In a contrary move, Google and Salesforce have partnered together and announced the launch of “Salesforce for Google Apps” today. Will this alliance benefit the enterprise customer? I still have my doubts. Taking technology to the enterprise consumers depends a lot on the developer community. The size of the Salesforce developers network might be substantial for their own platform, but would the average Salesforce developer branch out to Google’s App Engine for deployment?

Update (15th April): More Details On The Google-Salesforce “Enemy Of My Enemy Is My Friend” Alliance

With the announcement last night of Google App Engine, it’s now literally possible to build your entire web app on top of Google’s vaunted infrastructure – the BigTable, CPU cycles, and bandwidth – all courtesy Google.

It has already been possible to do that (and more) on top of Amazon’s infrastructure for some time now, and so far, Amazon’s AWS is in the lead. Amazon EC2 and S3 are highly scalable platforms, which provide the advantage of utilizing resources on-demand from an external hosting node as well.

Google App Engine comes with its own limitations, but never-the-less this is Google’s grand entry into consumable cloud computing.

Earlier, I wrote about the SaaS (Software as a Service) model of software application delivery, and it drew the attention of Lars Leckie who writes about SaaS, and more recently wrote about DaaS (Data as a Service), on his blog.

Lars’ company, Hummer Winblad Venture Partners, are big investors in the SaaS domain. They have some 15 SaaS companies in their portfolio. Lars tells me that they have also been building out some best practices on SaaS. Although I couldn’t find the best practices on their website, but it will be worthwhile to publish it online for public review.

Ben Yoskovitz shares his experience with SaaS (Software as a Service), in which he suggests that vendors should charge their customers monthly, or offer discounts for longer term commitments. In my opinion, a more efficient option will be to offer a PAYG (pay as you go) model (with discount incentives), where-by customers should only pay for what they have consumed. Amazon’s Simple Storage Service (Amazon S3) is a good example of this PAYG model.

SaaS is not an entirely new model to software application delivery. It earlier existed in the form of the Application Service Provider (ASP) model. But what’s different about SaaS is that its a platform to serve a proprietary application(s), not only providing a frontend access to the customers, but also providing a rich API for open integration.

SaaS doesn’t limit the customers to just being able to “rent” and run the application, but it also enables them to intergate the application with their business processes through web services. This multi-tenant model is also different in architectural terms, because the SaaS vendor implements a virtual environment with a central (shared) application server but separate (often isolated) databases for each tenant.

However, cluster reliability and performance are still crticial concerns for most SaaS vendors. Moreover, I think that SaaS is not for everyone. The infrastructure required for a robust SaaS platform is not an easy or inexpensive task.

Update (26th March): Martin LaMonica has written about the Cloud computing trend, that encapsulates SaaS.