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…

Just when you thought that technology had advanced the human conversation as far as it could possibly go, the leaders of the esteemed CNBC network give us their newest innovation.  First called out as the Octobox by Jon Stewart, he brought the new and improved Decabox to our attention this evening.  Having seen this concoction in action, I am at a complete loss as to how this “feature” made it through any semblance of a design review.  Two or three talking heads, coupled with the host, is generally sufficient to guarantee a cacophony bordering on the unintelligible.  The mere suggestion that the addition of heads four or five should have been an offense worthy of dismissal, but 10 heads.  Really?  10?  Really?  I now refer you to Garrity’s Law:

The intellect of individuals in a group decreases exponentially as the number of individuals in the group increases.

This holds true for a meeting of any kind, especially one where television cameras and a national audience are involved.  Yeeessh…

You know, the funny thing about rallies in the market these days, especially the largest one day gain by a country mile, is that it’s hard to know what’s driving the move.  There’s an old saying about the markets, and it relates to dead cats.  I am in no way equipped to make market prognostications given the current turmoil, but it’s hard to look at the advances today and not think that there is something along the lines of a dead cat bounce happening.

The funny thing (depending on your point of view) is that the darn things bounce pretty high when they have had as far a fall as the Dow has seen in the last month.  Recall, we’ve seen 26% decline in the last month alone.  Is now the time to stand up and cheer about the policies working, or a time to sit back and mull over the realities of the market positioning and where things are going?  I’m not sure which it is, but I would really hate for a bunch of people to start congratulating themselves with high-fives and back slaps around the notion that “the plan is working.”  We simply do have enough data at this point to call it.

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.

From Techcrunch: It’s Going To Be A Grinch Christmas: Slowdown Forecast For Online Holiday Sales

There’s been discussion about consumers spending less this winter shopping season, and how the credit crisis is the culprit.  I would like to introduce a thought here, and one that extends a little further down the rabbit hole.  Consider for a moment that demand destruction has in fact occurred.  Consumers are scared and are holding back purchases – everyone understands that concept.  However, the new construct I would like to introduce is the notion that demand destruction will not exceed supply destruction.

What did that mean exactly?  Most retailers, specifically consumer focused retailers, tend to turn profitable around Thanksgiving.  That’s one of the reasons why the day after Thanksgiving is called Black Friday.  This is directly tied to demand coming in the front door (actual or virtual) of the business.  It’s possible that the exogeneous factor of the credit crisis may delay Black Friday, and in fact keep the year in the red.  However, if one also considers the reduced ability to borrow, things get even more challenging for the retailers to turn profitable.

Retailers need to stock up inventory ahead of their selling season.  Inventory is taken on credit terms.  Whether it’s a “net X day” payable, with the ability to return the goods if unsold, or borrowing against the value of the inventory is irrelevant.  Someone, somewhere, needs to borrow funds to make the stuff.  If the ability to borrow is impacted, whether by higher interest rates (pushing down margins and borrowing power), or borrowing is negated all together, the retailer themselves will be harmed because they will have reduced inventories to sell.  With reduced inventories, retailers will be challenged to hit their “black” date.

This puzzle becomes ever more challenging when you consider psychological factors on pricing.  To wit, if retailers fear reduced demand, they may start jumping the gun and offering sales, at reduced prices (and thus reduced margins), to spur demand.  This will have the perverse effect of pushing out even furhter the date at which they would turn black.  An even bleaker picture could envision inventories running out, and credit not being there to keep up with even a reduced demand, at reduced margins.

I can say this – I would not want to be long any retailers for the next two quarters.

From Politico.com:

Treasury’s initial plan was about three pages long. The House version, which failed, stretched to 110. The Senate substitute now runs over 450 pages.

I will, for the most part, stay away from political issues on this blog.  No need to incesnse half my audience, one way or the other.  That said, I find this demonstration of our government at work too difficult to let go.

That’s my emphasis above.  Somehow the bill managed to go from a pamphlet to a novel.  Never mind the fact that the cost of this thing has swelled over 20% from the original ask.  If you have an opinion one way or the other on this thing, I suggest you let your congress  person and/or senator know what you think.  You don’t get to complain if you don’t vote, whether by way of your actual vote in November, or your proverbial vote with a phone call to your representatives.

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.