More Details and Refined Status for the ExperiaSphere Project!

I’m trying to provide regular updates on the ExperiaSphere activity without giving you old news or nothing useful.  Hopefully today I have something that avoids these traps!

I’ve determined that the best way to explain ExperiaSphere is to start with a multi-plane vision of services and applications.  The top plane of this, which I’ll call the Service Domain describes the logical structure of a service, experience, or application.  This is related first to what it is, second to how it works in a functional sense, and finally how it can be described as deployable functions.  The bottom plane is the Resource Domain where the real stuff lives—including servers, storage, network equipment, legacy stuff, SDN, and so forth.  The resource domain is a lot of things because there are a lot of old and evolving things that live, will live, even have to live in this space.  It’s a classic moving target or collections of silos so potentially vast that it might look like the Farm Belt from the air.

ExperiaSphere’s goal is to accommodate anything that can be considered a service or a resource, period.  Further, the goal is to accommodate and not to make the other stuff do the accommodating.  Nothing has to change, not cloud or NFV components, not SDN or legacy technology.  The benefits of the network of the future can’t be achieved by limiting how you get there or by making early transitional phases totally unprofitable.  So we accommodate, and we start with a mechanism for defining services and applications that’s totally flexible, creating the Service Domain.

Service Domain functions are represented by objects, which I’ve called the process of structured intelligence because the service domain is about how to structure the intelligence, the logical or functional pieces.  If we’re going to deploy one of these objects we have to be able to map it to something in that vast chaotic world of resources.  We have to bridge these domains.

We actually have to bridge them twice, because there are really two binding issues between the two.  One is the deployment process, the linkage of service object to resources.  The other is the ongoing lifecycle management.  From the very first days of the open-source project that launched ExperiaSphere, we represented these two layers, imposed strict separation, and mandated explicit binding between the two.  One aspect of that binding was a dynamic data model that was built when a service was deployed and sustained as a kind of contractual record of the service.  This works nicely for services built as Java applications, but not so well for something built through a more agile service-architect process set.

The ExperiaSphere model, rather than build two bridges, builds a functional double-decker.  We have an Infrastructure Manager or IM that bridges both the deployment and management functions.  Whatever technology might live down in our resource-domain land of silos, there can be an IM designed to create the deployment and management bridges.  You can deploy any service object (a component of a service, application, experience, or whatever) and manage it on an ongoing basis by having the appropriate IM for it.  Anything that can support an IM, then, can be used as a resource.

Both services and resources have models, and I’m proposing to use the same open standards and open-source tools to describe both domains.  The principles applied in the modeling are consistent with the TMF’s operations structure (GB922) but ExperiaSphere does not use the TMF model explicitly for either services or resources.  I’d rather use an open standard to get open-source support.  It’s possible to map between the TMF model and ExperiaSphere but this is to me an “Adapter” function and it’s beyond the scope of the project.

The Service Domain in ExperiaSphere is a domain of functional models, and the Resource Domain a domain of real stuff.  To get all the siloed possibilities in the latter under some sort of control, ExperiaSphere proposes an i2aex-like repository that will hold not only all of the “primary MIB data” that real resources generate, but also all of the derivations or restatements of primary data that describe the management properties of the service objects.  Why?  Because these objects are virtual devices and we need to be able to make them appear in the most convenient and manageable way.  I called this part “Derived Operations” and it’s the second pillar of ExperiaSphere execution.

Operations processes have to be integrated too, of course.  Every functional Service Domain element defines state/event relationships that will map to the service lifecycle.  For each intersection we define a process link, and that process is treated as a Resource and supported by an Infrastructure Manager (see below).  That allows ExperiaSphere to bind any current or future operations or management task to the lifecycle process, which means that operations at all levels can be integrated with the Service and Resource Domains.  Even cloud applications can be represented as services, decomposed into deployable units, and then lifecycle managed.  Scale-in and –out and other new cloud-driven resilience and performance enhancements are, to ExperiaSphere, secure lifecycle elements and not the responsibility of the applications or functions.  And anything that runs on a platform that can be modeled as a Resource can be deployed and managed.

Our open-source mission here can be viewed in this light.  We need a set of open-source tools that will let us build that functional-symbolism-laden Service Domain.  We need a set of open-source tools that will let us build that great and agile management repository.  The former will obviously have to be a combination of what we could call descriptive/parametric processes and the latter a generic database function surrounded by proxies that can populate and represent it.  The good news is that I’m fairly sure at this point that I can identify what makes up both of these layers, what open-source pieces lie on both banks of the ExperiaSphere stream.  For the Service Domain I can identify tools and even implementations close enough to my own that there’s validation in the real world.  I’m working through the details of exactly how these two layers can work in open-source, and I think I’ll have the answers within a month.  Then it’s a matter of putting together a set of videos to describe them.

The bridge, the Infrastructure Manager, is where most of the variability comes in.  I’m going to propose a standard model for representing the linkage between the layers so that it can adapt to any software component/API.  That means that the Service Domain can speak a single language looking south to the resources.  What will have to be done is to create the shim (which in software is often called an Adapter Design Pattern) to translate this common language to each of those silos, or at least those that a given implementation is prepared to support.  Where there are open-source tools to facilitate this, including OpenStack or OpenDaylight, the shim can link to the existing tool/API set and that will generalize support for anything that the selected tool can support on its own southern border.  I can’t bridge a gap to so diverse a set of resource options as we have already with a single strategy, and no single open-source element does everything needed without at least a bit of customization.  I’m going to go as far as I can, then define what needs to be done to glue the assembly together.

In total, I think that 15% to 20% of an ExperiaSphere implementation could be done using off-the-shelf open-source tools.  The rest will be customization, largely in the area of the IM and the mapping between operations and management processes and the state/event structures that define lifecycle processes for the Service objects.  Existing structural models for things like SDN and the cloud, including OpenDaylight and OpenStack, could be integrated under an IM without anything more than the stub I’ve described.

So this is where we are.  I’m working on the detailed tutorial material, and I expect that it will start with a high-level picture and then divide into additional videos to deliver the details of the Service Domain, the Resource Doman and Derived Operations, the Infrastructure Manager, and a final one applying all this to a model service lifecycle.  The material will obviously take time and it may stretch even into September to get the last of it up.  By August, though, you’ll have enough of the picture to see what open-source software can do for the modern age of virtualization.

Posted in Uncategorized | Comments Off on More Details and Refined Status for the ExperiaSphere Project!

We Are Almost There!

And so it goes on!  I have additional progress to report on the open-source-friendly ExperiaSphere model for management and orchestration for SDN, NFV, and the cloud.  I’ve completed my preliminary webinar series with major stakeholders in the operator and standards space, and it’s taught me a lot.

One thing it’s taught me is that explaining this on a webinar, even at a high level, is very difficult.  We’ve typically needed a hour and a half to simply introduce the model and to map it to open-source elements at a very high level.  My detailed slide deck, what I’ve been using to develop a complete explanation to the level needed to drive implementation, is already north of 70 slides, more than double the size of the high-level deck that took an hour and a half.  You can do the math.

What this means is that I am not going to schedule further webinars on the model.  It’s simply not going to be possible to make them truly valuable.  Instead what I plan  to do is to work harder on a series of public tutorial videos and slide decks.  I’m still planning to be able to release these in late July or early August, because the time I save in not doing other webinars can be directed at building the greater level of content detail I now know I’ll need.  Please check this blog, my LinkedIn Group (ExperiaSphere), my Google+ Channel (TomNolle) for information on when the videos will be available.  The good news is that you can play, stop, and start a video as many times as needed.  Large-audience webinars clearly will not work.

I’ve also been able to assemble enough information to do the critical mappings between the model and open-source tools.  In many cases I’ve identified alternate approaches that could be explored for situations where cost-benefit optimization is essential.  Let me go through the major areas to summarize.

In the critical central service data model, I’ve defined the structure of a service as a hierarchical collection of subordinate components that build downward to the actual resources.  I’ve determined how this model can be specified and how it is linked to deployment and lifecycle management.  While the approach I’m proposing is very “cloud-like”, it is also compatible with SDN and even with legacy elements.

I’ve identified how to extend the NFV IGS’s notion of a “Virtual Infrastructure Manager” to support any link between a functional vision of a service and the corresponding structural representation of components.  My “Infrastructure Manager” will codify both the deployment and management hand-off at the function/structure boundary, which means it identifies how you present and utilize all management data, including that for SDN.

In the management area, I’ve identified a management model that conforms to i2aex proxy repository principles and that provides for the collection of management data from all “real” sources and its dissemination in any logical, structured, form that’s required.  There are a number of enhancements to this area that seem to have potential, including the use of complex event processing (CEP) and big data.

The agile projection of management data is an element in lifecycle management and operations integration, but the other element is also provided in the model.  Service components at any level are finite-state machines that can define states and process events—some of which come from other components and some from underlying management repository processes.  The intersect of the state and event defines the lifecycle process to be run at that point, and so NMS, OSS/BSS, and other processes are integrated into a cohesive lifecycle vision through a common coupling at the service component level.

What my tutorial video is going to do is explain all of this in enough detail that a software team could then go out, get the identified open-source pieces, and integrate them into a structure for open management and orchestration that would work for any resource set that can be represented through one of my “Infrastructure Managers”.  I’m diddling different notions of how to structure multiple tutorials to avoid one of those “Gone With the Wind” endurance contests, viewing-wise.

I’m sure people will have questions on this stuff.  Those clients who want to do consulting on it can obviously do that, but for the rest what I’ll have to do is devise an economically reasonable way of answering inquiries.  What I’m doing there is using the LinkedIn ExperiaSphere main group.  If somebody posts questions or comments there, I’ll do my best to respond.  I’m not going to do phone or webinar work for this sort of support because I can’t absorb the loss of billable time.  Thus, if you are interested in getting questions answered on the model, you’ll need to join the group.  Nothing will be done there other than Q&A; nobody can post without moderation so there will be no spam or job offers.  I’ll post status and answer questions, and that’s that.

If you’ve indicated interest in one of the webinars that were to be done in June or July, I’m sorry to say they won’t be happening.  Not because I don’t want to, but because I know now from experience that the format won’t be enough.  I’ll be putting video tutorials up as soon as possible, and I’m pretty confident that it will be worth the wait.

Posted in Uncategorized | Comments Off on We Are Almost There!

Populating the Functional Zones of ExperiaSphere

I’ve gone through almost a half-dozen webinars/presentations on the ExperiaSphere model, and the good news is that I’ve not found any major issues.  That means that my activity can continue along expected lines and that I should have something I can share in a public video and slide deck by August, as expected.

One thing I did find is that this is a very difficult topic to address in abstract.  My instinct was to present a model for defining orchestrable services, explain what was in it, and then talk about how it could be implemented in open source.  That works OK for people who are somewhat immersed in orchestration and management, but not so well for people without that specialized background.  I’m now looking at a slightly different approach.

What I’m proposing to do going forward is to explain the model by explaining an open-source-mapped implementation of the model.  This means that I’ll start by laying out a representative service lifecycle, the steps operators take in going from an opportunity gleam into the realization and sustaining of customers that address that opportunity.  I’ll then take these steps to illustrate what’s needed and how it’s done using open-source tools and open standards.

It’s also become clear that the problem divides itself into three main areas or “functional zones” of logic.  First, the service model or data structure that defines a service and supports automated provisioning of the service.  Second, the management derivation process that bridges between the functional/conceptual view of a service that a customer or customer-service type would have, and the resource-and-status view that’s needed for network operations and remediation.  Finally, we have the state/event processes that link lifecycle events (wherever they’re generated) with the appropriate network, service, and business processes.  I’m pretty confident at this point that I can identify open-source solutions for all of these three areas, solutions that have (within their areas) some reasonable level of actual market validation.

The challenge now is to figure out how these “solution zones” that align with my problem areas can be merged into a cohesive application.  Certainly there are primitive open tools that can be used to facilitate the development of the linkages.  The question is which tool is best, meaning likely which will offer the best combination of flexibility/agility to respond to changes, but at the same time minimize specialized development and integration.  It does not appear possible to create an industry-wide model for management and orchestration without some custom glue being needed.  There may be better ways than others to get it, but something will have to be developed in the end.

Clearly there’s a relationship between the stuff we can identify in to support our major areas and the glue we’ll need to bind them together.  That’s something that is particularly true in my management derivations category, because you need a lot of flexibility to be able to 1) incorporate data from the widest classes of resources and 2) present that data and derivations of it through the most flexible possible combination of views.  If you have any knowledge of this problem set, please join the LinkedIn Group ExperiaSphere or contact me directly.  I’ll try to put you to work!

Posted in Uncategorized | Comments Off on Populating the Functional Zones of ExperiaSphere

More on the Webinar and ExperiaSphere Q&A Process

We’re heading into our second round of briefings on the new ExperiaSphere model, and I want to let everyone know how the later rounds are going to work, as well as how I’m going to handle Q&A.  I want to start by reiterating that ExperiaSphere is not a project like my previous CloudNFV work—it’s not going to be an implementation with a consortium of vendors and formal contributions to this body and that.  I can’t spend the time on that sort of thing two years in a row!  This is an architecture and what I’m driving is purely information dissemination.  I want everyone to understand this new approach to operations, orchestration, and management, but I have to conserve the time I expend.

On June 9th, I’m scheduling another webinar on ExperiaSphere for network operators only.  The end of June or early July, I’ll schedule another for members of the ETSI NFV ISG, the ONF, and the TMF.  You’ll have to provide your name, company, and title to register for any of these webinars.  While there will be some opportunity for Q&A, I’m dedicating only 90 minutes to the sessions and so all questions will be taken at the end of the material, and with limitations on how many a given attendee can ask, to give everyone a chance.

In either late July or early August depending on my scheduling, I’ll be releasing the full model in an open public disclosure.  This release will be in the form of a slide deck that will also be put onto SlideShare, and a YouTube video for which I’ll provide a link.  Because of the number of people interested and the difficulty in setting a time for everyone, I’ve decided I have to do a video that can be played on demand.  Both these will be available on the ExperiaSphere website.

I can’t do phone calls on this or answer individual emails for Q&A because of the impact it would have on my business.  If you want special 1:1 presentations or personal input and suggestions, I can do it only as a normal consulting activity billed at the normal rate.  Beginning in mid-June, I can do company-private webinars for a fee as well.  Most support is going to be covered on LinkedIn, in the ExperiaSphere group.  I ask that any who are interested in the status of the project join the main group as soon as possible.  I’ve also set up two subgroups for detailed participation.  One is the Implementation Subgroup, which will be limited to those prepared to actually contribute to the project by undertaking some tasks.  Generally these will be related to the open-source components of ExperiaSphere.  The Insiders Subgroup is by invitation only so you’ll know you could be one when you get an invite!

This is an open architecture, contributed freely into the public domain for all to use and share.  You need not refer to your own implementation as “ExperiaSphere” but if you want to use the name and logo you’ll have to offer me a presentation deck on what you’re doing.  ExperiaSphere and “Think Outside the Bit” are Trademarks of CIMI Corporation, and so to use the term and logo you’ll need my license to apply it, which I’ll grant freely if what you do conforms to the architecture.  I want to be sure that anything that is called “ExperiaSphere” really works as I’m describing.

So that’s it for now.  Again, please join the ExperiaSphere LinkedIn group or at least connect with me on LinkedIn if you don’t follow this blog regularly, so you get the latest status.  Thanks again for your interest!

Posted in Uncategorized | Comments Off on More on the Webinar and ExperiaSphere Q&A Process

Next Round of ExperiaSphere Webinars

Our first group of webinars on our ExperiaSphere open-source-driven approach to orchestration and management for the cloud, SDN, and NFV have been fully subscribed so please don’t send us any other applications.  We are scheduling our next round for the week of June 9th, with the current tentative date/time being June 9th at 10 AM Eastern Daylight Time.  The webinar will be scheduled for 90 minutes and content will reflect the feedback we’ve gotten from our first series and additional details on the architecture that have emerged.  This webinar will be open to network operators only.  We will do our first webinar for non-operators in July and it will target members of the NFV ISG, the ONF, and the TMF.  An open webinar will be held in late July or mid-August.  Contact our registration email (hangmeout@cimicorp.com) to register or inquire, or respond to me on LinkedIn (Tom Nolle).

Posted in Uncategorized | Comments Off on Next Round of ExperiaSphere Webinars

Some Structural Insights and a Progress Report

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!

Posted in Uncategorized | Comments Off on Some Structural Insights and a Progress Report

CloudNFV Transitions

Ben Franklin said, in describing the challenges of reaching a consensus on the wording of the Declaration of Independence, that it was hard to get “13 clocks to chime at the same time”.  That notion fits the challenges of managing mult-vendor projects pretty well too.  Most of you know that I started CloudNFV based on the work I did with ExperiaSphere and that I opened my design for use by anyone without restrictions.

I also launched a project with the same name to build an ETSI NFV implementation prototype based on that architecture.  6WIND, Dell, EnterpriseWeb, Overture, and Qosmos all joined in immediately, and Metaswitch, Mellanox, and Schenick all joined later.  These companies have all labored to implement the NFV prototype, and all of them deserve both praise for their efforts and a return on their investment.  That means CloudNFV has to be productized.

When I stepped down from my role as Chief Architect for CloudNFV in January, I told everyone that this was an essential part of the “Project-to-Product” transition, and it was.  I can’t run a commercial activity as an industry analyst.  The problem is that while my departure was a necessary condition in the transition, it’s not a sufficient condition.  There are many vendors in CloudNFV and each has their own optimum opportunity and preferred path to achieving it.  It’s pretty likely that there will be multiple different implementations of all or part of my original architecture that emerge from CloudNFV.  It’s also likely that some vendors will elect to do things very differently than the original design mandated, or even assemble partners other than the original ones.  All of this could muddy the waters hopelessly, to the detriment of all who participated and all who know about the project and concept of CloudNFV.

To try to “un-muddy” things, what’s now going to happen is that the CloudNFV website will be dedicated to the architecture of CloudNFV, to my original design, and to providing a jumping-off point for those who want to see how the various members of the team have developed the concept commercially.  I’ll continue to maintain the website, and CIMI Corporation will continue to hold the Trademark for CloudNFV and the copyright for all the collateral.  However, I’ve already delivered a license to the CloudNFV team to allow them to use the term in connection with their past, current, or future activities on the project and also to use the three collateral pieces that were developed for the launch last summer.  If the team fields a product or wants to have a project website for CloudNFV, I’ll provide a link on the CloudNFV site so you can find it easily.

My own goal is to take the original design of CloudNFV and expand it to embrace management and orchestration for the cloud, SDN, and NFV and also to embrace legacy network elements seamlessly.  I’ve already begun discussions on this with experts in the standards area, and I’m starting operator dialogs at the end of April.  This is going to take me some time, simply because I can’t stop doing billable work to volunteer myself as a resource!  Hopefully I’ll get some support from outside as I develop the concept enough to prove it’s worth supporting.

I will not be posting material on this new approach to the CloudNFV website.  Those companies who committed themselves to the architecture of CloudNFV didn’t commit in any way to my notion of how it should evolve and I have no right to co-opt their work nor to infer their support by posting my new ideas on a site linked to the original concept.  I’ll use the ExperiaSphere website for that purpose, and I’ll also provide every one of the CloudNFV project members a link to their own activities that derived from our joint efforts.

 

Tom Nolle, President CIMI Corporation

Posted in Uncategorized | Comments Off on CloudNFV Transitions

What To Expect from the “New ExperiaSphere”

If you’re reading this you probably read my personal CIMI Corporation blog, and if you do then you know how important I think a single model for orchestration, operationalization, and management of SDN, NFV, the cloud, and legacy infrastructure is to operators.  Whatever we believe about the future of networking, we’re in a present whose sunk costs run in the hundreds of billions of dollars and we’re not going to junk that and start over.  That means the new has to coexist with, as a minority element in fact, the legacy.  Not only that, things like the cloud, SDN, and NFV present different benefits in different applications and places, and so will likely deploy in a specialized way rather than generally.  We have to accommodate that.

When ExperiaSphere launched as a project six years ago, it grew out of TMF Service Delivery Framework discussions and operator interest in prototyping some of the concepts for service automation.  From the first it supported hosted elements, network services created in any way that worked, and even a harmony between web services and provisioned elements.  All of this is included in the new model of ExperiaSphere that I’m now defining and starting to share with selected operators and experts.

This is going to be an architecture effort, not an implementation project like my CloudNFV efforts were.  I want to be able to build a model of operationalization for the future that can be applied by anyone in any way they like, and in particular to support an open source implementation, which is what ExperiaSphere was based on from the first.  I started this quest in January when I left my role as Chief Architect for CloudNFV, and I’m glad to say that I’m almost done with a proto-model, and also that I’ve identified what I think is at least one of several possible paths to implementation that leverage open-source elements for all the key missions.

I can’t rush this because my time spent on projects that are fun but not profitable can’t be infinite!  I also want to get input from standards groups and in particular the carriers, and that process is already starting.  I hope you’ll be patient, and I hope you find the result to be worth the wait.

ExperiaSphere’s motto has always been Think Outside the Bit and that’s what I’m asking everyone to do…because it think the conditions in our industry demonstrate that’s the only way we can reach a future where we’re all happy and successful in this dynamic industry.

Posted in Uncategorized | Comments Off on What To Expect from the “New ExperiaSphere”

A New Direction for ExperiaSphere

There have been a number of commitments by network operators to new technologies like the cloud, SDN, and NFV.  Last week, Metaswitch earned its carrier stripes with a win in Europe, one of the first (of many, I’m sure) non-traditional IMS deployments.  Their stuff has been used in at least one NFV PoC. Verizon and AT&T are both committed to the cloud and operators are deploying SDN too.  But I’m sure you agree that all these deployments are islands—no operator has committed to a complete infrastructure refresh based on next-gen technology.

The benefits operators hope for largely center on “service agility” and “operations efficiency” and yet the “island” nature of these early trials makes it impossible to realize these goals because there just hasn’t been enough of a change in infrastructure to drive agility up or opex down overall.  Truth be told, we didn’t need these revolutions to meet the agility/opex goals, we needed a revolution in management in general, and in particular in that new wonderful thing called “orchestration”.

Many of you have followed my discussions on management and orchestration models, and even engaged in a number of lively dialogs on LinkedIn on one or more of the blogs.  Some have asked whether I’ll be presenting a complete view of my management/orchestration model, something that starts at the top where services start and ends with resources.  People want something that works with the cloud, SDN, NFV and legacy network and IT technology, that does federation among technologies and operators, and that’s compatible with an open-source implementation.

Well, the answer is that I’m going to be publishing a complete orchestration model later this summer.   I’ll be releasing a complete vision based on the two key principles I’ve blogged about—Structured Intelligence and Derived Operations, and it’s based in large part on my ExperiaSphere open-source project, though it expands on the scope considerably.  The presentation will be made available as a YouTube video on my channel and as a PDF on SlideShare.  The material will be free, links can be freely distributed for non-commercial attributed purposes, and all the concepts I’ll illustrate are contributed into the public domain for all to use with no royalties or fees.  I’ll be using the ExperiaSphere website to communicate on this material as it’s released, so check there for news.

I want to stress that I’m not starting a project here; I can’t contribute that kind of time.  What I’m doing is making a complete picture of a suitable orchestration-layer architecture available, in fact making it public-domain.  If standards groups want to use it, great.  If somebody wants to launch an open-source project for it, likewise great.  Vendors can implement it or pieces of it if they like, and if they actually conform to the architecture I’ll give them a logo they can use to brand their implementation with.  None of this will cost anything, other than private webinars or consulting that a company elects to do on the model.

 

That’s a key point.  Some people already want to do a webinar or get a briefing, and as I said I can’t donate that kind of time any longer.  I will make a complete video and slide tutorial (likely two, an hour each) available when I can get it done.  Meantime I want to get the idea exposed where it counts, with the network operators and some key standards bodies.  Therefore I’m going to start by offering service providers who are members of either the TMF or the NFV ISG the opportunity to attend a single mass webinar at no charge.  This will be scheduled in May 2014 at a specific date and time to be announced.  I’m asking that service providers who are interested in signing on contact me by sending an email to experiasphere@cimicorp.com. Say that you’re interested in the “SI/DO Model” and please note your membership in the TMF or NFV ISG, your name, company, and position.  I promise not to use this for any purpose than to contact you for scheduling.  Slots are limited, so I can’t accept more than five people per operator for now, and even that may have to be cut back.  You’ll have to promise not to let others outside your company sit in.

At some point in June I’ll be offering for-fee private webinars to network equipment vendors (and to service providers who want a private presentation), billed as a consulting service and prepaid unless you’re already a CIMI client.  These sessions will be exclusive to the company that engages them but you’ll still have to provide email addresses of the attendees, and you may not invite people outside your company.  If you like you can host these private webinars on a company webinar site rather than mine, but if you record the sessions you must not allow access outside your company without my permission and under no circumstances can the material be used in whole or in part as a part of any commercial or public presentation or activity.  If you’re interested in participating in one of these webinars, contact me at the same email address and I’ll work out a time that’s acceptable to both parties.

At this same point, I’m offering the TMF and NFV ISG and also the ONF the opportunity to host a mass webinar for their members, at no cost.  This will be a shorter high-level introduction designed to open discussion on the application of my proposed model to the bodies’ specific problem sets.

I’m expecting to have the open public video tutorials and slide decks will be available in August, and these will include feedback I’ve gotten from the operators and standards groups.  Anyone who wants to link to the material can do so as long as they 1) don’t imply any endorsement or conformance to the model unless I’ve checked their architecture and agreed to it and 2) they don’t use it in any event or venue where a fee is paid for viewing or attendance.  I want this to be an open approach and so as I’ve said, I’m releasing the architecture into the public domain.  I’m releasing the material with these simple restrictions.

Contact me at the email above if you’re interested, and be sure to let me know whether you’re an operator, a member of the standards/specification groups I’ve noted, or a vendor or consulting firm.  I reserve the right to not admit somebody to a given phase of the presentations/webinars if I’m not sure of where you fit, and if you’re not committed to an open orchestration model don’t bother contacting me because everything in this architecture is going public!

Posted in Uncategorized | Comments Off on A New Direction for ExperiaSphere

ExperiaSphere, the Cloud, and DevOps

One of the questions that’s come up recently in our ExperiaSphere work is how ExperiaSphere relates to the emerging vision of cloud computing and in particular how it might relate to the concept of “DevOps” or Developer/Operations fusion for the cloud.  We did an old presentation on the cloud, and we’re intending to update that now, including a section on how ExperiaSphere concepts might relate to DevOps.

In our view, the most valuable work in DevOps for the cloud is addressing two related issues, if somewhat orthagonally at present.  The first is the provisioning of apps or machine images onto the cloud, and this can be looked at either from the resource perspective (spinning up a server to host apps) or from the app perspective.  The second is the addressing of cloud-hosted apps or components, either by users or by other components in a SOA framework.  The cloud work here is still evolving, and so we can’t be sure that anything useful can be done right now, but we’re examining the space and if it’s possible we’ll do our update.  In the meantime, we invite anyone with perspective on the issue to get in touch!

Posted in Uncategorized | Comments Off on ExperiaSphere, the Cloud, and DevOps