Taking a Horizontal Slice Across the ExperiaSphere Concept

After my blog on a model-driven service lifecycle management technique, I got a bunch of emails from operator and vendor contacts (and from some who’d never contacted me).  Part of the interest was driven by a Light Reading article that noted my skepticism about the way that ETSI NFV was being implemented.   Most was driven by interest in the specifics of the model that I think would work, and it’s that group that I’m addressing here.

My ExperiaSphere approach to NFV has been extensively documented HERE in a series of tutorials, and I’ve now added another tutorial to the list, this one cutting horizontally across the service-lifecycle-stage approach taken by the earlier tutorials.  I’ll be adding it to the ExperiaSphere tutorial list, but in the meantime the new presentation can be found HERE.

My goal in this extra tutorial is to link the event-centric evolution in public cloud services I’ve blogged about, with the needs of network service lifecycle automation.  This was a principle of ExperiaSphere from the very first (which some of you may remember was in 2007), but the specific features of Amazon, Microsoft, and Google can now be used to explain things in a modern-relevant way.

The key point here is the same one I’ve made in the earlier blog I referenced, and that I made to Carol Wilson in the interview for the Light Reading piece.  We have to do NFV using the most modern technology available, which means “event-centric” cloud and data-model-driven portability of features.  We know that now because of the direction that all the major cloud providers are taking.

We’ve built our concept of networking on the notion that a network connects addresses, which represent real and at least somewhat persistent things.  We’re entering an age where the concept of addresses, persistence, or even “things” is restrictive.  In the cloud, there’s no reason why features can’t migrate around to find work, rather than the other way around.  There’s no value to a specific resource, only to resources as a collection.  Users are transient things, and so are the services they consume.  This is the future, both of the cloud and of networking.

All of this was pretty clear a decade ago, and so were the challenges to promoting the vision.  I was a part of a group called the “IPsphere Forum” or IPSF, and it was probably the first initiative that saw services as things you composed on demand.  The founding force behind it was a vendor, which prompted the vendor’s arch-rival to try to torpedo the whole notion.  Operators jumped on it and worked hard to bring it to fruition, but they were defeated in part by regulations that forbid their “collusion” in operator-dominated standards work.  And above all of this was the fact that at the time socializing a concept this broad and different was difficult because most in the industry had never even thought about it.

They think about it now.  We’re now seeing the future of networking differently, and in no small (and sad) part because we’re really seeing it in the cloud and not in the network.  In networking, everyone has focused on protecting their turf as market changes and competition threaten their profits.  There was no massive upside to connection services, no big benefit cloud to fight for.  Cloud provider competition, rather than trying to protect the status quo, is trying to advance the cloud faster into new areas.  Regulations don’t impair cloud providers.  Most of all, for the cloud we’re sitting on a trillion-dollar upside.

That upside could have gone to network providers, both services and equipment.  Networking was, and still is, the broadest of all tech industries in geography and “touch”.  It can tolerate low ROIs, and has plenty of cash to invest.  As an industry, networking has squandered a host of advantages it had in defining the fusion of network and computing that we call “the cloud”.  As an industry, networking has even largely squandered itself, because its future is now out of its own hands.

ExperiaSphere is my attempt to frame the future in at least a straightforward way.  Maybe it’s not something everyone understands, but I think every network and IT and cloud professional would understand it.  I want to emphasize here that I’m not “selling” ExperiaSphere, or in fact selling anything related to it.  The material on the website is all open and public, available to anyone without attribution or fees.  I’m selling an idea, a vision.  Better yet for the bargain-conscious, I’m giving it away in these tutorials and my blogs.

This blog is posted on LinkedIn, and anyone who has a view on the issues I’ve raised can comment and question there.  There’s an ExperiaSphere Google+ community too and I’d be happy to take part in discussions there as well.  Do you share the vision I’ve cited, or do you have reasoned objections?  Let’s hear your views either way.

Posted in Uncategorized | Comments Off on Taking a Horizontal Slice Across the ExperiaSphere Concept

A Very Early Look at What NFV Needs

A lot has been said, and written, about NFV since ten network operators published their “Call for Action” white paper in the fall of 2012.  I’ve contributed my share in blogs and website material relating to how NFV could and should be implemented.  What I’m finding now, admittedly with some frustration, is that many of the points raised early on seem to have been pushed to the background.  Now, late in the process and with little time to fix things, we’re suddenly raising them again.

Back in April of 2013 I gathered a group of vendors at the ISG meeting in California and launched what became CloudNFV.  I became the Chief Architect of the group.  The initiative went public with an approach that summer (you can find the information on the website reference just provided), and in the fall of 2013 we demonstrated the architecture to operators at two separate events.  CloudNFV was also presented as a PoC, and had the honor of being the very first one approved.  In January 2014, the first phase of the PoC was completed and demonstrated to the operator sponsors (Sprint and Telefonica).

The original CloudNFV PoC defined eight goals (quoting from the original PoC applicaton):

  • PoC Project Goal Number One: Demonstrate a framework for the application of NFV principles to actual service provider service creation, deployment and management practices.  We propose to demonstrate four CloudNFV service processes—NodeBuilder, ServiceBuilder, ServiceBroker, and ServiceManager—and to align these both with NFV use cases and architecture and with OSS/BSS/NMS systems and service/operations practices.  The goal is to provide a way of visualizing the potential impact of NFV on service velocity and agility, management efficiency and opex, and reliability/availability.
  • PoC Project Goal Number Two: Identify the optimum way of describing the structure of a service in an NFV environment, including the definition of the NFVs, NFV connectivity with other NFVs, NFV connectivity with the overall end-to-end service, and NFV connectivity with “Infrastructure Services” that may have been pre-deployed and are shared by multiple services.  We have implemented a model that composes low-level structures (“Nodes”) that can represent not only VNFs or VNF packages, but also devices and services.  We believe that many of the suggestions on describing VNF deployment and connection would not describe enough about either to permit them to be used with existing software elements that could provide network functionality—particularly open-source.  That would mean that this software base could not be easily used to support NFV goals.  VNF connectivity must define the network environment that the VNFs were written to run in; anything else is either superfluous or insufficient.
  • PoC Project Goal Number Three: Demonstrate the optimum way of deploying a service, suitable to apply to VNF deployment in the cloud, on virtualized servers, on bare metal servers, and in network devices or CPE, including chips such as the EZChip or other network processors.  We believe that a service will cross over between cloud-deployed VNFs, dedicated-server VNFs, VNFs that run on special blades in devices, etc.  It is critical that all of these hosting options be supported or some of the valuable capabilities of specialized hosting may be lost, and cost savings reduced.
  • PoC Project Goal Number Four: Establish the optimum way of defining management practices as “co-functions” of the service, composed in the same way and at the same time, and representing the service and its elements in the optimum way based on one or more existing sets of operations practices, or in a new way optimized for the virtual world.  The functionality created by combining VNFs defines not only how a service works but how it should/must be managed, and the only way to harmonize management with functionality and at the same time create a link between virtualized elements and real services is to link them at the time of deployment by composing both side-by-side.
  • PoC Project Goal Number Five: Develop the requirements for an NFV-compliant data center, including the hardware issues that would impact performance and stability, the platform software issues, and the mechanism for virtualization.  We have created a harmonized, optimized, model for an NFV data center but have also learned the lessons of how that can be extended.  We have already added a new vendor to our Active Data Center structure (Mellanox) and we are looking to integrate others.  Our practices here can be a guide for NFV deployment in general.
  • PoC Project Goal Number Six: Define the requirements for authoring VNFs and making them portable across multiple implementations.  We have defined an architecture that does not require VNFs be authored to a specialized set of APIs, but we can support an arbitrary “Platform-as-a-Service” developer framework providing that the NFV user has licenses for the APIs involved and that they can be exposed as network interfaces (a URL, for example).  Our goal from the first was to be able to create a VNF by “wrapping” any software component that exposed an interface, any hardware device, or any deployed service, in a CloudNFV description that would allow it to be deployed and managed using our model.  That means that all these things, including existing devices and services, look like NFV to us, which is critical in transitioning to VNF-based service features.
  • PoC Project Goal Number Seven: Determine the attributes for VNFs and VNF packages that would make them suitable/optimum in achieving the requirements defined by the ISG.  For example, we have determined in our use of Metaswitch Clearwater IMS how VNF connectivity must be described and managed and what is needed to make a VNF horizontally scalable.  We evaluated existing open-source software to meet the ISG use-case goals, and found Clearwater IMS from Metaswitch.  The package was not intended to be a VNF, and we were able to deploy it without any changes to the software, largely because it has attributes that make it easy to convert into a VNF.  We can describe those attributes and thus help guide selection of candidate software, and provide specification goals for real software.
  • PoC Project Goal Number Eight: Evaluate the adequacy of explicit and implicit steps to assure openness from the NFV ISG work, and recommend additions/modifications.  We seek to establish whether the current model for NFV and the current functional separation is adequate to insure openness and optimum in addressing the functional requirements set by the two white papers.  We believe that our “totally open” approach allows the ISG to consider whether additional interfaces or functional separation would help advance the ISG’s goals by encouraging component substitution, helping to break down proprietary barriers already being built.

I believed at the time, and still believe, that these PoC goals covered all of the critical issues of NFV, from proving the technical concepts to proving the benefits that could make a business case.  Unfortunately, commercial pressure has done a lot to NFV, and it did a lot to CloudNFV as well.  The objectives of the vendors, understandably, became increasingly commercial as time passed.  That made my position a volunteer, unpaid, architect untenable, and I withdrew in late January 2014, just after Phase One of the PoC completed.  I had prepared a report on findings before my withdrawal as Chief Architect, and after that step I didn’t attempt to socialize the report through the rest of the group for formal publication.  In any event, the goals and structure of the PoC were amended after my departure, and many of the original points dropped, making my comments on them moot.  Operators who knew of the work did ask me for a copy offline, and I provided the report to them as a personal document not a group contribution.

I’m publishing that document now (the link is HERE), because I think it and the original CloudNFV goals show that most of the issues that seem to be perplexing vendors and operators today were recognized in the very first PoC ever approved.  I believe that had the PoC proceeded as it was originally approved, we’d have much better insights on these matters than we have now, and be closer to a full deployment of NFV.  As the PoC goals and this Phase One report show, my own views on what’s needed for NFV to succeed haven’t changed.  I don’t think the needs themselves have changed either, and it’s not too late to take these matters up and resolve them.  Hopefully this publication will help that along.

Posted in Uncategorized | Comments Off on A Very Early Look at What NFV Needs

What Now for ExperiaSphere?

Some of you have asked me what I plan to do next with ExperiaSphere, given that I’ve just published the last of the five tutorials I promised.  The answer is “nothing specific” or maybe “it’s up to you!”

I believe that NFV specifically, and the whole notion of an NGN model in a more general sense, needs a holistic end-to-end, top-to-bottom architecture that virtualizes everything, because I don’t think you can efficiently adopt virtualization in little islands.  We virtualize services, resources, and processes, or we anchor agile things in legacy inertia.

When ExperiaSphere launched as a project back in 2007, the goal was to prove that you could represent service and resource abstractions with software objects.  That was proved, and that concept was the basis for my CloudNFV project in 2013, and for the new ExperiaSphere work directed at an open NFV model that has just been completed.  I think all of this adds up to a pretty well documented proof that this can be done right.

Some of you have expected me to form a company or launch another CloudNFV-like consortium to implement the model I’ve described.  I’m not prepared to do either.  I’m a strategy consultant, and that’s what I want to be.  The job of running a startup is more work than I want at this stage in my life.  I can’t dedicate more uncompensated time to running a group of companies in a cooperative project like CloudNFV was.  So I’ve done as much as I can do with this, and the industry at large now has to decide if the work was useful or not.

I won’t regret my efforts here even if nothing comes of it.  Strategy consulting involves giving a lot of advice you know your client isn’t going to take, but it’s still the truth and still what they should do.  I’ve done my part, and now others are welcome to use as much of this concept as they find useful, and build what serves your own goals.  If further industry activity suggests something more can be done here, within my constraints of donating time, then I’ll take up that something when it arises.

Posted in Uncategorized | Comments Off on What Now for ExperiaSphere?

The Final ExperiaSphere Tutorial is Available!

I’m happy to say that I’ve completed and posted the final ExperiaSphere Tutorial.  You can find this on the ExperiaSphere website or download from below.
Tutorial Five:  ExperiaSphere Service Lifecycle Phase 4: Deployment

  • Slides for the Management phase are available HERE.
  • Annotated slides for the Management p;hase are available HERE; we recommend you use for the notes per slide.
Posted in Uncategorized | Comments Off on The Final ExperiaSphere Tutorial is Available!

Deployment Phase Tutorial Now Available!

I’m happy to announce that the tutorial for the Deployment lifecycle phase of ExperiaSphere is now complete and posted on the ExperiaSphere website.  Click HERE for the page.

There is one more tutorial remaining, on the general Service Management lifecycle phase.  We’ll get to that as work permits!

Posted in Uncategorized | Comments Off on Deployment Phase Tutorial Now Available!

Service Order Phase Tutorial Now Available!

I’ve completed the service order phase tutorial for ExperiaSphere, and posted the tutorials on the ExperiaSphere website.  We have two tutorial formats, one in PDF ONLY for those who want only the slides, and one in ANNOTATED PDF form with my slide notes attached.  As always, this material can be exchanged freely as long as our copyright notices and trademarks are intact.

Please use our Google+ Group to post questions and comments!

Posted in Uncategorized | Comments Off on Service Order Phase Tutorial Now Available!

Service Architect Lifecycle Phase Tutorial is Now Available!

I’m happy to say that I’ve completed the slides and annotated slides for the Service Architect tutorial for ExperiaSphere.  They are now available on the ExperiaSphere website as follows:

  • The slide deck without annotations and in PDF form is available HERE.
  • The annotated slide deck in the same form is available HERE.  We recommend that you use this deck for learning since the notes are highly valuable.

These documents can be shared freely as long as they remain in PDF form with our copyright and trademark notices intact.  You may not use the term “ExperiaSphere” except to describe the documents unless you contact us for permission.

There is no obligation for you to reference us or the ExperiaSphere project or design in your own work, even if it is derived from ExperiaSphere.  We’d hope that you would voluntarily do that, and provide a link to the website, if you do incorporate ExperiaSphere principles into your design or product.

Posted in Uncategorized | Comments Off on Service Architect Lifecycle Phase Tutorial is Now Available!

The Second Tutorial is Coming in August

I’m happy to say that the second of the ExperiaSphere tutorials will be available in August 2014, likely toward the middle of the month.  For those who found the first one heavy going, this one is going to be even worse, but the good news is that successors will get much easier.

The second tutorial is the first of the four “service lifecycle” tutorials aimed at explaining what ExperiaSphere will do and how it will work by following the path of a service from conception to deployment and management.  The tutorial is aimed at the first lifecycle phase, that of the Architect.

ExperiaSphere builds services by harnessing resources.  The inherent behaviors available from cooperative systems of resources like networks or data centers are framed into useful groupings called service models, and these then form the lowest-level building blocks of the services themselves.  The critical step in this evolution from resource to service model is the creation of Logical Resources that are virtual functional chunks that can be instantiated as needed.  ExperiaSphere builds down from them to the actual networks and data centers and up from them to services.  Architects control all this by building object containers for resources, both logical and physical, and these are then used as proxies for the resources in assembling stuff and committing infrastructure to customers.

I know this tutorial is going to be a challenge; it’s over 50 slides.  But it’s the heart of ExperiaSphere, the thing that makes everything else work, and so getting it right will set up for the simpler tutorials on ordering, deployment, and management.

Posted in Uncategorized | Comments Off on The Second Tutorial is Coming in August

ExperiaSphere Tutorial One Slides Available!

I’m pleased to say that the slides (both plain and annotated) for the first of the ExperiaSpere tutorials are now available and the ExperiaSphere website has been updated to track the new open-source-driven management and orchestration model.  Carol Wilson of Light Reading published a nice piece on ExperiaSphere HERE, and I’m happy to finally have the architecture overview complete and published for review.

The slide decks in PDF form can be found at:

http://www.experiasphere.com/ExperiaSphereTutorial1Slides.zip (slides only)

http://www.experiasphere.com/ExperiaSphereTutorial1Annotated.zip (slides and notes)

This tutorial is not a light-hearted romp, and the slide decks aren’t small (37 slides).  I wanted to be sure to convey enough detail to permit a technical planner or architect to evaluate what I suggest and take a stab at laying out a project based on the architecture.  I can be a bit more explanatory in the video that will come next, at the expense of making it an hour and a half long, perhaps!

With this release, I’m moving all of the ExperiaSphere activity to the ExperiaSphere website and blog, and to the Google+ ExperiaSphere Community.  I’ll not be updating the LinkedIn Group further, so be sure you’re registered for the new Community.  I’ve also created an ExperiaSphere Insiders Community on Google+, for those who contact me and commit to actual implementation work.  Not to keep harping on this point, but I can’t support Q&A and clarifications on the approach in any form except posts in the ExperiaSphere Community, so please don’t send me emails with questions or ask for phone calls.  I will try to cooperate with the media, of course.

I’m asking everyone in the ExperiaSphere Community to obey common-sense rules about questions and postings.  Don’t post irrelevant information or something that’s self-serving without advancing the topic.  I don’t want to pull someone from the group or limit admissions, but we all need this forum to be open and useful at the same time, and if we have to sacrifice the former to get the later, so be it.

I’m starting on the four ExperiaSphere lifecycle presentations, and also preparing the audio for the YouTube version of the first tutorial.  I can’t promise exactly when any of this will come out but my goal is to have at least the slide decks (annotated and plain) for all the tutorials available by the end of August.  I look forward to working with those who are really interested through the Community.

Posted in Uncategorized | Comments Off on ExperiaSphere Tutorial One Slides Available!

Tuesday June 24 is the Release of the First Tutorial Slides

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.

 

Posted in Uncategorized | Comments Off on Tuesday June 24 is the Release of the First Tutorial Slides