Guest Post by Tom Nolle
Automating a network services lifecycle involves fielding thousands or tens of thousands of events, managing thousands of traditional network devices, and deploying and sustaining thousands of virtualized network functions (VNFs). VNF “onboarding” alone has presented problems literally dazzling in their complexity. Most of the NFV implementations have taken the ETSI end-to-end model literally, and that’s created a second problem of performance and scalability.
EnterpriseWeb is solving both those problems at once. The company built and patented a platform for object-based software that structures itself dynamically to fit the problem set, the load of activity, and the state of infrastructure. A specially-developed programming language, GOAL, is used to author object-based systems for each application domain, and NFV is one such domain. This is a sophisticated, architectural, solution to the complex NFV problem, so I’m going to take it one step at a time.
Let’s start with a high-level view of EnterpriseWeb’s approach, referencing the figure. A deployed service is a web of elements linked by connections, and that’s illustrated by the blue model in the figure. EnterpriseWeb defines that real service with a model (the rust-colored model in the figure), where each element in the service is represented by an object. These combine with all the relationships between elements to form a graph of objects. Graphs themselves aren’t new; standards like OASIS TOSCA are examples of the idea. What makes EnterpriseWeb’s approach different is that graphs are executed directly. The execution applies policies and resolves relationships in a totally integrated way.
Distributed state is maintained in the graph, where the state of each object is determined by the state of its related objects. Lifecycle management is accomplished by executing the graph, which causes processes to run to deploy or repair a service as needed. This approach formed the basis of the first approved ETSI NFV ISG PoC, and the foundation of several award-winning TMF Catalyst demonstrations.
Most service modeling approaches apply structure at the model level, creating rigid artifacts to represent services and service pieces. EnterpriseWeb builds its graphs based on the actual relationships of service elements, and thus the graphs always represent service reality rather than constrain it. The graph approach also avoids a host of tools designed simply to manipulate the service graph structures themselves, before you even get to the point of deploying or managing a service. The Platform knows, and works with, the real world directly. Since the real world can evolve, so an object definition and the related graphs can evolve to reflect new relationships and features. Models never constrain you.
The figure illustrates how the Platform as a framework (the right side) is used with models at multiple levels (the left side of the figure) to make ETSI NFV a full-service lifecycle reality. The Platform is an object-based system designed to represent the real world with objects that, when manipulated, coordinate that manipulation into the real-world elements they represent. It’s effectively a new model of object-based middleware, a model that’s lightweight and event-driven, and horizontally architected to manage the elements of even complex and highly distributed software systems.
The Platform and its object framework are based on established Web concepts like REST, JavaScript, and XML and deployed as a Java-based system for portability. They have a very small footprint, so they can be run with low overhead on bare metal, virtualized, and cloud resources, and the connection between objects is supported using high-performance, low-overhead tools. All this combines to make it an ideal platform for coordinating multiple software elements in an event-driven, interdependent application.
Applications are built by creating a domain model that defines the elements of the application and how they are related to one another, as the layered structure on the right of the figure illustrates. To implement NFV, EnterpriseWeb used the Platform’s “native language”, GOAL, to define how NFV is supposed to work, laying out the elements of the ETSI E2E model and in particular defining the relationship between VNFs and the rest of the ETSI structure. This NFV domain model is then used to define and deploy services.
The service lifecycle starts by onboarding all of the real-world NFV elements, hardware or software. This creates an abstraction “object” representing each piece of NFV, and defines bound relationships like the one between a VNF and the associated “local” VNF Manager component. Besides VNFs, EnterpriseWeb supports onboarding deployment tools like OpenStack, APIs to NMSs to control legacy network elements, and even other partial or complete implementations of NFV. During onboarding, the data models and interfaces of each element are specified, defining each relationship or dependency between elements through a platform-assisted mapping that replaces complex manual integration tasks. These are mapped to the NFV metamodel based on algorithmic suggestions, subject to manual adjustment as needed, and completed models are then stored in a catalog. It’s that catalog that forms the basis for managing the full service lifecycle.
The onboarding of VNFs and their related VNFMs is especially important because most VNFs were created to run within a proprietary environment, and there’s no standardization of management features, information bases, interfaces, configuration parameters, etc. Because EnterpriseWeb harmonizes all these things to the NFV metamodel, all VNF/NFVMs appear the same from the outside, so differences in VNFs never propagate into lifecycle management. This applies intent modeling to policy management, enabling policy management even over very diverse elements.
Services are created by pulling elements from the catalog and placing them in a contract template whose initial structure is determined by the NFV domain model. This greatly reduces the effort because the core platform “understands” the core concepts of services, and their implementation. This model is shown in green in the figure. The contract template is also a graph, and it describes the dynamic relationships between VNFs or fixed network features that are needed to create the service behavior. For each element (VNF, management API, resource, etc.) in the service model, a corresponding object is picked from the catalog and added to the graph. All the dependent elements, and even their graphs, are added to the service model template automatically. When the template is complete, it describes both the structure of the NFV software and the structure of the service; a complete NFV implementation. Services can be authored directly through the NFV domain model’s GUI, or imported from virtually any of the modeling languages used for networking and the cloud—including YANG, TOSCA, or XML. Completed service model templates are stored in the catalog for use.
You can also onboard “composites” like a service chain or even a complete service definition from a third party. You could also onboard as much as a complete NFV implementation, such as ECOMP. In these cases, the composite has to have an interface through which it can be deployed and managed, and what happens inside the composite is known only by what’s available at that interface. However, you could build the same composite in the Platform as a kind of “sub-service”, in which case the graph for the composite would be merged with the graph for the service overall when the service referenced the composite as an object. Harmonization of the data models and interfaces is still available with composite elements.
Now to the next step, which is ordering. Service orders are placed against a specific contract template. When that happens, the contract template is updated with any order-specific parameters and a service instance graph is created (the blue model in the figure). This graph parallels the service elements through the entire service lifecycle. Once the graph is instantiated, it is executed by the Platform run-time, and since the objects in the graph are all in the “ready-to-deploy” state, that results in the deployment and interconnection of each object, as it is defined in its own model and described in its onboarding. That creates the rust-colored model, the real resource commitments.
All of this is sophisticated, flexible, and above all agile. You’ll remember that each service element has a corresponding model, and models are connected by the service- or object-defined relationships into a graph. When a service graph is executed, the management interfaces, parameterization, and other implementation-specific features of the element each object represents are harmonized into the NFV data model, which resolves any differences by converging everything on a common standard. A service is built, automatically, from catalog elements and a service template.
Everything else follows the same pattern. A lifecycle event, such as the failure of a service element, causes the graph to be executed, and the Platform seeks the goal of correct operation by undertaking repair, replacement, or reconfiguration as needed. The specific steps to achieve that goal are defined at the element level by the objects that represent the service elements themselves, and at the service level, in the service model template.
Let’s now go back to the high-level vision and cover implementation efficiency. In EnterpriseWeb’s approach, service lifecycle processes aren’t part of a monolithic single-thread structure. The service graphs represent a fully distributed implementation of service lifecycle processes, scaling with every new service that’s deployed. They can’t overload as services change or lifecycle events are generated. The service graph is executed and the appropriate processes run when any external event or internally recognized condition occurs. The graph and model provide distributed state, mediation of interfaces and data models, and pathways for context exchanges that ensure all the pieces track correctly, resolving dependencies and cooperating to do what an event dictates.
Next, it’s auditability. In the real world, deployments and lifecycle management has to be auditable, which is always difficult in a distributed system. Not here. Each object in the Platform has inherent version control, journaling, security and governance, and these capabilities are automatically part of each NFV deployment. Because control and management interactions are mediated by the Platform objects representing the real hardware and software, everything done to the modeled elements of NFV or to NFV services is done through the models and graphs, and fully journaled, secured, and mediated. You can see everything that has happened, how and why it happened, because it’s all journaled, and that makes service auditing and diagnostics much easier. There can be no finger-pointing, even in a diverse environment like NFV.
That sums up the EnterpriseWeb approach to NFV, and it also shows at a very high level the sophistication of the underlying object architecture. This is a very flexible solution, not only to the problems of NFV but also to other problems of distributed event processing and software management. The whole of the tech industry is getting more complicated because the relationship between us all and our technology is getting closer. Everything has to be optimized to tighter constraints, managed with less human intervention to control cost and increase agility. EnterpriseWeb seems to be on the right path with NFV, and with many other applications besides. It’s going to be fun to watch how they evolve.
Copyright 2017, CIMI Corp. and EnterpriseWeb LLC
About Tom Nolle
Tom Nolle is a veteran analyst in the networking, cloud, SDN, and NFV space. He is the president of CIMI corporation and its principle analyst. With a background in software development and architecture, a deep understanding of the Information and Communications Technology, and an inimitable writing style Tom has been a clear-headed voice in IT and Telecommunications circles for over 30 years. Tom has been writing regularly for the technology press since 1982, including: ComputerWorld, Information Week, CIO Magazine and Network World. He is a regular contributor to TechTarget publications and has his own popular blog is followed by CxOs, Architects and Engineers around the world. Tom is also a frequently invited speaker at industry tradeshows and at events hosted by leading International standards bodies. He’s currently a member of the ETSI NFV ISG.
About EnterpriseWeb
EnterpriseWeb® (www.enterpriseweb.com) is a New York based software company, which offers an intelligent operations platform, which radically simplifies the design, deployment and management of Cloud-native applications and distributed processes.
While Globalization, Outsourcing, Cloud-computing and the Internet-of-Things have led to the increasing fragmentation of modern organizations, EnterpriseWeb has made it easy for customers to work across business silos, IT layers and partner ecosystems for highly-integrated operations.
With EnterpriseWeb, organizations can quickly onboard diverse functions, services, systems, databases and devices into a graph-connected model of software objects – an enterprise “web” of information and capabilities.
The Platform allows customers to flexibly compose the objects with low or no-code; application logic is defined by policies and metadata. The approach supports rapid prototyping of intelligent, event-driven services, applications and processes that can be managed from a unified command center.
Customers and partners around the world use EnterpriseWeb to develop differentiated and transformative solutions. EnterpriseWeb supports Cloud, On-premise and Hybrid/Multi-Cloud deployments. In addition, EnterpriseWeb also offers vertical solutions including: “CloudNFV” for the Networking/Telecom domain and “Ideate” for R&D management and compliance.
