Managing the New Box

[benverghese]

Following up on an earlier blog post about the new Box; the concept is essential to thinking about the case where an individual or an enterprise is buying capacity from a service provider. The new Box — the progression of instances being the VM, the vApp and the VDC — gives us a great way of providing the user with an abstraction to replace the "old Box" in the context of the cloud.  This is what the user is buying from the service provider.

"New Box" sounds good, but how do we manage and secure this new Box when we buy it from a service provider. Typically one buys this box as capacity to deploy one or more applications. The application comes with a set of requirements added at successive layers; by the architect, developer, integrator, deployer. The provider uses these application requirements to create a custom box in the underlying cloud/virtualization platform for each application. These application requirements should also govern the lifecycle of this box.

So essentially the consumer states his requirements, the provider produces a custom box and a set of SLAs associated with the box. The contract with the producer is that this set of SLAs will be maintained or there will be notifications when there is a violation of any SLA. The consumer depends on this to decide if an issue they see is on their side (application) or a problem from the producer. This co-ordination will be essential for efficient fault diagnosis in a cloud.

If you think about it, this is really a reversal of a trend; the trend towards increased integration across the entire stack, bringing together data from the infrastructure and the application to diagnose problems. In the service provider cloud this has to be achieved with the contracts and selective signals across the boundary because there is no direct visibility of details "under the cover". The fidelity of these health signals is critical. This lack of visibility to the end-user means one has to be very clear if the problem happened on the infrastructure side or not. Service providers and their software vendors need to build tools to provide these clear health signals about the infrastructure.

The bigger picture is that if and when we achieve this level of clarity, the separation actually becomes an advantage and not a problem because it breaks the larger problem into two hopefully simpler sub-problems --  infrastructure and applications separately — and no one will need to understand both domains completely. Incidentally, very similar arguments apply to other aspects of management, such as compliance, etc. and represent a new model for management.