We’ve all been out, at least once, to a new restaurant or cocktail lounge that was woefully understaffed or otherwise unprepared for the amount of business it had attracted. You see one or two frantic servers are rushing around trying to do the work of a whole crew. Orders are getting stalled and mixed up. The whole place is hurtling toward disaster. Oftentimes, this chaos can be traced back to an underestimation of the operational costs associated with the space chosen or the services provided.
As a patron, perhaps you’re sympathetic to the challenges and expenses common to the food and beverage industry. Maybe you expect mediocre service from a fledgling establishment, and are willing to tolerate it for an exceptional meal or fun atmosphere. Yet, even in the unlikely event that every customer is as understanding, there are still consequences for misjudging the cost of doing business. Technology applications cost money to build and operate just like restaurants. But instead of transporting food and drinks, their operations involve transporting data. In both situations, these costs are undoubtedly greater than zero.
Last week, we saw how having too many cooks in the kitchen can overcomplicate things. And earlier in our series on the Fallacies of Distributed Computing, we talked about the impact of latency and bandwidth limitations — and the soft surrender of embracing low expectations. In today’s penultimate chapter, we’ll discuss how the same kind of complacency about fundamental business questions like transport costs can be damaging at a much deeper level than a negative customer experience. Because if you don’t think about the expense required to keep your application running, it’s probably not going to stay running very long.
As other technology correspondents have covered in detail, even a simple local network incurs costs related to moving data. In addition to the functional components involved – routers, security measures, etc. — there are also hidden costs (time and computing resources) of getting data from the application level to the transport level. And far from curtailing these expenses, the web environment increases the overall cost of data transport dramatically.
Former New Relic engineer Brian Doll emphasized this point in his review of the Fallacies last year – data storage and transport have become the primary commodities of the cloud. So the more you trick out your application, the more these costs are probably going to affect you. If you fail to plan for this up front, you may end up with the technosphere’s most disruptive app that nobody’s ever heard of because you can’t afford hosting. How successful would Hulu or Pandora have become if the developers had tacitly accepted the Fallacy of Free Transport?
Certainly, all developers realize there’s a price to pay for data storage and transport; you’re not going to find any argument to the contrary. In fact, Tim Bray’s article “The Web vs. The Fallacies” – which contends that web technologies have diminished the relevance of the Fallacies – acknowledges that the web has inflated this expense, introducing more complexity for application builders. He affirms that it’s a widely known and accepted fact, even by non-technical users and internal stakeholders.
Yet, like his take on the similar issues of latency and bandwidth, Bray concludes that widespread understanding is precisely what allows application builders to disregard it. Although we don’t advocate overlooking any of the Fallacies, this seems like a more reasonable approach for network latency and bandwidth limitations because their effects primarily concern the user experience. Taking transport costs for granted, however, has consequences far beyond disgruntled users. It can undermine everything you’re trying to do by depriving your application of the financial resources it needs to operate.
Nobody wants to see all that blood, sweat, and takeout food go to waste. Why spend months building an application that could be unsustainable? Even if you’re fortunate enough to have sophisticated, patient users and business partners who understand that moving all these 1s and 0s isn’t free, letting their expectations encourage you to build beyond your means is simply too risky. It’s like debuting a hip new restaurant — recognize the level of service you need to deliver and the kind of traffic to expect, and plan for the expense of operating at that level on a continuous basis. Or generate lots of hype and make a big splash, then fizzle out and fade into obscurity because you ran out of capital.
If your app is intended to do a lot of heavy lifting, like streaming video or real-time updating, then prepare for the accompanying price tag for those services. Try to find cost-effective solutions for data transport. It’s a good idea for the long-term viability of your app, and it means there’s less cost to pass on to users, either directly or via advertising. Plus, you can always scale up as your user base or service offering grows. We’d also obviously be remiss in not mentioning that another way to try and gain some control over transport costs is by eliminating bottlenecks and optimizing performance proactively. Such as with a real-time app monitoring and management solution, for example.
Next up: Final Fallacy — with a surprise twist? Is the last one actually true?