I spent a good portion of today and this evening mulling over the methods for application deployment and trying to figure out a few things; I think it only relevant and interesting that I share whatever insights I have gleaned from very likely thinking too hard.

For some time, I have resisted the very in vogue notion that the future of computing is “in the cloud,” as it were, though no one is quite sure where the cloud is and I’m pretty certain that no one person owns that cloud. Listen to tech podcasts or read tech news for a short amount of time, and you’ll see that many in the technology punditry business are saying that before long, many computers will be nothing more than dummy terminals. You won’t have Microsoft Office, you won’t have complicated desktop applications, and you certainly won’t have the complex operating systems you have now or store your files locally – everything will be handled through Internet-based communication. Your documents and your files will be stored “in the cloud,” and my impression is that everyone wants a piece of this cloud before it floats away.

It wasn’t until today that I really understood the appeal of this methodology.

I’ve been thinking for some time about working with applications and the best ways by which to deliver them. Surely, I’ve been witness to some interesting deployment challenges. Shipping a rather oft-updated Windows application is an exercise in interestingness. Platform difficulties, computer incompatibilities, the threat of having to leave a version of Windows behind based on updates, the difficulty of testing an application intended for thousands of computers on a handful of computers and hoping the sample is good enough… these things are challenges that have been fun and rewarding to work with.

But while evaluating some web applications earlier today, it dawned on me the kinds of advantages that are carried by web development and deployment of applications to users. Assume we’re talking about an application where you want to deliver data to customers in a file format of their choosing, working with databases containing the originating data and databases storing users’ saved information. Let’s take a look at the advantages of traditional deployment:

• Finer control over the look of the user interface.
• Possibly more powerful APIs and extensions to work with. (In some cases.)
• A software deployment model that users are familiar with. (Stick the CD-ROM in the drive.)
• Easier to iterate and test without significant equipment investment (the computers you have can do in a pinch).
• Doesn’t require an infrastructure investment. (You’re not hosting people’s data.)
• You’re not responsible for anything other than making sure your application doesn’t blow up. (You’re not hosting people’s data.)
• You can tailor your user experience to be familiar to users of your chosen platform. (Assuming you are only developing for a single platform.)
• Users can access the application and use it without the need of an Internet connection.
• You don’t really have to worry about scalability.

If you can think of others, please let me know.

Now on the other side of the fence, let’s take a look at the benefits of web deployment of the same application:

• Instant cross-platform compatibility. (Everyone has a web browser, though to be fair not all of them are going to be standards-compliant.)
• You don’t have to ship patches to customers. Cheaper and faster deployment.
• Iterations of the product can be faster because of the above.
• Testing doesn’t require anything more than a couple of computers running multiple browsers to check for compatibility.
• You are taking ownership of the customers’ data, which means you can run the backups so they don’t have to worry about it.
• Removes the need to work with networking code, as the data is hosted in a central location. Multiple users can work on a project without needing a client/server model or other database sharing. They can also work from disparate locations. (People working at home on the same things people are working on at work are no longer a problem.)
• When an environment upgrade is made, you’re not leaving people in the dust (Rails or PHP being updated might inconvenience you for a while, but it’s not like, say, .NET 3.5 not working on Windows 2000.)
• An online service is a stronger motivator for a monthly subscription framework, rather than a single purchase of an application. Since it’s a “service,” and less of a “product,” that connection is more strongly made in users’ minds.
• Easier integration with methods for communicating with the customers. It’s a lot easier to direct people to a discussion forum or to submit a bug when they’re already on the Internet.
• Integrating a “help system” is a lot easier when you can combine it with the application in look and feel. You even gain advantages in deployment through the use of video and other tools that are very Internet-native but due to filesize couldn’t easily be deployed with a desktop app.

There’s advantages on both sides of the scale, but to my eyes the Web-based deployment model is almost instantly preferable. You can get the product updated and change it must faster than if you were preparing a patch for a desktop application, which typically needs to be tested and retested and contains a “ball of updates,” and you no longer have to deal with customers who are frustrated because they have to download a bunch of updates when they first get a disc in the mail, since that disc could be months old, depending on your press run.

You would lose the segment of your users that had a non-existent or nearly-non-existent Internet connection, but I think in an increasing number of cases that’s an acceptable loss.

By switching to a web-deployment model, one of the other things you gain is a potential increase in customer service without the need for additional staff. You can encourage people to use technical support through Internet-based means like Campfire or e-mail, and perhaps even eliminate phone support entirely. If your inline and video help is good enough, the case for doing so is strengthened even more. The application should explain itself adequately.

The huge disadvantage to the Web-based model is the need for additional infrastructure. At the start, this isn’t going to cost much, as your hardware needs can scale with the application, but at the very least, you’re talking a virtual private or dedicated server host, who will help with handling backups and redundancies, and has an Internet connection you can only dream of, to make sure that any problems you encounter are bound by either your code or the hardware you can throw at it, and not a crappy Internet connection. Boxes hosted off-site can always be admin’d by remote. It’s a cost risk that would have to be overcome through smart marketing, a product that people need, and well-chosen subscription levels.

You don’t have to worry as much about ridiculousness like Authenticode, messy operating system-level APIs, or even computer performance in many cases (if they have a slow computer, they have a benchmark for their Web-usage speed already, so they won’t be surprised if your app “runs slowly”). Vista is less of a problem because you’re not impacting the operating system unless you’re saving files out of the Web app, and that’s not anything UAC is going to flip over like it does with many tasks people have taken for granted until now.

The primary advantage of the Web deployment model is faster response time to customers. Because you are theoretically “closer” to the customer using a Web-based model and Internet-style communication, and you can iterate the service more quickly, responses to customer bug reports and feature requests can be performed even multiple times per week – per day if you’re feeling adventurous.

There are certainly applications that don’t lend themselves to the cloud computing model. I don’t think Meebo is a suitable replacement for a desktop IM client, and things like IRC chatting and other communicative apps are still stronger on the desktop. (I like iCal better than Google Calendar, even though I can’t share my calendars as easily.) Desktop apps also provide a relatively unified “look and feel” with the operating system – one of the things I like so much about the Macintosh envrionment. And sometimes, local apps have to deal with a large amount of personal data (like iTunes, though you could theoretically handle that through a streaming model of some kind).

I do think the future is in more and more powerful Web applications that will replace many of the tools we use on the desktop. Some of these already exist, and I’m happy to be using them (Google Reader, how I love you). Some are yet to come, but I think the shift to remote application hosting is only a matter of time.