From Simple to Complex -- Whats the Model for Change?
One of the big struggling points in the "cloud" is around granularity of changes and how to facilitate them. I'm using some "OpenDI" terms in the following discussion -- refer to http://wikis.sun.com/display/OpenDI for more info on that.
The following use case illustrates a very simple change. Updating a config file -- and restarting the services -- but also keeping a network device (or pair of network devices as is usually the case) in sync with the changes.
Looking at the object model for this, it shows how the change is associated with an application instance (which is important from a modeling perspective) but also effects changes on two different targets -- a server node and a network device.
Another example of a composite change might be to multiple consumer provider relationships (e.g. apps and app containers, app containers to OS containers, etc) -- these are almost vertical in nature -- more deep with more complexity. They are typically of higher cost and risk but can be minimized with the right modeling.
This type of model represents many of the changes that are made at the "appliance" level.
The final example shows a simple "horizontal" change across several nodes. A good use case would be to modify the total threads utilized by a JVM -- on similarly configured systems running the same "service" or within the same SDN (Service Delivery Network) service domain.
This diagram shows some of the OpenDI nomenclature -- a config file associated with an application container provides its context. However it is actually "changed" on a file system running on an OS instance. In this example the parameter change is inserted in a new version of a config file -- the element that is actually deployed -- but the element that is "managed" is the variable change. The system must be able to recognize this and deploy the right level of granular change.
Looking at the object model for this, it shows how the change is associated with an application instance (which is important from a modeling perspective) but also effects changes on two different targets -- a server node and a network device.
Another example of a composite change might be to multiple consumer provider relationships (e.g. apps and app containers, app containers to OS containers, etc) -- these are almost vertical in nature -- more deep with more complexity. They are typically of higher cost and risk but can be minimized with the right modeling.
This type of model represents many of the changes that are made at the "appliance" level.
The final example shows a simple "horizontal" change across several nodes. A good use case would be to modify the total threads utilized by a JVM -- on similarly configured systems running the same "service" or within the same SDN (Service Delivery Network) service domain.
This diagram shows some of the OpenDI nomenclature -- a config file associated with an application container provides its context. However it is actually "changed" on a file system running on an OS instance. In this example the parameter change is inserted in a new version of a config file -- the element that is actually deployed -- but the element that is "managed" is the variable change. The system must be able to recognize this and deploy the right level of granular change.
