Useful things to do with the cloud, developer edition

“What is cloud?” was the only discussion about a year ago in cloud computing. Then there was a fragmentation of discussion about different vendor offerings, public vs. private cloud, dev/ops, and the usual FUD that comes around disruptive change. I’ve begun to encounter a more subtle, but meaningful question on the topic more and more: what can I do with cloud computing? Why should I care? Why is it worth the trouble? Here are a few answers, many of which you’ve heard from me before.

Developer-centric

Most of these are for developers and those concerned with applications (hence the popularity of cloud computing for SaaS offerings, like consumer oriented, public web apps). Interestingly, it’s more challenging finding good answers for operations folks unless they take the dev/ops challenge and try to bring developers back into their house. I’m rounding up a similar list for ops folks.

Getting beyond hearing about just suffering

When you’re running all instances of the applications, you can watch how people interact with and use the software, and fine-tuning features accordingly. On-premise software hears mostly about overt needs, which change quickly, and bugs. You always heard about what doesn’t work, but rarely see good data on what works. With the raw data of SaaS usage, you have information about how every user is doing everything in the application.

With a proper analytics platform (enabled by the commoditizion of Big Data from cheap servers, network, and things like Hadopp) you can analyze these heaps of data and use them as input to tune your application the same way movie makers will use test screenings to tune a movie to be more commercially viable, if less artful and innovative. As an even more advanced use, you can do A/B testing to find out the best way to implement a given feature: what page layout drives more customer satisfaction, sales, or whatever goals the software is trying to accomplish.

Aggregated Analytics

Building on top of the endless user data, think about how you can reflect all that data back to the user-base, as a feature of the platform. Look at Spiceworks as an example. They do inventories of 100,000’s of networks of varying sizes and know what type of IT and software those networks are using. Crossed with additional data like ratings from IT admins and some input on the success and failure of various setups (sort of like Amazon reviews, if you need an analog), they can start to automate best practices for IT by pulling from all that raw, but real, usage data. If 4,000 instances of a server tend to break more often than an alternate server they could report on this, allowing users to get a sense for the quality (across the 100,000’s of users in Spiceworks) of that piece of IT.

Delivering features, not releases, or “apps” not “applications

Instead of delivering big releases and “suites,” deliver a feature to customers right when it’s done instead of waiting for the full release. This is the famed Flickr model, where they “release” every day. In reality, you’re just pushing out features as they’re ready. You have to manage feature bloat, perhaps retiring and re-doing old features. But the rate at which you deliver features makes your software always relevant and useful, instead of antiquated. Think of your experience with consumer web sites: the more frequently they introduce a new feature, no matter how small, the more likely you are to value them.

For an ISV/SaaS, this means customer retention, which is the primary selling goal of a SaaS: renewals.

In a business context, one of the biggest threats is being “out of site, out of mind”…and then out of budget. If you, “the IT department,” can deliver a steady stream of functionality to The Business you have a better chance of proving your worth.

Give businesses disposable applications

If you can deliver small chunks of software (“apps”) more frequently and more cheaply, the business-side of the house can create disposable applications: apps that are intended to be used for small runs instead of being “permanent.” Think of the contests on the back of candy packets, or short-run products that will be made only a few times and sold. Or, smaller companies like a local restaurant or retailer that couldn’t afford an app if it was a traditional, fully staffed, application that needed to be supported for years.

In theory, this means you can write more custom applications in business settings: if you can whittle away expenses and time for infrastructure, and if you can keep the same staff, you can spend their time writing “valuable code” for the business. This is promised by every new software technology, and it’s benefits tend to take much longer and be difficult to see. Nonetheless, they do occur, we usually just forget to look.

Roml Lefkowitz gave a great talk called something like “IT Should be a Deli” on this topic at LinuxCon a few years ago – I talk I’ve never been able to find hide nor hair of after seeing it. The idea was that we have too large of a scope for most applications, they should be small, not always perfect, fast, and cheap.

Be a plugin

Build on-top of a PaaS like IPP, Force.com, Google Apps, etc. Fit yourself into a giant market, like the iTunes App Store. Go for volume sales and usage, or finding high paying people in the form factor. Network management, for example. Using pricing as a feature, the $4.99 to $49.99 price.

Drive new business models

For example, use viral spread with employees, instead of as in open source with developers, or in traditional IT marketing with managers and budget holders. Quick sign up and useful integration on shoe-string budgets means you can things like Expensify, “we try to use the employees [who get free accounts] as lead generation into the company, and then we turn around and we convert the entire company at a time .”

One of the most difficult parts of being successful with software is getting people to use and then pay for it, the ease (and potentially lower cost) at which a cloud-based (SaaS) application can be trailed (no need to provision on-premise servers, etc.) and even used might help selling potential customers easier.

(I wrote this several months ago, I wrote this piece for one of the conference magazines around devoxx. As such, it sort of goes with the two cloud related presentations I did there. I’ve updated it slightly.)

Disclosure: Salesforce, Intuit, Spiceworks, and Cloudera are clients.