Juju for Telcos and Service Providers Pt. 2

In the first blog of this series I introduced Juju and how it maps to the ETSI NFV architecture at the highest level. Now I’ll dig deeper into this relationship to see how it can be leveraged by telcos and service providers. So lets dive in…

Juju is a neutral VNF modelling system

Juju has adopted a domain neutral model and does not encode policy. It can therefore be described as a generic VNF Manager (VNFM) and not a VNF Orchestrator. In fact, Juju is useful across many domains and is being adopted in big data, cloud infrastructure, PAAS and other scale-out scenarios. This is very useful as it ensures that common elements such as databases, messaging systems, key value stores, logging infrastructure and other ‘glue’ functions are charmed and available for automatic integration, reducing the burden on vendors and integrators. For this reason, Juju should not be classified as a NFV Orchestrator (NFVO), but rather working with MANO vendors to enable them to use Juju as a neutral VNF modelling system.

A NFVO is a domain-specific tool that should understand:

• The range of VIMs and their capabilities at the operator (for example, it might be aware of development, test, and production VIMs in a range of locations).
• Policies at the operator, such as fail-over strategies between VIMs as well as operational practices such as backup, data retention and disaster-recovery.
• Contractual commitments such as SLAs and other commercially-oriented logic, topological constraints such as the physical endpoints of customer connectivity, together with strategies to meet and prioritise commitments at times of load or stress.

A NFVO may be open source or obtained from a long-established telecoms network equipment provider. The same VNFs, represented by the same charms, could be orchestrated by entirely different NFVO’s from entirely different vendors, greatly reducing the complexity to VNF vendors of supporting a wide range of NFVOs at their customer sites.

Apart from using Juju to implement VNFM functions it can also to work with bare-metal using Metal as a Service (MAAS). There are likely to be cases where VNFs will perform best on bare metal. Juju can provide VNFM services across both OpenStack and MAAS.

MAAS and Ubuntu OpenStack are also well aligned with NFV Architecture. Please refer to diagram depicting mapping to NFV architecture below:

Juju provides an overall multi-cloud and multi-datacenter infrastructure to model, deploy, and manage IT and Telco assets including VNFC, VNF services, VNFM and VNFO functions.

Ubuntu OpenStack is fully aligned with VIM and provides standard Neutron based plug-in mechanisms for vendor specific SDN implementations.

MAAS can be utilized for image based DC and virtual infrastructure management tasks.

Juju leverages the capabilities of VIM’s by implementing their northbound API in a driver, called a “provider”. At present through its collection of supported providers, Juju can talk to AWS, Azure, Google Compute, Joyent and OpenStack.

Charms

Services in Juju are defined by Charms, which are similar to packages in that they are self-contained, self-describing encapsulations of operational code (that handles configuration and service lifecycle) as well as the software itself.

In the ETSI model, a service definition corresponds to a Juju charm. Charms exist for hundreds of pieces of open source and proprietary software in use today on public and private clouds. Charms can include all the resources needed for the full lifecycle of the service.

Charms are uploaded to Juju and stored there to be delivered to new resources at the discretion of the NFVO. This collection of charms and bundles corresponds to the ETSI Network Scenario catalogue and the process of uploading charms corresponds to the NS onboarding process described in the reference architecture.

A global catalogue of charms is available, including charms of free and open source software that is useful for integration purposes. VNF vendors and network operators are free to create their own catalogues and import into them appropriate charms from the global catalogue. Operators can audit and constrain the use of charms to those which are approved for particular environments, ensuring both access to a deep pool of open source charms but also retaining control of the Network Scenario on-boarding process.

Juju supports the decomposition of a service (VNF in this case) into smaller functional blocks for reusability and faster response time, but can also bundle them together into more complex or specifically tailored services. The key components identified under the NFV Management functional block in the NFV reference architecture are already build in.

Juju models and manages the deployment of the services defined by charms that contain the operational code for all the possible functions that one might implement. Charms are location and hardware agnostic and can be executed as many times as needed. They also define and expose communication interfaces that are used at later stages for creating relations among the services deployed.

Juju manages the service lifecycle with hooks implemented inside charms, in any language. At present there are 5 “unit-hooks” with predefined names that can be implemented by any charm:

• install
• config-changed
• start
• upgrade-charm
• stop

In practice, hooks are scripts (written in the language of your choice) called during the lifecycle of a service. They are triggered either by the commands you run (like ‘deploy’) or events (like a relation to another service being added). Charm hooks represent the focal points where one defines what the charm actually needs to do.

For every interface declared by a charm, additional 4 “relation hooks” can be implemented, named after the interface:

• [name]-relation-joined
• [name]-relation-changed
• [name]-relation-departed
• [name]-relation-broken

For example, if a charm declares that it supports an interface “loadbalancer” then it could provide code to handle cases where a loadbalancer is connected to it, or disconnected, or the configuration or settings of that loadbalancer are changed.

Typically, commands are given at the service level and Juju coordinates the delivery of the needed events to each unit in the service. So, for a scaled out service, the VNFO only needs to model the behaviour at a high level, and Juju will handle the details of unit-level coordination.

Bundles

Groups of related services with associated configurations can be described as a “bundle”, stored separately, and shared by email or any other exchange mechanism.

envExport: 
  services: 
    mellanox: 
      charm: "cs:trusty/mellanox-2"
      num_units: 0
      annotations: 
        "gui-x": "400"
        "gui-y": "200"
    mariadb: 
      charm: "cs:trusty/mariadb-2"
      num_units: 1
      annotations: 
        "gui-x": "0"
        "gui-y": "400"
    haproxy: 
      charm: "cs:trusty/haproxy-3"
      num_units: 1
      annotations: 
        "gui-x": "-400"
        "gui-y": "0"
    "zend-server": 
      charm: "cs:trusty/zend-server-1"
      num_units: 1
      annotations: 
        "gui-x": "0"
        "gui-y": "0"
  relations: 
    - - "haproxy:reverseproxy"
      - "zend-server:website"
    - - "zend-server:database"
      - "mariadb:db-admin"
    - - "mellanox:juju-info"
      - "zend-server:juju-info"
    - - "mellanox:juju-info"
      - "mariadb:juju-info"
  series: precise

Juju: example of a LAMP bundle

These bundles can be instantiated on any Juju system, in any environment on any VIM, making them a reusable and useful form of Network Scenario definition. Bundles are described in plain text, and a visual editor for those bundles is available, enabling very easy collaboration between operational teams and very easy reuse of standardised Network Scenarios.

Juju GUI : example of exporting a bundleThe instantiation of a Network Scenario (“NS Instantiation” in the ETSI language) from a charm or bundle of charms is called “deploying” in Juju, and creates a Juju service provided by one or more units. Network scenario scaling (“NS Scaling”) is done by adding or removing units of the service and placing them on machines (“resources”).

The model maintained by Juju is live and dynamic, it is not solely a deployment-time construct. The environment or Network Scenario is expected to evolve over time, with changes in configuration, relations, scale, and the addition or removal of services both for network functions and for associated FCAPS such as monitoring. Juju maintains the model of all services throughout, and a clear picture of the configuration and status of every element at all times. This evolution of the Juju model, including updates to versions of the charms defining the VNFs themselves, corresponds to the ETSI “Update NS” capability.

Summary

I’ve described how Juju should be classified as a neutral VNF modelling system rather than NFVO. This has numerous benefits when modelling, deploying, and managing IT and Telco assets including VNFC, VNF services, VNFM and VNFO functions. Charms and Bundles are used to deploy services via Juju and are an extremely flexible and useful form of Network Scenario definition.