On Tuesday June 24th I’ll be releasing the first public tutorial on my ExperiaSphere universal open-source management and orchestration model. From the first, this activity has been aimed at defining a way to deploy and manage services made up of any combination of legacy technology, SDN, virtual network functions from NFV, and cloud application components. It’s also been a goal to integrate with any OSS, BSS, EMS, or NMS component, to support virtual functions and cloud components without modification or the use of specialized APIs, and above all to utilize open-source technology wherever possible.
Those who have followed my interest in the management and orchestration space know that there were two previous projects with goals that were substantially similar. The first, the original Java open-source ExperiaSphere project, was aimed at validating a model of service management where Java objects representing service features could be composed into applications that would then, through those objects, create services. This “Service Factory” approach was the source of much of my insight into service management, and it derived from work of the IPsphere Forum and the TMF’s NGOSS Contract and SDF activities.
Last year I launched a project to demonstrate that Network Functions Virtualization could be implemented in an open, multi-vendor, manner using these principles. CloudNFV was an implementation project involving a half-dozen vendors, and I served as its Chief Architect from the foundation through the end of January 2014. The project garnered a lot of press and won a TMF Catalyst award in Nice in June 2014, so it’s fair to ask how ExperiaSphere and CloudNFV are related.
To understand the technical differences between CloudNFV and ExperiaSphere we have to start with a technical commonality. Both were based on my “Structured Intelligence” and “Derived Operations” principles that were aimed at making service event handling and management totally virtual. The primary difference between the approaches at the ExperiaSphere technical level arise from the goal of supporting open-source elements, which was not a goal in CloudNFV. Because of the unique capabilities of EnterpriseWeb’s software, CloudNFV combined the service, resource, management, and process models into a single structure called “Active Virtualization”. Active Virtualization glued the work of a lot of other dedicated companies and people into “CloudNFV” and it’s been successfully demonstrated many times.
Operators told me loud and clear that they really wanted an open-source option. Since I could not identify an open-source equivalent to Active Virtualization, ExperiaSphere creates a virtualized service domain to which service lifecycle processes are linked, but it records management data, service variables, and lifecycle event-to-process and resource-to-service bindings in a Management Repository that is linked to but separate from the service modeling domain. Modeling and management are functionally unified but still explicitly separate, because that fits with how open-source tools have evolved. The rest of the goals of the two projects are congruent.
The way that virtual functions are deployed and managed is, from the perspective of the virtual functions themselves, the same for both approaches. VNFs in ExperiaSphere are resources just like devices or architected NMS services like VPNs. Their management interfaces are linked to proxies that populate the Repository with their data as the IETF’s i2aex recommendation describes. That Repository is then the source of information for query-based management proxies that can present aggregated and complex management views through whatever interface is convenient. Any virtual network function that could be deployed by ExperiaSphere could, with proper proxies, be deployed by CloudNFV and vice versa.
SDN and higher-level legacy network features (like “VPN” again) are represented in both architectures by “Service Models” that are presented to the service layer for functional orchestration and that are realized on resources through an Infrastructure Manager (in CloudNFV this was called a “Service Model Handler”). An IM can represent a Service Model “imported” from another provider, so the architecture is self-federating and that is also true for CloudNFV. Because the ExperiaSphere work has to support open source development and integration, the process of building service models and integrating Infrastructure Managers is defined in greater detail for ExperiaSphere, but CloudNFV could be made to work the same way.
There’s a non-technical difference between ExperiaSphere and CloudNFV, though. ExperiaSphere is an architecture or a model of open-source management and orchestration. CloudNFV is a project that sought to prove out these principles in an NFV context. It is an implementation, and ExperiaSphere is not, nor is it my intention to make it into one. The architecture I defined was contributed openly into the public domain for CloudNFV and so it is for ExperiaSphere. It will be up to those who believe that the ExperiaSphere model is useful to drive one or more projects from that model.
In just a few days the slide deck presentation on the overall ExperiaSphere approach will be available on the ExperiaSphere website. I hope everyone with interest in management and orchestration reviews it, and since the approach is open to all you can take whatever parts you like without attribution to me or to ExperiaSphere. I’ll try to answer questions on the approach through my Google+ ExperiaSphere Community (please don’t ask questions like “Can you explain the implementation in detail, taking three months or more?”) but I can’t take individual emails or calls on this unless you want to pay consulting fees.
There will be a video tutorial based on this same material, as soon as I can get it done. There will also be at least four and probably five more tutorials coming out between now and the end of August, based on the service lifecycle steps as a framework for a deeper dive, then looking into broad implementation and integration (time permitting). I designed ExperiaSphere to be open-source-ready, but you could do just parts of it in open source or do it all with completely proprietary tools. You could use a different service modeling and description approach than I’ve proposed and still be open-source, too. You may know of open-source elements I didn’t know about. All of this, I hope, will come out in Community discussions.
I’m going to moderate the community. I’ll accept useful posts but not spam or blatant and non-useful promotions. I’ll give offenders a chance, they remove them. We can make the Community work if everyone is reasonable. If I can’t make it work, then the only avenue I have to answer questions on this will disappear. We’re all in this together.