Skill at computing comes naturally to those who are adept at abstraction. The best developers can instantly change focus - one moment they are orchestrating high level connections between abstract entities; the next they are sweating through the side effects of each individual line of code. Abstraction in computing not only provides necessary containment, but also offers clear boundaries.
There is also something very liberating about that line you don’t need to cross. When I write Java code I’m happy to never think about byte code (unless something is going terribly wrong). And when I did board-level digital design, I could stop at the chip and not think much about individual gates or even transistors. It is undeniably important to understand the entire stack; but nothing would ever get done without sustained focus applied to a narrow segment.
Cloud is the latest in a long line of valuable abstractions that extend the computing stack. It pushes down complex details of systems and their management under a view that promotes self-service and elastic computing. In this way, cloud is as liberating for developers as objects were over assembler.
The physical location of resources is one of the first and most important casualties of such a model. Cloud means you should never have to worry about the day a power failure hits the data center. Of course the truth is that as you move down the stack from cloud to system through transistor to electron, physical location matters a lot. So any cloud is only as good as its ability to accommodate any failure of the real systems that underpin the resource abstraction.
Layer 7 has recently become involved in an interesting project that will showcase how cloud providers (public or private) can manage cloud workloads in the face of threats to their underlying infrastructure. The inspiration for this project is the following display from ESRI, one of the world’s leading GIS vendors:
ESRI developed this display to illustrate wireless outages as a storm rips through central Florida. But suppose now that instead of a wireless base station, each green diamond represents a data center that contributes its hardware resources to a cloud. As the storm moves through the state, it may affect power, communications, and even physical premises. Work loads in the cloud, which ultimately could map to hardware hosted inside at-risk sites, must be shifted transparently to locations that are at less of a risk of a catastrophic failure.
Today, few clouds offer the mass physical dispersion of compute hardware suggested by this display. Amazon Web Services, for instance, has the concept of an availability zone, which consists of several massive data centers interconnected within a region (such as US-East, which is in the Dulles area, or EU, which is hosted in Ireland). Their cloud is designed to leverage this regional redundancy to provide continuous service in the event of a site failure.
This big data center approach makes perfect sense for a service like Amazon. There will always be a place for the large data center that leverages commodity hardware deployed on a breathtaking scale. But there is an alternative that I think is set to become increasingly important. This is the cloud composed of many smaller compute facilities. We will increasingly see large clouds coalesce out of multiple small independent hardware sites—more SETI@home than supercomputer. This is where our initiative provides real value.
These highly mobile, micro-clouds make particular sense in the defense sector. Here, compute resources can be highly mobile, and face threats more diverse and much less predictable than hurricanes. This is an arena in which the physical shape of the cloud may be in continuous change.
This project is being done as a catalyst within the TM Forum, and we will show it at the TM Forum Management World 2012 show in Dublin this May. Catalysts are projects that showcase new technology for executives in the telecommunications and defense industries. This catalyst is sponsored by Telstra, and brings together a number of important contributors, including: