Fortinet black logo

SD-WAN / SD-Branch Architecture for MSSPs

7.2.0

External orchestration

External orchestration

We have seen in Blueprint 2: MSSP premises / public cloud, multitenant with FortiPortal how an external product (in that case, FortiPortal) can be used to access the information from both FortiManager and FortiAnalyzer and expose it to the Customer, rather than letting the Customer access the management products directly.

When designing the Managed Service infrastructure, this idea can be taken further. The SD-WAN Solution can be fully managed using an external Orchestration system. Here we will present only a brief introduction to this topic.

Multiple vendor-agnostic third-party Orchestrators exist on the market, and their description is outside the scope of this document. Typically they are not deployed off-the-shelf, but rather tailored to the designed Managed Service. What is important to mention is that a successful deployment of an external Orchestrator depends heavily on the following items:

  1. An ability to interact with the management plane using industry-standard API.
    Both FortiManager and FortiAnalyzer satisfy this requirement in full: nearly any action that can be done interactively can also be done through an API call.

  2. An ability to abstract vendor-specific implementation details away from an external Orchestrator.

    This allows to simplify and generalize the "conversations" between the management plane and the external Orchestrator, which greatly reduces the time needed to tailor the solution, to maintain it, and to extend it in the future.

    The methods described in the SD-WAN Deployment for MSSPs Guide that complements this document proved to be very efficient in this regard.

The following blueprint illustrates the integration with external Orchestration systems:

Here we depict not one, but two external layers. Let's briefly describe their roles:

  • Services Layer provides a Customer Portal for the entire Managed Service. Customer operators, as well as MSSP's own operators, will interact with the service using this portal. It can be developed in-house by the MSSP, or a customized third-party product can be used.

    This layer can perform a wide variety of business tasks and interacts with different systems, such as Procurement, Billing, Logistics, and so on. For simplicity, the above diagram depicts only a single interaction vector relevant for our discussion: passing operator commands down to the Orchestration Layer. These commands will be very high-level and in line with the Managed Service definition. For example: "Add Site", "Enable RIA", "Get Site Health", and so on.

  • Orchestration Layer interacts directly with the management plane of our SD-WAN Solution using JSON API. It translates high-level commands received from the Service Layer into a series of API calls sent to FortiManager and FortiAnalyzer.

    For example, an "Add Site" command could be translated into a series of API calls such as: "Create Model Device", "Set Variables", "Generate Certificate", "Install Policy", and so on.

    A collection of Ansible playbooks or Python automation scripts written in-house by an MSSP is a good example of the Orchestration Layer. But also here, comprehensive vendor-agnostic third-party products exist on the market.

Note

In this blueprint, external systems are not required to maintain your site inventory. Neither are they required to communicate to the Edge devices deployed on the Customer premises, facilitate Zero-Touch Provisioning, and so on. All these duties remain the responsibility of FortiManager and FortiAnalyzer.

External orchestration

We have seen in Blueprint 2: MSSP premises / public cloud, multitenant with FortiPortal how an external product (in that case, FortiPortal) can be used to access the information from both FortiManager and FortiAnalyzer and expose it to the Customer, rather than letting the Customer access the management products directly.

When designing the Managed Service infrastructure, this idea can be taken further. The SD-WAN Solution can be fully managed using an external Orchestration system. Here we will present only a brief introduction to this topic.

Multiple vendor-agnostic third-party Orchestrators exist on the market, and their description is outside the scope of this document. Typically they are not deployed off-the-shelf, but rather tailored to the designed Managed Service. What is important to mention is that a successful deployment of an external Orchestrator depends heavily on the following items:

  1. An ability to interact with the management plane using industry-standard API.
    Both FortiManager and FortiAnalyzer satisfy this requirement in full: nearly any action that can be done interactively can also be done through an API call.

  2. An ability to abstract vendor-specific implementation details away from an external Orchestrator.

    This allows to simplify and generalize the "conversations" between the management plane and the external Orchestrator, which greatly reduces the time needed to tailor the solution, to maintain it, and to extend it in the future.

    The methods described in the SD-WAN Deployment for MSSPs Guide that complements this document proved to be very efficient in this regard.

The following blueprint illustrates the integration with external Orchestration systems:

Here we depict not one, but two external layers. Let's briefly describe their roles:

  • Services Layer provides a Customer Portal for the entire Managed Service. Customer operators, as well as MSSP's own operators, will interact with the service using this portal. It can be developed in-house by the MSSP, or a customized third-party product can be used.

    This layer can perform a wide variety of business tasks and interacts with different systems, such as Procurement, Billing, Logistics, and so on. For simplicity, the above diagram depicts only a single interaction vector relevant for our discussion: passing operator commands down to the Orchestration Layer. These commands will be very high-level and in line with the Managed Service definition. For example: "Add Site", "Enable RIA", "Get Site Health", and so on.

  • Orchestration Layer interacts directly with the management plane of our SD-WAN Solution using JSON API. It translates high-level commands received from the Service Layer into a series of API calls sent to FortiManager and FortiAnalyzer.

    For example, an "Add Site" command could be translated into a series of API calls such as: "Create Model Device", "Set Variables", "Generate Certificate", "Install Policy", and so on.

    A collection of Ansible playbooks or Python automation scripts written in-house by an MSSP is a good example of the Orchestration Layer. But also here, comprehensive vendor-agnostic third-party products exist on the market.

Note

In this blueprint, external systems are not required to maintain your site inventory. Neither are they required to communicate to the Edge devices deployed on the Customer premises, facilitate Zero-Touch Provisioning, and so on. All these duties remain the responsibility of FortiManager and FortiAnalyzer.