It has become perhaps de rigueur in the last few years to have some Requests for Proposal or some IT departments still talk to us about the deployment of 'thin clients'.
Most often, when we drill down into what is being requested, it boils down that what they mean is 'browser hosted' applications. Somehow in the last decade it has been accepted within IT culture that browser hosted applications are 'thin' - which begs the question: If browser hosted apps are 'thin', why do they look like Jabba the Hutt?
Quick, run the Task Manager on your Windows client (Select the 'Processes' tab, and sort the processes by clicking on the 'Image Name' (first) column). Which apps are using the most memory? On my machine I have several Internet Explorer windows open - each of them takes around 100 megabytes of memory to run. (And if you're using something other than Internet Explorer, applications like Safari are worse - much more bloated and, on my machine anyway, chew up processor cycles while apparently idle.)
Do tests like these for yourself: Boot up a machine. Run a single instance of Internet Explorer with the 'home page' set to blank. As of this writing, you're going to get an 8 or 9 megabyte program. That seems reasonable. Now browse to Google.com. Voila, a 25 megabyte use of application memory just for the Google home page! Close the application and restart another one. Browse to something like Yahoo.com - more of a 'mash up' than the initial Google screen - there's a 50 megabyte instance for you. Click on the top story - typically, now you are at 75 megabytes. Now do something interesting like browse to Youtube.com. Load up a video, make it HD, how about 150 megabytes of application memory? My current 'favorite' is a Safari based social site aggregator that I use - it takes 200 megabytes just to boot. On a 1 gigabyte machine, I can run it and the OS and not much else. (The importance of doing this with a freshly booted machine and starting new browser instances is that after a while Windows will cache browser application memory and you won't be able to determine which ones take up what amount of space. Once you've got a memory hammer, everything looks like a nail I suppose.)
Please note that I'm not saying that these applications aren't useful. I'm not saying that they aren't perhaps artfully constructed. Like you, I use them every day.
But 'thin' they are not.
Further, in the context of line-of-business applications they are communication inefficient and do not perform well. Using script to format and transfer data from and to databases, they sling tens of thousands to hundreds of thousands of bytes per transaction back and forth using stateless protocol - typically displaying only static data - and start all over again with the next user interaction. This works okay when there are a few users and most of us don't care that we have to wait five seconds for our next CRM screen to display. But try it with 15 users all transacting every few seconds and it doesn't scale well unless a lot of clustering horsepower is thrown on the server side.
In the age of multi-core processors and virtually unlimited memory capacity and address space why does any of this matter? Well, in our business, performance matters. A suite of line-of-business applications utilized in distribution operations must have sub-second response times to users and must have a few tens of millisecond response times to automation equipment.
"Okay, okay" says Mr. IT guy. "I get it. I didn't really mean that the application was memory, i/o, or communication efficient. I meant our organization being able to utilize the promise of internet deployed applications - you know, things like central deployment, transparent upgrades, non-specialized client deployment, that sort of thing."
Well, sir, just to bring you up to date, that's what the Cloud brings to the table. Let's just define that for now as a scalable remote backbone of multi-core processors, memory and virtual machine instances. We can build a virtual secure LAN over such a configuration with your client machines and deploy native remote applications as icons on your desktops - which can be very low capability machines. The applications are centrally deployed and upgraded. They really are 'thin' - our typical applications use less than 10 megabytes of application memory - even middleware - and the most robust application with dozens of tabs open simultaneously traversing thousands of rows of real-time database tables takes less than 20 megabytes. Remote desktop runtime takes less space than that. For that matter, you can access an entire virtual desktop with less than 20 megabytes of application memory on the client. These applications use secure, direct socket to socket communications and in the best case sling dozens - less than 100 - of bytes back and forth to complete a user transaction. We're talking millions of lines of code featuring nearly two decades worth of functionality packaged in run-time instances that occupy less memory space than the application instance of this web page you are reading.
The advent of the Cloud in the last couple of years really has leveled the playing field between browser hosted applications and internet enabled native applications. For line-of-business applications, especially, it is instructive to ponder why SAP, Oracle Applications, and Microsoft Dynamics are deployed as native applications and why, as of this writing, Salesforce.com is pitching their Cloud deployment as the better solution.
And browser hosted applications? Please don't call them 'thin'. That's so [yawn] old school now.
