The End of Orchestration?

By | October 31, 2011

Been away this last week, lying by a pool in the Canary Islands, so apologies for the lack of posts! I did say that I’d write a post about a session I attended at VMworld before I went away, but I had to catch up on a few customer commitments at the end of the week before I went on vacation so I didn’t get a chance to do this then. I promised a post about VSP3205 before I went on leave though, so here it is.

VSP3205 — Technology Preview: VMware vStorage APIs for VM and Application Granular Data with Satyam Vaghani and Vijay Ramachandran from VMware. Before proceeding I need to state  that a technology preview like this session typically discusses features that may make it into a product in approximately 3 years, so don’t expect to see what I’m describing below in next year’s release!

001This session was a repeat of one previously presented at VMworld in Las Vegas that Scott Lowe wrote an excellent post about it when it was presented there so I’m not going to repeat his excellent and detailed report on the content of the session. There are few observations and a couple of interesting conclusions from the session that I do want to make a few comments about though, hence this post.

Firstly, it was very clear from the session that Service Providers customers have become a critically important source of requirements for VMware when developing new products and new product features. The very first slide that Satyam and Vijay showed had a series of customer quotes that illustrated the problem statements that the proposed enhancements to the vStorage APIs would address and at the top of the list was a Service Provider customer quote.

We’d ideally like to provide differentiated services to my customers per application. The problem is that we typically provision large sized LUNs for ease of management. With many applications on a LUN, providing differentiated services per application is impossible – Service Provider

002The fact that an SP specific requirement has made in into a technology preview is important in its own right, but what’s of more interest is that the challenge that this SP is facing is one that many are grappling with today – at significant levels of scale, it becomes extremely difficult or even impossible to manually manage the relationship between the configuration of infrastructure and the functionality and associated service levels provided by differing configurations. As a result, automated, policy driven solutions to manage the relationships between services, infrastructure and service levels become critically important. This is typically the role that a macro orchestration engine would fulfil within a Service Provider Architecture – creating service instances for specific customers with specific characteristics.

So, why The End of Orchestration? This technology preview is an example of the type of capabilities that are required to enable Service Providers to manage the definition of service characteristics in environments of significant scale. The second image shows the ‘Profile-Driven Capacity Provisioning’ approach that a service designer would use to directly assign service characteristics to the infrastructure by defining policies – the example here shows a specific snapshot policy, including user selectable options, being assigned to a storage capacity pool. Linking this capacity pool to a service level definition, or even to a specific customer and a service level enables service instances to be assigned to a particular class of service without the need for overlay or macro orchestration and the complex external data model that would typically describe service levels and their linkage to specific customers.

There’s some irony here in that like many things in IT, making things simpler actually means making things more complex, but moving the complexity somewhere else and abstracting it from the user! In this case the complexity that would normally have been inherent within the orchestration layer has been moved into the policy definition engine within the vStorage API itself, but the net result should be that things get a lot easier for Service Provider service designers when these features begin appear in future releases of vSphere – assuming it’s still called vSphere when this feature becomes generally available of course!

Leave a Reply