If I’m to have any hope of creating an open architecture for management and orchestration that satisfies the carriers’ goals for SDN, NFV, and the cloud, then I clearly have to start with what those goals are. The Virtuous Trio, goal-wise, consists of operations efficiency, service agility, and openness and we have to look at the issues for them all.
Operations efficiency can be achieved only when we can apply service automation principles to both the deployment of services and their ongoing lifecycle management. The key point that comes across in conversations with the operators is that you can’t solve operations problems on a per-technology basis. We have to be able to operationalize the services themselves, from top to bottom, across SDN, NFV, and the cloud but also across legacy infrastructure. We also have to be able to integrate what we’ve done with current network operations and OSS/BSS practices and processes.
To make this work, we need two things. First, we need to be able to model a service completely and hierarchically, so that functional elements of the service can decompose into the deployment and parameterization steps needed. Second, we have to provide a mechanism to create arbitrary “service management” views that are derived from the state of the resources deployed to support any of those functional elements, or any of the substructures below.
The goal of service agility is also related to modeling and service automation. A service is a cooperative relationship among resources, and “deployment” or “orchestration” is the process of creating that cooperation. To make something agile, we have to be able to visualize service creation simultaneously from two directions—top-down as a collection of retail components and bottom-up as a collection of resource behaviors. You cannot allow either of these directional processes to utterly dominate; opportunity drives services but technology commitments make them real.
The key to achieving this multi-directional analysis/synthesis process is to have a homogeneous way of modeling at all levels. A service is a number of “objects” or “elements” that are collaterally definitional (what is it, how much does it cost, what parameters does it need…) and structural (how is it connected and deployed). In this model, we can represent what the TMF used to call a “resource-facing service” and that I call a “behavior” (see the original ExperiaSphere work for examples) and also a “customer-facing service” which is a visible and commercial component.
The openness requirement is perhaps the most challenging, in no small part because it’s probably the requirement that vendors will do the most to circumvent even as they pledge allegiance to it. The only sure guarantee of openness is an open-source implementation, which is why I’ve said that my ExperiaSphere model will include a reference architecture using pure open-source tools. However, there will obviously be proprietary implementations of management/orchestration, so we have to address how we can be open even in the face of that.
The answer comes from the software world, with the concept of abstractions or abstract objects/classes. If we visualize a service, or even the processes that create and manage it, as a series of functional elements that have high-level interactions linked to the service lifecycle (from conception to deployment an operationalization) we have something I’ve called a service factory in ExperiaSphere. If we want a bike, we don’t expect someone to spin it up on a lathe or something; we send an order with specifications to a bike factory. Every service can be visualized as having a factory, and a “factory factory” can be visualized as the thing that creates service factories as needed. If we can define the components of a factory we can use software abstraction tools to map current packages and elements into the needed abstract forms, then connect them. This is what OpenStack does in networking, with Neutron models and plugins.
These are the high-level principles I’ve taken as the foundation for my model, and I’ve made pretty good progress in defining some of the critical elements. I know how we need to represent infrastructure and the “behaviors” that are presented by infrastructure upward for deployment and management. I know how we need to represent an open, agile, composable management architecture that can be made to represent logical management views based on the state of the provisioned resources. I know how to represent a complete service process from architecting it to deploying and managing it. Best of all I have a pretty good idea of how we can do this all using completely open standards and open-source tools.
What I’m going to offer is a vision of orchestration and management that will apply to the cloud, SDN, and NFV. It will provide for OSS/BSS integration, incorporate legacy and evolving infrastructure, support all forms of virtualization and hosting of features anywhere from on your own personal device to a vast cloud data center. It will be something I’ve run past the cloud, SDN, and NFV folks and the network operators. Finally, it will be something I share openly with you all.
Where am I now, then? I’ve already had a critical set of discussions with some thought leaders in the open source space to validate my initial model. Starting next week (the week of April 28, 2014) I’m doing webinars for some key standards groups and operators, with the goal of validating the approach and insuring I’ve covered the bases needed. I expect that will take through mid-May to complete. At that point I go to work finalizing the model, which I think will likely take through June and into July.
When then will there be that always-seemingly-elusive something to share with all of you? The answer, sadly, is “It depends”. This activity doesn’t generate revenue for me so I have to limit my time. As soon as I have something I’m sure of, that I can draw in enough detail to explain in a compelling way, I’ll share it. I’m hoping that by some early date in June I’ll have an “open-source map” of management and orchestration that’s suitable for presentation at a high level. I’m hoping to have a complete functional description of the process by mid-July. Whether I can do this will depend on 1) how much time I can commit to the process without interfering with my core business and 2) whether I hit any hurdles or uncover issues that force me to rethink or amplify pieces of the architecture.
Some people have already asked me whether they can help with this. I’ve made it clear (I hope) that this isn’t going to be a CloudNFV-type project because I simply can’t commit that kind of resources to anything else. It’s also hard to get cooperative activities to move forward and stay both cooperative and open; everyone has the same issues with return-on-time commitments I do. I’m not going to ask anyone else to toss their fates to ExperiaSphere winds, so what I’m going to be doing is asking for suggestions and insights and comments along the way. Clients and some selected key resources will be working with me directly on this, and for all the others interested the ExperiaSphere LinkedIn group will be the basis for my providing information and answering questions.
This isn’t a small problem; there are a lot of fundamental issues with the modeling of services, orchestration, and management. Many of these were exposed in the ExperiaSphere project and also in CloudNFV, but I’m looking to make this a reference open-source implementation and that will take more work and time. I’m committed to doing what I’ve said I would do, though, and those of you who know me surely know that I mean that. I’ll keep you posted!