HTTP Performance

Nice to see some rationality brought to the HTTP debate by Mark Nottingham in HTTP Performance. Now we just need another article on HTTP Reliability - or why the browser back button is not a protocol artifact.

Software as a service pros and cons

Phil Wainwright at Loosely Coupled alerted me to the fact that my RSS feed has been stalled since the last update of Blogger early July.

This illustrates the pros and cons of software as a service. The cons was that there is a ripple effect - I use Blogger as a service - no client software, no install, available anywhere, and a single update for all users. Therefore a single bug, change in default settings propagates from Blogger to me to Phil who is trying to consume my RSS feed. The same bug would effect everyone who is using Blogger and consuming RSS feeds.

The pros are a single fix and everyone is back in business. No need to test and deploy software for every platform. This is a radical change in economics and speed of distribution that is changing the playing field. If is no longer about the software it is about the service.

Improved productivity...

Microsoft has the power to increase global corporate efficiency by a single change to Outlook. Change the default meeting times to 20 minutes instead of 30 min. Make the new standard for meetings 20-40-60 bet we could all get the same done in a 20 min meeting as we do in a 30 min meeting the same for 40 versus 60.

Of course this would not stop the creation of more meetings....

Distributed Computing Economics

Slashdot | Distributed Computing Economics Jim Gray has a great article about the economics of distributed computing Distributed Computing Economics:Jim Gray. It lays out how to effectively quantify the benefits of distributed computing, what problems work in what areas. It clears through a lot of the hype created around Grid Computing and On-Demand and puts them into perspective.

There is also what I would call a companion article at Mailing Disks is Faster than Uploading Data that lays out the economics of data transfer. Taken together these articles lay out a very good case for designing systems that move as little data around as possible and centralizing the storage of data as a service in the network.

With cheap storage we are getting incredibly lazy and creating data everywhere. Our sysadmin regularly sends me e-mail about the bloat in my mailbox. Enterprises have databases everywhere and applications have a tendency to be very database centric.

Most enterprise applications store significantly more information than they actual need. The major impact of this is a data synchronization problem. There are many companies building and selling solutions to synchronize this data, but they are solving the wrong problem. We are designing applications wrong, mainly because we do not realize the impact of have data everywhere - after all storage is cheap. The real issue though is managing and synchronizing it is very expensive. Solutions like SForce are delivering storage as a service. This forces people to think in new terms, as storage is essentially free what they are charging for is management. The economics of scale they can bring to managing data reliably are enormous. Over time, I assume they will also provide the visibility and management tools that allow you to understand the flow of your data as it is now becoming part of your services network.

The bloat in my in-box is mainly due to office documents. The reason I get the original not the link is because the sender wants to send me a snapshot i.e. the document at that point in time. As the file system has no versioning (where is VMS when we need it) therefore they do not send a link they send the actual document. One company that has a really cool approach to this problem is Its the Content they have the potential to change how information workers interact and significantly reduce the content in the workspace. [Disclaimer: I have an advisory relationship with ITC.]

Just because it is cheap to build distributed systems and share information does not change the need to consider the fundamental economics and complexity they introduce. The companies that understand this will be able to take advantage of the services network the others will become mired in complexity

Patterns of persistence

Jon Udell: Patterns of persistence takes a bold stance on separating persistence in J2EE from relational databases. I agree with his points and I now have to go play with JBoss 4.0 to see what they have cooked up. For anyone interested in a simple but powerful object database (similar to ObjectStore but no post processing) I would recommend Db4o. I have not used it in any production applications but I am looking at using for my blog visualization tool.

Several years ago Sun had a project to put orthogonal persistence into Java - I am not sure what happened to it but seeing what can be done with Db4o I wish they had continued.

However for most enterprises the technique for getting persistence into the application is not the major issue it is the integrity of the backup and restore solution. This may be getting easier with RAID drives but it is still an issue that is key to any robust persistence solution.

PS Jon, when are you going to enable comments on your blog?