Beware of Public Clouds Bearing Too Many Gifts

B. Shimmin
B. Shimmin

Summary Bullets:

  • Public cloud services break the typical 18 month product revision cycle down into smaller, more rapid releases, a practice that varies widely among vendors in terms of frequency, focus (bugs vs. new features) and flexibility.
  • To avoid heavy deployment, training and support issues stemming from quick revision cycles, customers must demand options typically found in on-premises software.

Last week brought an animated and often heated blow up between Oracle’s Larry Ellison and’s Marc Benioff over the best way to deliver a public cloud offering. The argument, which played out publicly across keynotes given by both men during Oracle’s OpenWorld 2011 conference in San Francisco, centered upon whether or not’s cloud was indeed open and whether or not Oracle’s newly launched Public Cloud platform was in fact a public cloud. Such a public debate can only serve to ultimately make things easier for enterprise IT departments by exposing many of the often overlooked issues associated with cloud-borne software such as partial multitenancy or API-induced data siloing. But to this analyst’s mind, the debate missed what is the biggest hidden ‘gotcha’ – the breakneck speed at which cloud-centric vendors revise their software.

The update cycle for traditional, on-premises software is 18 months. That number shrinks exponentially for software delivered via the cloud. At present, most cloud-capable vendors push updates out every 60 to 90 days. In some more extreme cases, this cycle is repeated every fortnight. And certainly there’s a good reason for this. Bugs can be squashed with more frequency and new features can be introduced in step with fast-moving market trends. Unfortunately, these updates appear as if through an unmanageable fire hose for many customers, forcing at best unplanned user training expenses and at worst development costs stemming from unanticipated errors within customer-built product extensions or customizations.

The best way to avoid these pitfalls is of course to choose your cloud provider wisely. In general, look for a vendor capable of delivering cloud software as though it were on-premises software. This starting point should guide you toward a provider that:

  • Publishes a detailed product update schedule
  • Manages new features and bug fixes as separate product update tracks
  • Offers pre-built training materials for each major release
  • Allows customers to select which features are enabled during a given version update
  • Offers a less-frequent update program that combines many, intermediary changes into one larger deployment
  • Synchronizes feature updates across both cloud- and premises-based software (if both are offered)
  • Allows customers to roll-back to an earlier version
  • Permits customers to lock in on a given update and API for an extended period of time (an important capability for customers employing custom development work)

Fortunately, the current vendor landscape for cloud-borne software, particularly within the collaboration platform marketplace, is fairly mature. Most of the above-mentioned capabilities are available from vendors offering managed hosted software via the cloud. However, when it comes to pure Software-as-a-Service solutions, customers should beware that the level of control available is still in the hands of the vendor, not the user. Thankfully, that is changing, thanks in part to industry movers like Larry Ellison and Marc Benioff, whose combative energies serve to illuminate shortcomings and opportunities within the dynamic marketplace for cloud-based software.

What do you think?

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.