DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Utilizing Declarative, Model-Driven TOSCA Orchestration for NFV

A model-driven approach using TOSCA can simplify your orchestration process for new services, all while keeping independent from your cloud provider's capabilities.

Arthur Berezin user avatar by
Arthur Berezin
·
Mar. 29, 17 · Tutorial
Like (3)
Save
Tweet
Share
3.61K Views

Join the DZone community and get the full member experience.

Join For Free

TOSCA service template

Declarative, model-driven is an elegant and streamlined approach to solving the needs of NFV orchestration. Utilizing TOSCA as a declarative language to model network services and functions for the needs of NFV makes perfect sense, but we need to ensure old habits don’t creep in and cripple the whole NFV solution.

Hard-coding and scripting the manual step-by-step procedures of an onboarding process is NOT orchestration but can be used as part of it. I’ve had to repeat this concept too many times recently. In this article, I will take a high-level look at why model-driven orchestration is a fundamentally more robust method than business process workflows by comparing their approaches to NFV orchestration and offering an approach to leverage existing BPMN workflows with TOSCA declarative orchestration. 

Why Telcos Need NFV Orchestration

Until very recently, communication service providers (CSPs) went through a manual and drawn-out process for onboarding services that could take up to 18 months to make a new service available to the end user. The manual onboarding process includes instantiating the service alongside all of the dependent components it requires and then integrating the service with the other existing services in the CSP network.

This long and cumbersome process is a major challenge for CSPs to overcome. Network Functions Virtualization (NFV) proposes a more modern approach for offering services. NFV allows communication service providers much greater flexibility by following a software-based approach using off-the-shelf hardware. When onboarding new services the whole process is fully automated with the help of an orchestrator. The main advantages of NFV over the traditional approach are much greater flexibility and speed of service delivery, as the solution is software defined and much quicker to instantiate as a result of automation. Operators are looking to deploy new services quickly and require a much more flexible and adaptable network — one that can be rapidly and easily provisioned and activated.

To achieve this pinnacle and reach a high degree of flexibility the operator needs to be able to automate the entire end-to-end process, including instantiation of virtual resources, configuration of networking devices, instantiation and configuration of software components, as well as have the ability to coordinate them with existing running processes. This mostly results in running a large set of coordinated tasks that instantiate the new service and chain it with existing operational services.

It is the role of the orchestrator to coordinate dependent and independent components when onboarding a new service. After the service is onboarded — a day zero operation — it is the orchestrator’s role to instantiate — day one operation — and then manage the day two operations of that service. Day two operations commonly include scaling the different tiers of the service, maintenance of the service, service upgrade, and others.

Declarative Model-Driven Orchestration

Model-Driven Orchestration helps to onboard services, instantiate them, and then run and manage day 2 operations, with a simple, and very powerful approach. It allows creating the model of a service using a declarative, human readable language — TOSCA.

The service model describes the service’s components, relationships between components of the service, dependencies, requirements, and capabilities of each component in the template. The model declares reusable types and uses them to construct the structure of the application. Types can represent Nodes and Relationships helping to define connections between nodes of the model.

After we have the Nodes defining the model, node types and relationship types can define their lifecycle interfaces and trigger their implementation. The service template, in fact, represents the graph of the application. Once we have the application graph, typical application workflows are based on the service graph.

Common workflows, such as Install/Uninstall, traverse through the service graph and initiate lifecycle operations of each node of the graph and interact with the state of the service state. Other operational workflows such as Scale, Heal, Upgrade, Maintenance and others query the graph described by the template, query the service state, then execute a specific set of operations based on the graph and the context in which the workflow is executed. Interaction with the graph can read information and modify the service state.

The service state enables interacting with the service graph and discovery of relationships and state of components and services. Additionally, the service state allows passing contextual properties between components, allowing transactionality and idempotency of operations.

For example, when executing the Install workflow on a service template, an OpenStack Instance is provisioned, the service state keeps information about the instance, including its credentials and connection details. When the next node of the graph is executed, it can pull contextual information from the service state to perform the next needed operation, for example, connect to the VM instance and install software.

This is in contrast to standalone workflows, such a with BPMN, which are standalone, one-off, implementations of specific task-oriented cases. Once execution of a BPMN workflow is completed, the contextual information is lost and the workflow engine has no information on the application graph, let alone introducing changes to the application graph.  Thus, performing operations on BPML instantiated services require developing new custom workflows that match only the latest state of the service.

Business Process Workflows

Business process workflows are an imperative, scripted organization of tasks performed in a specific order for implementing a use-case. A workflow allows defining a repeatable, step-by-step procedure which can represent business cases such as purchase orders, shipment fulfillment, or a process for onboarding a new service. Workflows can define repetitions of tasks and include if statements for conditional execution.

As such, each workflow is a tailor-made implementation of a certain flow or use-case. This approach may be suitable for immutable business processes which are static and predefined by nature, but they introduce difficulties and unnecessary risk in software defined environments where changes are wanted and can occur frequently.

What happens when a change, such as replacing a component, is required in the process? What happens when there’s a need to implement a different use-case using similar components? All these would be cumbersome to implement and would require re-implementing the entire use-case while posing fundamental challenges in integration with existing, additional running components.

The Object Modeling vs. Printer Instruction-Sets Analogy

Other domains employ a very similar approach. TOSCA allows defining the service model which describes “WHAT” it is we want to achieve, instead of scripting an immutable “HOW-TO” workflow. In the manufacturing domain, CAD models are used to design physical objects. Imagine what would it take for hardware engineers to write direct instruction-sets for the CNC manufacturing machines or script an instruction-set to a printer to print this article, instead of using a word processor for writing text, and letting the printer driver translate the text (model) into printer instruction-sets (TOSCA nodes and relationships types lifecycle implementations), telling it to make the physical movements and spread ink on a piece of paper.

Utilizing BPMN With TOSCA

TOSCA allows defining the service graph and then executes a set of operations on the declarative, model-based graph. Operations of each node rely on external implementation. This mechanism allows choosing the implementation of each node type, which can be a BPMN workflow, allowing model-driven orchestration while utilizing existing BPMN artifacts.

Conclusion

The model-driven approach allows a much more simplified implementation for constructing and orchestrating new services. It allows users to focus on the services themselves instead of focusing on tasks needed to be performed. It makes it easier to modify and interact with existing services, since we have the service graph and contextual state of each node in the graph, thus eliminating the need to reprogram every single use case and rather just interact with the service directly.

Workflow engine Graph (Unix) Use case application Business process

Published at DZone with permission of Arthur Berezin, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Better Performance and Security by Monitoring Logs, Metrics, and More
  • Top Five Tools for AI-based Test Automation
  • How to Quickly Build an Audio Editor With UI
  • DevOps Roadmap for 2022

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: