I’m not saying anything…but I do find the speculative fiction from the news types (this taken from news.com)  The next couple of days will be fast and furious, and there is no shortage of noise coming from the PDC.  I can’t wait to take the muzzle off…

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.

If your cloud provider falls over, but you have no customers using your app, did it really fail?

It’s not so often than I get to poke fun at anyone (yeah, right), but in this day and age where it seems that the only way to get noticed is to have funny cartoons, I figured I would enlist the help of my super secret artisan resource, and poke some fun at our competition.

As I spend more and more time with our partner community discussing all things related to SaaS and PaaS, one topic comes up over and over again.  Having a proper Service Level Agreement (SLA) provided by any potential cloud provider is the most important item on the list of their required items.  The failures of the Amazon cloud (portal and web services) and Google properties (Apps, and App Engine) are well documented, and it has given pause to many of the potential developers in the IT Pro and ISV space.  Their main concern is what is going to happen if they deploy a service or application against that infrastructure?  Who’s neck do they get to choke?

Google App Engine has no mention of an SLA in their terms of service, and they know it.  The GMail guys have one, but like the Amazon S3 SLA (the only one of their web services to have an SLA), it’s 3 9s.  A good start, but not what the enterprise customers are going to need to instill confidence to move to the cloud.  The loss of control associated with moving to the cloud is a powerful disincentive for these developers, and without a higher degree of certainty over the uptime of the services consumed, moving mission critical, line of business applications and services to the cloud becomes a much harder discussion with the business decision makers.

The notable exception here is Joyent, who goes out on a limb to claim 100% uptime in their SLA.  The big issue here, unfortunately, is that as a provider on top of the Amazon services, they are at the mercy of Amazon and their ability to keep their servers up.  The pecuniary consideration Joyent is willing to pay out is not really well within their control, which is unfortunate, and it will be interesting to see how this plays out over time.  However, I definitely give them credit for putting that SLA out there.  The problem with writing late at night is you get your companies mixed up.  Joyent does provide SLA, but they don’t run on Amazon.  Big thanks to Rod at Joyent for keeping me honest on this one.  Joyent is running their own datacenters and have made significant investments across their 4 DCs.  That said, they have had some downtime, which is not unexpected.  It would be very interesting to know the economic impact of their January outage, but something tells me that Rod won’t be so forthcoming with that correction for me. <g>

The company I was thinking about that had tied themselves to the Amazon ship is RightScale.  They have a FAQ tied to their pass through SLAs with Amazon.  The challenge I have with their solution is that if you have access issues, you are advised to log in and launch more instances.  This doesn’t help you if datacenters fall over, power goes down, large scale DDoS attacks, etc.  This only helps for domain / app specific scaling issues, and even then, it doesn’t always solve your problem.

There’s a lot of work to be done in the cloud space, especially if the many business ISVs out there are going to think about porting some or all of their offerings to a platform provider.  The feedback from partners is very clear, and the online conversation backs up this assertion – SLAs are the first stop to winning the hearts and minds of the business ISVs and IT Pro developers.