The twelve-hour stretch of outages suffered by Google’s App Engine this week set off a debate in the blogosphere about whether “cloud computing” is a smart choice for Internet companies. My take is that beyond what’s already been discussed, two overlooked factors argue against cloud-based computing: the specificity of needs for Internet companies, and the importance of transparency during problems.

By way of background, cloud-based computing and storage services provide servers (often shared or “virtual” servers) and storage capacity on top of which an Internet company can build their application. So, for example, if TrackVia used a cloud-based infrastructure [we don’t – we control our own dedicated server farm at a Tier IV datacenter], then a TrackVia user who downloaded a file from TrackVia would cause our website, behind the scenes, to fetch that file from the cloud-based storage service instead of from a local server. Similarly, if a complex TrackVia report were to be executed, our website would have that report run on and delivered by a could-based virtual server, instead of a local machine. Cloud-based infrastructure can make life simpler for young Internet companies, but it also makes them susceptible to the cloud’s outages. In the last few months, there have been significant cloud-service problems at Amazon, HP, and others.

The cloud/outage debate is usually couched in terms of whether a company like TrackVia thinks they know more about keeping servers up and running than Google, Amazon, or the other mega players. Our uptime record is extremely good, but I’m not going to claim we know more about server management than Google does.

What we do have that Google doesn’t, though, is knowledge of our own needs. When planning infrastructure growth over time, TrackVia and all other web-based software companies have to balance cost, performance, and reliability, with an improvement in one often coming at the expense of the others. The right balance depends on the nature of the application and the customers that use it – in other words, there is a specificity of needs. A cloud provider optimizes that three-sided triangle in light of the aggregate needs of all of its clients. We optimize it in light of the specific needs of our application and our customers. We control our own infrastructure because we want to make our own choices about where to invest in any given month – Faster storage devices? Redundant load balancers? More database servers? More human beings? – instead of having the cloud make those decisions for us.

The second overlooked factor is transparency during problems. If we see an ominous trend in a certain server’s load during the day, we have very granular visibility into the problem and control over the possible solutions. We can communicate to customers what to expect. We can analyze the likelihood that it will happen again. We never have to say to a customer, “TrackVia is performing slowly because Google’s App Engine is performing slowly; we don’t know why; we don’t know how long it will last; we don’t know if it will happen again tomorrow.” Owning our infrastructure allows us to understand and communicate the why, how long, and will-it-happen-again issues. Scoring very well on those dimensions is as important as the uptime record itself. If you don’t believe this, ask your customers.

As cloud computing matures, I expect it to become an increasingly responsible choice for younger companies. But I hope the above illuminates why TrackVia at least decided to go our own way.