Are Cloud Computing Pay Walls Coming?

We're all familiar with Web sites that start out free, then put up a pay wall. Think you won't see the same thing with cloud services?

When it comes to innovation at low cost, it's hard to beat cloud services and applications. As a user of these apps, there's basically no infrastructure cost beyond your ISP fees. On the supply side of apps and services, cloud deployments result in huge cost efficiencies, particularly if the supplier has designed around a multi-tenant architecture. Even if they've just used simple VM deployments, vendors can wring a whole lot more value out of a server rack by driving up utilization rates.

There really are some free lunches in the cloud, but they're not going to last forever. Some very useful free cloud services have gone dark recently, and it seems that even some academic projects aren't getting grants renewed. In the commercial world, some cloud applications have put up a pay wall, now that their user bases have grown and the VCs have grown impatient. The bottom line is that you can't bank on free, and you need a transition strategy when economic reality sets into the cloud. This applies equally to applications, plug-in products/extensions, and services deployed in the cloud.

The Private Cloud

If you're already following a private cloud strategy, you're almost certainly paying for all the key assets already. This gives you essentially complete control of your destiny.

But you might want to double-check for freebies that you take for granted. You may be using a service — even something as simple as a mashup — that has been given away as a teaser. If you can find an open-source version of that freebie, double-down on the private cloud strategy by bringing the service in-house and hosting it in your own cloud. You'll have to bear some incremental deployment, administration, and maintenance costs, but you'll have gotten rid of a dependency.

If the freebie service isn't open-sourced, talk to the provider of that cloud service. See if they are willing to provide a service contract to you with an SLA that applies for as long as you need the service. Beware the tempting upsell: those bright glittery features that the vendor will be advertising for future releases may be the equivalent of bloatware. More important, their "improved" versions are unlikely to be bug-for-bug compatible with what you're using now. Every new feature brings with it more compatibility testing and temptations to rework your side of the application. This usually means integration changes that look trivial but seldom turn out to be. Better to keep it simple.

The Public Cloud

If you're following a public-cloud strategy, the situation is a bit different: your entire objective is to avoid having to take ownership of (or responsibility for) most (if not all) of the services you're using.

Public cloud freeware apps usually start with limited functionality in the totally free version. Within a few quarters, it's typical to see some sort of advertising or sponsorship model added to the UI. (I have yet to see an advertising model added to a SOAP or JSON API, but somebody will devise one soon enough.)

Usually, the pay wall is erected a few months later, in the form of an unrestricted version that enables additional features or higher usage levels of the app or service. In most cases, the freeware is still available and isn't explicitly changed. (However, I have recently seen examples where the freeware is literally turned off or put into read-only mode, rendering it essentially useless.) In order to justify the price for the "full up" version, vendors typically add enough new features that the original user experience and APIs are obsoleted. At the very least, you'll need to do some testing.

1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams