A bet on BBCs and VM Mobility

Last week a friend from work bet me I couldn’t write an intelligible blog about ‘BBCs.’ As usual, without thinking too much, I took the bet. So a BBC- British Broadcasting Corporation? Nah, hard to write about customers and you don’t want to violate anyone’s NDA or security posture. So how about the fabled and storied “Bailey’s Banana Creme Colada” from Cyril’s Fish House in Amagansett, New York? What the heck, why not… Cyril’s is a Fish House on the side of the road, pretty good food an interesting cocktail, and quite the following. But what is quite interesting is what Cyril does with his fish house, staff, and such when the summer season ends in the Hamptons. Starting towards the end of summer Cyril pack’s up his staff and supplies and moves to the British Virgin Islands, specifically Anguilla and re-opens there for the yachting season which runs from late-October through just before Memorial Day weekend when the migratory cycle is repeated. Now, this may be a stretch, but I have had several people ask me how they can do the same thing with Virtual Machines. Specifically, “How can I Follow the Sun, Follow the Kilowatt Hour Price, Follow the Customers”? Follow the Sun- think call centers. You want the servers to be in closest proximity to the workers who will be awake and at highest productivity when answering live calls in their time zones. This will ensure maximum responsiveness. Follow the kWh- affordable power. Many utilities offer discounts for off-peak loads, if the virtualization platform understood power pricing and power draw in real-time, and also understood the ‘cost’ associated with a given workload move (bandwidth costing against size of VM for instance) then you could move the workload to the location with the most affordable energy costs at a given time and reduce the OPEX associated with power. (Note: this would be pretty network intensive, but would be a heck of a demo.) Follow the Customers- not dissimilar to Follow the Sun, but if your customer base is migratory then move the workloads to the location that is best able to service their transactions at any given time. Some services will certainly continue to be centralized but other, more real-time, applications can benefit from proximity. I can imagine some of today’s CDNs evolving to limited and then more full-featured VM hosting and tying in to multiple customers virtualization platforms to provide for them the analytics and capacity needed to co-locate workload near demand. Of course, these models, while quite interesting on the surface expose significant network limitations – most significantly the lack of an ESI in the IP structure. Global and Cross-AS workload portability is not pragmatic with today’s protocols and host stacks. (Someone will invariably post the comment- “Can’t you just use DNS to solve this… in short, “No.” DNS A-records are cached both by clients and proxies and TTL is not always adhered to. Your browser will cache an IP address for a given FQDN and then open a socket up, that socket itself needs to remain intact through the move for it to be seamless to the end-user. This is not possible with DNS tweaks.) What ways are you seeing people design around these limitations? (I have seen: really large flat Layer-2 networks that remind me of the Vitalink days, BGP setup VPLS tunnels, emerging standards such as TRILL and LISP, and some more proprietary implementations…) any others? dg