…and say hello to Cappuccino in a Cloud.

The Red Hat “Boston” office just moved into new diggs down the street from our old office space.  This is the second move we have made since I got here four years ago and a needed one as the company continues to grow at a steady pace. Inevitably the discussion of coffee makers comes up every time we make a move (and quite frequently in the interim too) with a new coffee gadget showing up shortly after. We opted for the Flavia drink station this time around. This brings up the issue that any new gadget presented to a large audience will inevitably see high traffic for the first few days before the novelty wears off and the traffic reduces to a steady level of consumers.

There are many questions that need to be considered here. Will the machine stand up to the first few weeks of abuse? If it was engineered for a high peak capacity is it still economical to run when that traffic has fallen off? Do we just accept that the first few weeks will see some breakdowns, pissed customers who will not come back because of the failed experience and keep on chugging with the knowledge that our initial costs were low? If coffee making could be parallelized could it scale up and down economically and efficiently?

This is the Cappuccino in a Cloud problem. How do you make processes efficient and scalable for both high load peak and the inevitable lower day to day traffic? The travelling salesman problem dealt with efficiencies of one single entity (the salesman) finding the most efficient (read cheapest) single threaded route through a number of destinations. In today’s word the consumer comes to the buisness or service, sometimes all at once, and it is important to figure out the most efficient way (measured in the consumer’s satisfaction and producer’s bottom line) to handle that load.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]