I spent the better part of the last month looking to buy a new car.  I have to say, I am quite surprised at the tactics that would be employed to sell a car.  It’s bad enough that we are in a bit of an economic, erm, situation borne of borrowing too much and living beyond our means, but to willfully create fiscal irresponsibility is something I could not let go.

Let me start by saying I ultimately bought the Honda Odyssey from the lot in question, Bellevue Honda.  The sales person, Gil, was a great guy, and had nothing to do with my issue.  I take Honda to task.  Since I didn’t notice this “issue” until the day that I was buying the car, I don’t know whether or not this is an issue with other lots.  I suspect it is.

This first picture is from the window of a Honda Insight.  At a whopping 40-45 miles per gallon, what’s not to like about this car?  Sounds great, and the $1,464 in fuel costs per year sounded normal to me.  Normal is a relative term, of course, and I didn’t do the math in my head to sort out if this number made any real sense at all.  It wasn’t until I wandered past a Honda Pilot that I did a double take, with the words “WTF” flying out of my mouth.

You see, the Honda Pilot is one of those SUVs.  They tend to drink gasoline.  I should know, I used to own one.  This sticker shows that they get 16-22 miles per gallon.  That’s an improvement over the initial model year (when I was an owner), but clearly worse than the Insight, right?  Apparently, your estimated fuel costs for the Pilot will be about $1,585 per year.  Again, WTF?  At first I thought that Honda was playing games with the number of miles per year that someone would be driving.  You know, because someone who is driving a hybrid will drive that shit to death because of all the great gas mileage they are getting.  Nope, it turns out that they estimate 15,000 miles per year on both cars.

So the culprit lay at the feet of the estimated fuel costs.  $4.10 per gallon for the Insight and $1.90 for the Pilot.  Again, WTF?  I really, really want to believe that this is not a calculated move on the part of Honda, and in fact the fuel prices reflect the reality of the fuel costs at the time the lot took ownership of the car.  Regardless, with that kind of spread in pricing, the lots should take the initiative and change the stickers in the cars to reflect a price of gasoline more in line with reality.  At $1.90, the estimated fuel costs for the Insight would be about $680.  The Pilot, at $4.10 per gallon, would estimate out to about $3,400.

Again, I want to believe that Honda just dropped the ball.  I don’t want to think that since SUVs have historically been the profit honey pots for car dealerships that they are maliciously misleading customers with an artificially low per year fuel costs to make them seem more affordable.

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.