Evolution of Networked Computing

• 1969: As of now, computer networks are still in their infancy, but as they grow up and become sophisticated, we will probably see the spread of 'computer utilities', which like present electric and telephone utilities, will service individual homes and offices across the country. - Leonard Kleinrock, UCLA
• 1984: The network is the computer. - John Gage, Sun Microsystems
• 2008: The data center is the computer. - David Patterson, UC Berkeley
• 2008: Cloud is the computer. - Rajkumar Buyya, Melbourne University

From the book "Distributed and Cloud Computing" by Kai Hwang et al.

The Era of Webapps is Over - Say Hello to Web APIs

I remember a time when developing a web application (webapp) was considered one of the coolest and most exciting feats a software developer could perform. It was not so long ago when a software product with no web application component was considered uncool, unpresentable and unmarketable. A wide range of dynamic web programming technologies and standards were born in this era and they continued to thrive thanks to the unprecedented growth and evolution of the Internet. However today if we take a closer look at how the Internet is being used in our day-to-day lives and in the business world, one thing becomes hauntingly obvious. The era of the webapps has passed. Now is the era of the web APIs.

First of all lets take a closer look at webapps. Webapps are designed to be directly consumed by human users. The user is aware of the URL through which the application can be accessed which he/she enters into a web browser. The web browser then interacts with the remote URL by making HTTP GET requests to pull content and HTTP POST requests to submit content. HTML is used as the primary data exchange format and how the content appears on the user’s web browser (style and formatting) is actually a huge deal. All the important information that should be communicated to the user must be embedded in the HTML payload as that’s the only thing that’s going to get rendered on the screen by the web browser. Things like HTTP status codes and headers do not play a big role in webapps, except perhaps when reporting an error (404 Not Found, 500 Internal Server Error etc) and performing a redirect (302 Found + Location header). 

But webapps are increasingly becoming less interesting to both developers and users. Today it’s all about web APIs. Interestingly most of the technologies that are used to develop webapps can also be used to create and expose web APIs. In fact it’s not wrong to say that web APIs are the next generation webapps and webapp development frameworks mutated into web API development frameworks as a consequence of the natural evolution of the web.

So how do web APIs differ from webapps? And what makes them cooler? Unlike webapps, web APIs are not designed to be directly consumed by human users. They are APIs, meaning they are designed to be consumed by other applications. Developers can use web APIs to construct other high level APIs and end-user applications. The end-user may or may not know the exact location or the URL with which the application is interacting with. Web APIs may use any content exchange format but JSON and XML are the most popular choices. A properly designed web API would use most of the available HTTP methods (at very least GET, POST, PUT, DELETE and OPTIONS) combined with the proper use of HTTP status codes and headers to pass critical control information. Things like layout and formatting don’t mean anything in the web API world but effective use of URL patterns, intuitiveness and simplicity of the APIs mean everything.

The end-user applications that are developed using web APIs can include desktop applications and more interestingly mobile applications. In my opinion this is the last nail in the coffin of the webapps. Simply put people are no longer browsing the web. Rather they use mobile apps. Latest reports and Internet usage surveys show that the amount of mobile Internet traffic is starting to bypass the amount of desktop Internet traffic (see the references section). This means the webapps are increasingly becoming obsolete. To point out a real world example lets take GitHub. GitHub is a pretty cool webapp, one of the best in my personal opinion. We can consume this app in a desktop environment using a traditional web browser such as Firefox. We can do the same with a smart phone, using the mini web browser the device is equipped with (eg: Safari for iPhones). But that’s not good enough for us. We need a native GitHub app for our smart phones. And as a result we now have the GitHub app for iPhone and Android platforms. Soon these mobile apps will become dominant traffic sources of GitHub. This has already happened to many of the popular social networking service providers such as Twitter and Facebook. The web API is a more critical component in these systems compared to their webapp counterparts. 

This transition from webapps to web APIs is a crucial one for technology driven companies. They have to carefully assess this trend and adjust their game plans accordingly. Many organizations have already realized the shift towards the web APIs and started to expose their business functionality as web APIs rather than as webapps. Web APIs open up businesses towards a larger and more diverse clientele with ample future proofing and more room for change. This massive push towards APIs has also given birth to the field of API management, which has now become a business of its own and starting to produce many lucrative business opportunities around the world. The growing number of on-premise and cloud API management solutions (Layer7, Apigee, Mashery etc) available is a testament to this fact.

Perhaps the most impacted by this change are the developers. They need to take a whole different stance in the way they think about software solutions that run over the web. They should learn to implement systems for other developers rather than for end users. They should learn to optimize systems for machine-to-machine interaction rather than for human computer interaction. They need to pay a lot of attention to little things like using proper HTTP codes, using proper HTTP headers, and adhering to open standards. Problems they are used to be messing with such as improving the browser compatibility of webapps and session management are becoming less important by day. They will have to learn to pay less attention to things like form authentication and adopt more HTTP-friendly security mechanisms such as BasicAuth and OAuth. API management is going to become a mainstream technology and developers will have to start treating it as primary development tool just like version controlling and issue tracking. Technology platform providers will also have to take this shift seriously. Developers no longer need webapp development frameworks. They need web API development frameworks. This is why platforms like Google App Engine has become so successful. Their staying power resides in their ability to facilitate the development of powerful web APIs with very little amount of code.

So does all this mean traditional webapps are dead (as in dead for good)? Well, not really. The need for webapps will always be there, at least for the foreseeable future. But we will see more dominant deployment and adoption of web APIs compared to webapps. Webapps will become the Cobol of 21st century; Thousands of lines of code are written every year, but nobody gives a damn. Newly implemented webapps will sit on a layer of web APIs making the webapp just one of the many frontends of a larger system. 

All in all, if you’re a developer, some very exciting times are ahead of you. So buckle up!

References

http://news.cnet.com/8301-1023_3-57556943-93/mobile-internet-traffic-gaining-fast-on-desktop-internet-traffic/

http://bits.blogs.nytimes.com/2011/10/12/mobile-accounts-for-7-percent-of-web-traffic-report-says/

http://www.kpcb.com/file/kpcb-internet-trends-2012

Google Chrome, Looking Good

It seems almost everybody is taking a strong liking into Google Chrome these days and almost everybody who has downloaded it seems to be appreciating it a lot. So I myself thought of giving Google Chrome a trial run. 

However I have to say that my first impression on Google Chrome was not a very good one mainly due to the fact that it’s only available for the Windows platform at the moment. I’m an open source fan and that makes me naturally dislike anything that won’t run on Linux out of the box. However I think I can forgive Google for that. I believe they just wanted to keep the things simple by focusing on one target platform since this is only a beta release. Also they probably wanted to get the maximum possible test coverage out of this release. In that case Windows is the only logical solution since whether we like it or not Windows still dominates the client side system software market. (and it will probably remain that way for a long time :-( )

Other than the above mentioned glitch my experience with Google Chrome has been a fairly good one. It’s easy to install and configure. I really like the wording and labeling convention used in Chrome. It’s simple and casual English that anybody can understand. Not a single technical word is used so that even someone who is browsing the Internet for the first time can easily get used to Google Chrome. Even the buttons that are usually rendered as ‘browse’ buttons in other browsers will be rendered as ‘choose file’ buttons. 

The user interfaces are pretty cool too. Chrome UI designers have clearly dumped the approaches taken by IE developers and Firefox developers to come up with their own style. It has no menu bars and no tool bars. All it has is the address bar with few more additional controls embedded into it. The address bar can be used to type in both URLs and search queries. One advantage of this organization is that it makes the browser’s main Window large so that the user can see more content without having to scroll much. But the problem is for someone who is so used to IE or Firefox, figuring out how to control the browser is going to be a bit of a pain.

In my opinion it has slightly better performance compared to Firefox-3 and IE-7. (well at least I feel that way) I have experienced frequent browser crashes with both IE-7 and Firefox-3. But I’m yet to experience that in Chrome. 

Perhaps the most enticing feature of Chrome is that every time a new tab is opened a new process is forked off by the browser. This way each tab gets its own set of resources. This will hopefully rectify most of the memory related issues experienced by other browsers. If you are a regular Firefox user you know that as we continue to open new tabs in Firefox the overall performance of the browser degrades significantly. This is because all the tabs have to share the same set of resource (memory in particular). By dedicating a separate process for each tab Google Chrome effectively deals with this issue.

I will continue to test Google Chrome in the days to come. I just started with Chrome and I will be in a better position to give a comprehensive feedback after another couple of weeks. Until then ‘good job Google’!