Stratoss is a new cloud native product, designed to deliver web-scale levels of operational automation for the cloud-based networking world across highly distributed environments – both to telco and enterprise service providers.
A new OSS “in the control plane”, Stratoss accelerates the design, creation and continuous optimization of enterprise and communications services. It delivers “lights out” operational automation across hybrid and distributed cloud environments, lowering the cost of managing edge cloud fabrics for Enterprise and 5G, and increasing the pace of innovation.
Built from scratch as a fully cloud native product, Stratoss offers comprehensive end-to-end Service Orchestration, productized service modelling and design-to-operation DevOps CICD features, to create a unique product solution.
Some of the features of Stratoss are briefly outlined below.
One of the key reasons that NFV has struggled to progress, is that product companies working to solve the problem of managing the complexity of virtual networking across distributed data centres have tried to hammer an old world solution into a new world. OSS vendors bending offerings designed for traditional network appliances, or cloud orchestration vendors bending IT public cloud offerings to manage virtual networks across distributed edge clouds are not fit for purpose and hinder the business case required to accelerate adoption.
Vendors and standards bodies have tried to make the implementation of NFV a staged process, starting with the day 1 scenarios of VNF on-boarding, with little consideration for the stage 2 scenario of on-going VNF or more importantly the continuous deployment and ongoing operations of complex Network Services.
From the very start, Accanto has developed a product in Stratoss designed to deliver webscale levels of automation for virtual networking across highly distributed cloud environments. Building a new opinionated approach and set of technologies from the ground up designed to automate the management of distributed edge cloud environments, and accelerating the design, creation and continuous optimization of enterprise and communications services, delivers “lights out” operational automation across hybrid and distributed cloud environments.
Most solutions providers will only solve part of the problem. Accanto’s Stratoss considers the Day 1 and Day 2 scenarios to complete the process of continuous integration/continuous deployment (CI/CD).
Network functions virtualization (NFV) is the concept of replacing dedicated network appliances — such as routers and firewalls — with software running on commercial off-the-shelf (COTS) servers. The aim of NFV is to transform the way communication service providers (CSPs) architect networks and deliver network services. Network operations are transformed as network function software is dynamically instantiated in various locations in the network as needed, without requiring the installation of new equipment.
NFV technology separates networking tasks like network address translation (NAT), firewalling, intrusion detection, load balancing, domain name service (DNS), WAN optimization and caching from the hardware they run on. Without NFV, organizations typically deploy multiple specialized appliances in order to meet their needs for these various services. But with NFV, organizations can use standardized, commodity hardware running software in a virtual machine (VM) to serve these various functions. It is different from but complementary to software-defined networking (SDN), and the two technologies are often deployed in tandem.
The earliest proponents of NFV were service providers, who were attracted by the technology’s promised cost savings and greater agility. They helped create some early NFV standards under the auspices of the European Telecommunications Standards Institute (ETSI). Now, enterprises are also becoming more interested in deploying NFV technology for a variety of reasons.
Replacing dedicated appliances with shared servers dramatically reduces hardware costs. Operational costs also decrease with fewer appliances to deploy and maintain and the ability to offer on-demand pay-as-you-go deployment models. But the key advantage is the increase in the speed of bringing revenue-generating services to market. NFV brings unprecedented agility and flexibility and enables innovation nu turning the network edge into a factory for virtual network functions (VNFs.)
NFV virtualization of network services via software will enable network operators to:
- Reduce the cost of building networks (CapEx) by supporting pay-as-you-grow model to eliminate wasteful overprovisioning
- Reduce the cost of operations (OpEx) by reducing equipment requirements and management of network services
- Deliver agility and flexibility by quick scaling up or down services to address changing demands
- Accelerate time-to-market by allowing easy trial and evolve services to determine best meet practices
NFV MANO (network functions virtualization management and orchestration), also called MANO, is an architectural framework for managing and orchestrating virtualized network functions (VNFs) and other software components, defined by The European Telecommunications Standards Institute (ETSI).
The MANO architecture is designed to enable the deployment and connection of services as they are dissagregated from dedicated physical devices and moved to virtual machines (VMs). It achieves this by managing and orchestrating resources that include compute, storage, networking and virtual network functions like routing, firewalls and load balancing.
MANO works with templates for standard virtual network functions so users can pick from existing network functions virtualization infrastructure (NFVi) resources to deploy their NFV platform. NFV MANO must be integrated with application program interfaces (APIs) in existing systems in order to work with multivendor technologies across multiple network domains. Telecommunications providers’ operations and billing systems (OSS/BSS) also need to interoperate with MANO.
NFV MANO consists of three principal functional areas
- NFV or NSO orchestrators consist of two layers — service orchestration and resource orchestration — which control the integration of new network services and VNFs into a virtual framework. NFV orchestrators also validate and authorize NFV infrastructure (NFVI) resource requests.
- VNF managers (VNFM) oversee the lifecycle of VNF instances. These include generic VNFM platforms that are deployed in a multi-vendor environment which can consist of VIMs with/without their own VNFM
- Virtualised Infrastructure Managers (VIM) control and manage NFV infrastructure, which encompasses compute, storage, network resources.
Effective Service Modelling and Design is fundamental to maximizing automation, and reducing unnecessary human errors and associated degraded time to launch/maintain network services.
The traditional approach to service modelling and design is centred around manual process/workflow. With this approach, significant numbers of expert network design and operations staff are employed to code scripts which are then maintained manually. This approach has a number of drawbacks
- High-level of manual effort with resulting costs
- Higher error rates
- Longer time to onboard and heal networks
Many of the manual tasks are boring and repetitive for skilled operations staff and experts who could be freed up to solve more strategic operational issues. Due to the increasing shortage of skilled expertise and exponential increase in network complexity driven by 5G/Edge, maintaining the status quo of complex operations, manual processes and workflow-based approach is no longer a viable strategy.
Stratoss™ is designed around a radical technology that leverages an opinionated product model. A standard lifecycle model is the basis for the behaviour for each component such as a VNF and the foundation for a set of productized higher-level opinionated behaviour patterns. Stratoss™ requires that all instances of each element behave in an identical way. This lays the foundation for imposed design and extreme intent-based automation levels.
Intent-based service modelling enables services to be modelled and the relative behaviors between the elements to be declared without the need for manual-intensive workflow or programming. The service model and underlying standardized lifecycle model and associated patterns are then used for all Day 0 – Day 2 functions, leveraging in-built tools to ease and accelerate the onboarding and testing of VNFs and services.
The CI/CD Hub is a reference deployment of a best practice suite of Continuous Integration and Continuous Delivery (CI/CD) tools. These collectively providing an infrastructure for Assembly and Resource package and descriptor development, release and distribution management. It leverages common, open source, third party tools augmenting Stratoss specific tools to enable an integration with one or more Stratoss instances as part of a holistic CI/CD environment. This spans multiple environments such as Dev, Pre-production/staging and Production but it is not limited to these.
The integration of Stratoss with a CI/CD process does such as CI/CD Hub neither productizes nor mandates the set of third party tools it deploys. Indeed, the CI/CD Hub does not provide these tools, rather it simplifies their installation. The selection of these tools does not prohibit any or all of their functions being realised using a number of other commercial or open source tools. Nor does their inclusion constitute an endorsement.
Maintenance of the environment post installation falls outside the scope of the CI/CD Hub, excluding the set of Stratoss specific tools (e.g LMCTL)
At the core of CI/CD process for Stratoss are 6 components:
- Source Version Control Server
- Artifact Repository
- Build Automation Server
- LDAP Authentication & Authorisation Server
- Stratoss command line tools
- A local, designer/developer git repository
The CI/CD Hub realise these using the following;
Collectively, these constitute a CI/CD environment. With the exception of LMCTL which is developed and maintained by Accanto, the remainder are third part tools.
An additional requirement exists for Designers/developers to have local git which is installed on a Developers local machine. This differs from the remainder which are all deployed in a CI/CD server. As such it falls outside the remit of the CI/CD Hub.