Highlights of Deploying Fortinet VNFs with Cloudify Webinar

We recently completed our joint webinar with Fortinet on how how they are using Cloudify model driven orchestration to deploy and manage the lifecycle of their VNFs, including virtual firewalls like FortiGate.

Register and Watch Deploying VNFs at Scale with Cloudify Webinar on demand!

The webinar featured some of the opportunities and challenges that NFV represents for virtual editions of FortiGate, and how the concept of orchestration can help solve some of these challenges and help automate the existing processes, making them faster to deploy, giving the ability to easily deploy on different environments, and making the whole process less error prone.
Also featured was a live demo showcasing the Cloudify-Fortinet VNF solution, which in essence can be used as a example for VNF on-boarding for VNFs from any vendor. This VNF on-boarding  process puts the power back in the hands of the vendor, and allows them to have their VNF deployed easily, and to any cloud.
Fortinet NFV pioneer Nicolas Thomas, and Cloudify’s networking architecture wizard Sebastian Grabski, then took live Q & A and answered questions from the audience, some of which included:

• I assume that you decompose the service first and decompose the resources/nodes
  • This is the efficient way to do it indeed. The blueprint represent your services/intents and is in charge of finding, connecting etc.. instances on nodes. You can also have autoscaling this way.
• During instantiating a VNF, can I put dependency on another VNF ? e.g. my VNF requires any service from another VNF?
  • Yes, this is one of the powerful abilities of TOSCA orchestration, the ability to create service function chaining, and be able to create dependancies based on different VNFs, and create a whole working NFV service.
• (Continuing the previous question) What happens if the deployment is not available – is the instantiating aborted only or is it retried automatically?
  • This is a more advanced topic, but you would need to configure the operations and workflows in the service modeling itself, i.e. give it a re-try maximum number of times or a similar policy.
• For the application level provisioning (the second service you showed) are you converting a TOSCA model into a device specific readable configuration syntax (i.e. YNAG, JSON, XML, CLI, etc)? I am assuming the FortiGate has a configuration API like NTECONF, REST or SOAP and it cannot read a TOSCA model directly. In other words you are not talking to OpenStack, but talking to the device directly via an API.
  • FortiGate has a REST API allowing every function to be configured. You got right the difference between TOSCA and the application, as TOSCA is abstracting application modeling, or service modeling.
• How do you scale out the VNF or add more instance?
  • Yes its possible to execute the built in scale workflow, and scale the VNF.
• (Continuing the previous question) thanks, is it automated?
  • Yes, it is possible to create policy within the TOSCA blueprint to have auto-scale, auto-heal and other automated workflows instantiated on the VNF, or other deployment that is part of the service.
• Is there a heat template for us to try on our own OpenStack setup?
  • While it is possible to use a HEAT template in Cloudify (via the HEAT-TOSCA translator), we highly recommend modeling the service or application in TOSCA DSL in order to make the most of TOSCA capabilities, and make the service agnostic to where it is being run (i.e run it on any cloud, not just OpenStack). We also recommend registering for the Cloudify NFV lab and getting easy one click access to an OpenStack environment, with Cloudify Manager already installed.

Meet us and see a live demo at Mobile World Congress 2018

You can watch the recorded version of the webinar, by registering at on our Deploying Fortinet VNFs with Cloudify Webinar page. You can learn more about NFV Orchestration, or download the Production Grade NFV deployments whitepaper.