For example, we now think about our pictures as stored on a PC or Mac, uploaded through a USB cable and protected by an online service such as Carbonite or Dropbox. We select which pictures to put in Facebook, Flickr or Picasa Web Albums. In a couple of years we’ll think about the pictures as stored primarily online, directly uploaded there by our WiFi or UWB-enabled camera and protected by a service such as Backupify (yes, we’ll still need backups).

Our computers’ will still have our documents and pictures and music downloads but these won’t be the “master” copies but serve merely as performance optimization and offline access caches for the data, in the same way you can read your email on a plane with no WiFi access using Google Gears for Gmail and Cached Exchange mode for Microsoft Outlook. Amazon’s Kindle is another good example. I read my Kindle books on my laptop, iPad, iPhone, Blackberry and, oh yeah, Kindle. All my content is there, locally cached for fast access without requiring connectivity with the latest read position automatically synchronized without me having to even think about it.

Side note: A few weeks ago Google deprecated Gears with an eye towards HTML5 offering more standard approaches for building these types of application experiences. I would expect significant extensions–going well beyond HTML5–to show up in ChromeOS.

The change will profoundly impact both the hardware and SW industry. On the hardware side, it benefits netbooks and tablet devices as well as smartphones. On the software side, it benefits third-generation SaaS players who are targeting this deployment model as they will have a noticeable performance and user experience advantage over current-generation Web apps.

I’m even more excited about fourth-generation SaaS apps whose user experience will automatically scale up and down with the capabilities of the client-side hardware and bandwidth constraints, similar to the way some gaming engines & services work today.

The shift of master data from PCs and local networks to the cloud creates significant opportunities. Get in touch if you are working in this area–I’d love to hear from you.

I will be leading an unPanel (like unConference but smaller) at Xconomy’s Cloud³ Forum. Great lineup of speakers and the audience will be full of pundits (trust me, see the invite list) so the conversation is guaranteed to be both interesting and educational. This isn’t yet another “intro to cloud” or “cloud 101″. Expect a much deeper and more engaging and interactive forum. CloudCamp comes right after. Register here.

Tollbit is a cloud virtualization company with the lofty goal to do for cloud computing what virtualization did for data centers. Wish us luck and stay tuned by following @Tollbit.

I spoke on a panel with Google, IBM, Microsoft and Sun. Their offering are somewhere between vaporware and beta.

• Google recently launched App Engine
• IBM has a big vision and is mastering resources internally
• Microsoft is trying to equate enterprise application hosting and SaaS as cloud services
• Sun recently did a beta release of Project Caroline.

Absent from the discussion due to schedules was Amazon, so I had to be the one to talk about Amazon Web Services. For the record, I like what AWS is doing for the simple reasons that (a) they shipped early and (b) they took a very open approach to the core of cloud computing (EC2 and S3).

The audience focused Q&A on a couple of interesting areas: SLAs/reliability, where is became clear that one-size cloud computing would not fit all, and security/privacy, which is indeed a very interesting topic, especially when one considers, for example, what governments can force your cloud services provider to do with your data.

There are three complementary approaches to both topics or, for that matter, any facet of value-add on top of the core infrastructure-as-a-service cloud computing layer:

• You can architect a solution that achieves your objectives based on core cloud services. For example, since many startups don’t trust Amazon S3 and EC2 not to fail they have made alternative provisions. In another example, one can introduce application-level encryption such that Amazon or Google only keep encrypted data and don’t have access to the keys.
• You can rely on enhanced cloud services, e.g., data encryption add-ins or spreading servers across different zones with an automatic failover layer maintained by the cloud service provider (CSP), etc. This carries potential lock-in implications in exchange for having to solve less of the problem yourself.
• Rather than solving the problem through technology, you can solve it through processes and contracts. For example, failure to meet SLAs can carry financial penalties.  

My point is that the cost to vendors for upgrading products has gone down substantially. First, there were the truck rolls. Then it was about provisioning and shipping the right type of media to the right customer. Then it was about posting a nicely packaged updater online. And, if you are hosting, you don’t even have to package an update–just get it to your servers anyway you can.

As upgrade costs to vendors have gone down, it has become easier to push more and more smaller upgrades. There are other factors driving this trend also, including the spread of security vulnerability exploitation tools. The net effect on customers is not necessarily positive. Just find a CIO and ask him/her about the cost of planned and unplanned outages due to upgrades. For example, several of the Blackberry outages have been pinned on upgrades.

The worst type of upgrade in the shrinkwrap world was a “forced upgrade,” an upgrade that you had to install in order to maintain support coverage or deploy any additional upgrades. As I have been thinking more about building startups that leverage online platforms and cloud computing, I’m starting to realize that almost every SaaS and PaaS upgrade is a forced upgrade.

When Facebook changed the way in which so-called “forced friend invites” were handled last February, hundreds of Facebook application vendors using the F8 platform were affected overnight. They had no control over Facebook’s choice — it was a “forced upgrade.” The only options developers had were to roll with it or get off the platform. This is much different from building applications on top of infrastructure deployed on premises (for example, if you don’t like Vista, don’t upgrade).

Congrats to the Animoto team. They’ve built a very cool service and deserve to get a little breathing room.

Handling this type of spike the old-fashioned way would have been painful and expensive. If you plan on being successful and see these types of spikes in traffic, you should think about cloud computing from day one.