As I work through my day job as the guy in charge of Cloud Services ecosystem development for Microsoft, I have the distinct pleasure of working on some very hard problems.  During my travels, I also get to spend time thinking about topics on which not much brain matter has been spent.  Over the last couple of weeks, I have been thinking about a unique circumstance that could present itself to developers as development continues to migrate to cloud platforms.  Dare Obasanjo has written about some of the attendant challenges with a SaaS platform, but I wanted to throw out a few new ideas.

In times past, ISVs would develop their software and ship it off to their customers when there was a sale.  Way, way back, diskettes were sent, which evolved to CDs, then to DVDs, and eventually net-based delivery.  For the really complicated stuff, a bona fide “systems engineer” would show up with the servers under his arm.  The beauty of this model, from the stand point of running a business, was that you knew exactly how much profit you were making on a customer.  Sales guys have some loose reigns, for the most part, so that they can get the deal done, and their lever is product price.  CFOs can then plug all the data into their spreadsheets and from that they derive the customer profitability.

You see, it doesn’t generally matter if you write bad code.  The first step in all customer service calls for any enterprise software packages is to poke the box.  No matter what the issue is, the first step is to reset the box.  How does that construct carry over in a cloud based world?  With shared hosting, the damage any single tenant can do is limited to the number of other deployments on that shared set of servers.  With a true cloud – a fabric of machines shared across all deployments — there is no proverbial machine to poke.  Mercifully, the cloud architects have thought this through, and are building in self-healing into the infrastructure.

What this example does not envisage is the profitability impact of bad code.  When code goes awry on a customer site, only that customer is impacted.  Profitability never enters into the equitation.  Service support calls, if they are not charged for, are at least baked into the standard service and p contract.  Further, a machine lockup cannot spread in this environment.  In a cloud, thanks to the magic of elasticity, without proper controls in place, errant code can actually spread like a virus, causing machine images to spin up, which in turn drains the profitability of that customer account.

Consumptive pricing for end customers hasn’t yet hit mainstream.  Most pricing (if you are charging at all) is based on price per seat per month or year.  If you are hosting your web app with a hoster, your profitability is locked in when you make the sale.  There is some variability associated with network throughput charges, but for the most part, you’re locked in.  In the cloud world, where all of your resources are billed out 0n a consumptive basis, profitability is now a function of variable cost inputs.  These inputs are impacted by how well your code performs.

Amazon loves to hold out Animoto as an example of the greatness of their platform.  They love to show the chart on the left here.  In a couple of days, usage of the Animoto service exploded.  There’s an accounting of the event in a blog post by the AWS team.  If you do the quick math, they were supporting approximately 74 users per machine instance, and their user/machine image density was on the decline with increased user accounts.  The story they like to tell from this chart is “wow, we were able to spin up 3000 machines over night.  It’s amazing!”  What I see is more along the lines of “holy crap, what is your code doing that you need that many instances for that many users?”  I don’t mean to impugn Animoto here, but I don’t want the point to be lost: the profitability of your project could disappear overnight on account of code behaving badly.

For the most part, the design and efficiency of your code is largely in your hands.  What about a potentially more onerous situation – customers behaving badly?  Revisiting the software license model, a customer can only use so many cycles on the servers to which your application is deployed.  That customer can abuse the code, but they cannot impact the customer experience of any other customer, and they can’t cause you to deliver more machines to them to support their load unless they pay for them.  As such, you’ve collected your money, and they have no impact on your profitability.  In a world where SaaS vendors haven’t yet figured out how to do consumptive based pricing for their offerings, the very real possibility exists that a small handful of customers can abuse your application and destroy not only the profitability of the account, but of your entire P&L.

The simple answer is “quotas,” though that is somewhat harder to enforce in practice when the consumptive unit is not easily measurable.  What kind of a quota can you put in place for a business intelligence application where a micro managing mid-level employee is running wild with “what-if” scenarios?  As more applications migrate to the cloud, there will be plenty of scenarios where the work units are not as simply to constrain as disk or processor usage.

Consumptive costing models, automatic scaling of applications and difficult to define atomic quota units have the potential to create serious financial challenges for cloud based application vendors.  The new challenges will manifest themselves by enforcing rigid software efficiency design goals on development teams, and forcing the operations team to entertain the notion of firing bad customers.  Designing good software is certainly not a new topic, but the possibility of bankrupting a company is not something about which the architects have ever really had to think.

It has been pointed out to me by a commenter and some emails that perhaps the thesis of both Stallman and Ellison is correct, and should not have any hate flakes rained upon them, such as I did with this post.  With that in mind, allow me to suggest some other things that could be confused with cloud computing, per Stallman and Ellison:

1. Daycare services – you send your kids off somewhere where they are processed, and returned to you in a different state
2. Delivered Pizza – you enter your state as “hungry,” make a request on the network, and food is returned in a box object, with a state of “closed” and “hot.”
3. US Postal Service – put your message in the queue, for delivery to a remote end point, with zero guarantee of quality of service
4. Goodyear Blimp – a message is transmitted to many synch points via broadcast mechanism, and based on the message content, message consumers take certain actions

Yes, I am joking, but I’m just trying to underscore the notion that given a broad enough definition, you can lump anything into it.

So it seems that Richard Stallman has proclaimed that cloud computing is stupid.  It appears that Larry Ellison has voiced a similar sentiment.  In case you missed some of the other claims made during the roll out of new technology:

Stanley Schuster, famous horse breeder and seller c. 1910 – “These stupid cars are just a fad.  They aren’t going to love you like a horse.”

Robert Valchek, Polish military tactician c. 1936 – “I’m not sure about this whole tank thing.  It’s stupid really.  What soldier wants to sit inside of tin can, separated from his enemy?  I just don’t see how those things make any kind of an impact.”

James Vanderslotten, home radio salesman c. 1945 – “Moving plays in your living room?  What a waste of time.  Customers want the intimacy of performances acted for them in the comfort of their home, not nitwits on a impersonal screen talking about house cleaners.”

Howard Hallet, big band conductor c. 1962 – “This rock and roll nonsense is nothing but noise.”

Bill Gates, Microsoft CEO c.1981 – “640k is all the memory your computer will ever need.”

Donald McAvoy, Encyclopedia Brittanica salesman c. 1995 – “Disk based encyclopedias?  Who wants that?  People buy encyclopedias because they want to have the books…to turn the pages.”

Joe Stinson, owner Corner Video Rentals c. 2004 – “Mail delivery of DVDs?  Seriously?  What a joke.  How do you browse through titles?  What about the last minute pickup?  What a brain dead idea.”

There you have it…plenty of curmudgeons who have staked their claim on history with some pretty prescient pronouncements.

It should go without saying that the current financial crisis is going to loom large over the business plans of young and new software companies.  In fact, there is an article out that suggests that the removal of Lehman and Merrill from the buyer pool has reduced the IT budget of the financial services sector by 6%.  Let’s let that marinate for a moment.

It’s one thing to have a cyclical contraction in spending.  It’s another thing entirely to compound that problem with demand destruction.  Worse still, the demand destruction is not due to a symptomatic pricing issue, but rather the abject removal of key buyers from the market.

Even more complicating is the difficulties in financing businesses operations.  I’m not talking about raising venture money, but good old commercial credit.  Many companies use debt for expansion, and many times that expansion includes computer systems.  Companies are now having their hands forced to not just pay lip service to lowering their CapEx associated with IT, and moving it to OpEx.  They have no CapEx dollars left.  They need (must) find a way to fund software and services.  Enter SaaS business models, and the Cloud more broadly.  I would expect a knee jerk and rapid migration of buyers in the market to seek out SaaS solutions for line of business applications, and a reduction in spending on CapEx associated with IT.

Here’s the sad irony of the current financial debacle.  IT is what got us here.  IT has been wielded as an offensive asset for many of these firms.  The calculations required to price and model out many of the derivative products they were buying in insane.  I almost took a job at Merrill working on their Fixed Income Derivatives desk back in 1995.  Scary.  Here’s what’s more scary: my Fixed Income homework from my FNC235 class (*there’s a nod to all Wharton peeps who ever had Prof. Basak) is what got me the job.  The MD actually said “hire this guy.  I can’t make heads or tails of his homework and he got them all right.”

People worry about Google being the current incarnation of Skynet, but I would look more to the systems which have been handed the ability to make trades for humans based on human created models which very few people understand, much less can maintain in such manner as to adapt to what are being called 10 sigma events.

I was in NYC when 9/11 happened.  I remember a quote that still hangs with me: that we suffered a failure of imagination in our ability to stop the terrorist attacks.  There’s a similar sentiment to be had here.  The failure of imagination in the building of these models has led to many models essentially acting (reacting?) the same way, causing herd like behavior in a flight to or from assets.  The combination of programmed trading, naked shorts and no uptick rule has led to some serious unintended consequences.