Rethinking network management through Network as a Service
Observability as a discipline distinct from network management is still in its infancy within the network engineering realm, with newer job titles such as Network Reliability Engineer (NRE) looking to extract the same organisational value that the more DevOps-aligned Site Reliability Engineer (SRE) provide to the more traditional SysAdmin space. Network as a Service (NaaS) is a new approach to network operations, which often distils down to two commonly accepted meanings:
- An Operational Expenditure (OpEx)-led approach to procuring Managed Network Services and associated network hardware
- A paradigm shift in the approach to network management away from legacy Network Management System (NMS) and associated Element Management System (EMS) lifecycle approaches
In this blog, we’ll focus on the latter, and how the formation of a NaaS Team – or Squad – can improve network observability and enhance your network infrastructure’s insight, uptime and value.. We’ll also touch on the former and larger shift from Capital Expenditure (CapEx) to Operational Expenditure (OpEx) Lifecycle Management approaches, and what this means for shifts in the IT and network industry.
Getting to the root of Network as a Service (NaaS)
“Oh no, not another ‘as a Service’ buzzword-fest…” I hear you say, and yes, in some respects, you would be sadly correct. However, Network as a Service (NaaS) has its roots firmly in the overall cloudification trend found elsewhere within the wider IT and cloud industry, only now having percolated down towards the steadfast realms of the hardware-centric network industry.
At its core, NaaS is about the following differentiators from other more asset-centric approaches:
- Consumption of network infrastructure through flexible OpEx subscription-based models
- Exploitation of cloud-based models such as Infrastructure Elasticity and Horizontal Scaling
- Commoditisation of private WAN services (such as MPLS) into public WAN services (such as SD-WAN)
- Centralisation of visibility of network insight into application-aware dashboards and telemetry systems
Ultimately, NaaS is more of an operational model than it is a consumption pattern. NaaS is chiefly about realigning thinking towards that of the upper layers of the OSI model in remembering that the objective of the network is to solidly underpin a complex soup of interconnected middleware, microservices, PaaS and SaaS dataverse ecosystems which eventually combine toward the aspiration of the modern Twelve-Factor App Manifesto.
Observability versus monitoring
Before we can dive into NaaS, we need to understand the difference in observability versus monitoring – or that is, focus on the Three Pillars of Observability which are:
Each is distinct in its value and requirements in the art of observability, but in short, can be defined as:
- Logs – The act of logging function or component-level activities to an off-system repository for later analysis.
- An example might be a Syslog showing the last reboot of a Linux or NOS Daemon or Service, such as NTPd for System Clock.
- Metrics – The performance of the infrastructure-aligned components within the system, as typically observed over a time-graphed basis.
- An example might be a CPU utilisation monitor, showing that the processor has crept up to 78% utilisation over the last ten minutes.
- Traces – The ability to debug low-level sub-component and function activities to derive context of whether a piece of software code is working as prescribed.
- An example might be a trace within a Python function, showing that the error being caused by Netmiko is because a SSH session to a Cisco router dropped out at v1.99 instead of expected SSHv2.
These differ somewhat from traditional monitoring approaches like Network Management Systems (NMS), which have typically only focused on the Metrics pillar and have superficially referenced the other two pillars. What observability has done to traditional monitoring is comparable to the movement happening from the NMS to the NaaS arena— moving the management concern “up the stack” to focus on higher-level abstraction objectives and away from lower-level hardware-led concerns.
Understanding NaaS as an approach
NaaS is a conceptual change in network consumption as a going concern. Rather than worrying about the network layer as a discrete concern, the network is positioned as part of the wider technology stack – often up to and including the application layer – that is services. While this may sound trivial, it is a huge step change in how Enterprise and Service Provider (SP) Networks run when contrasted against the current de facto practices. NaaS can be simplified as being a “cloud model” – not in the sense that it must be operated and hosted within Public CSPs – but more in the ideas associated with cloud operational models, including Service Elasticity, OpEx-led billing, Horizontal Scaling and API-first integrations into wider ecosystem concerns.
Benefits of the NaaS approach
The main benefit of NaaS is flexibility and adaptability to changing technical stack conditions. Where a legacy NMS-led approach might falsely report “All clear; the network is fine” because metrics are clean and green, a newer NaaS-led approach might instead report “Problems detected in latency experienced by the application due to MTU clipping” because the upper-level traces and logs collectively indicate an issue to a latency-sensitive service bus-based application.
The true strength of NaaS lies in its alignment of the network layer to cloud, DevOps and observability practices to enable the monitoring, management and tracking of the network as if it were just another IaaS or PaaS component of the overall application stack.
How CACI can help you add NaaS to your IaaS and PaaS
With several years of network management and enterprise network operations experience, the CACI Network Services team is ideally positioned to help you transition from NMS to NaaS. Contact us today to see how we can help your business fully shift towards the observability promise as delivered by a NaaS approach to network operations.