Cloud Management - A Continuous Perspective
By jasoncatsun on Apr 14, 2009
Clouds are a great example of applying "continuous architecture." Continuous architecture is a subject that has a basis in architecture but its really the cross section of biological thinking and the human task of creation. It's the notion of complex adaptive systems applied to something that historically might have been viewed as static (though buildings and houses are anything but.)
In the cloud, static really doesn't apply. A workload might be on one server one minute, on many the next, or on another in the next instant. This may or may not be apparent to the "developer" or service designer, or even the operator of the cloud, in fact its most likely not.
So how is this accomplished? For years we've (via dynamic infrastructure, JxSON, and other projects) thought that workloads are a composite of elements -- to run they require vLANSs, IPs, CPU, Storage, etc. As computer system technology continues to mature, so do the features, especially around the deployment, management, and virtualization technologies that enable much of the cloud today. Anyone that uses GridEngine or other grid/HPC applications -- this is old school. Yeah there's a resource manager, resources are mapped by the manager process, and they run, report back results.
But how does one assemble a bunch of virtualized resources that need to be brought together to meet the needs of a service? Are all the sub-elements assembled via a model and "put on the stack" or do you do this at runtime? How long does this process take? How does a service know when to return its composite resources back to the "pool?" Does it have a default time to live? The model map of the resources need to ensure that they are providing the level of service required by the service.
I was speaking to a customer the other day and every service by default is deployed in their DC with a 30 day TTL (time to live.) You can "purchase" an exception... I won't get into the downstream effects of this thinking -- and their are many but this forethought is significant.
But it illustrates these two processes....the consumption of composite resources by the deployment (run) requests for services.