Putting Cloud Native Claims to the Test

Since it’s broadly accepted that cloud native software design is essential for successful network transformation, just about every vendor now claims that their network functions are cloud native. Operators should be wary of such claims. As our recent white papers explain, it’s extremely difficult to refactor legacy network function software with the architectural requirements of cloud native.

putting-cloud-native-claims-test-sports-car-wind

Also, you can’t simply take a virtual network function (VNF), wrap it in cloud native marketing and make it a cloud native network function (CNF). That’s just not how it works. CNFs really need to be built from scratch. And that takes time and investment.

But how can you test cloud native claims? How can you know for sure that the software NF you’re getting is really cloud native?

We’ve put together a list of ten questions to help you evaluate software NF products and see whether they pass the cloud native smell test.

1. Is the software packaged as containers and orchestrated by Kubernetes?

While historically it has been possible to embody cloud native architectural characteristics in VM-based applications and orchestrate with a Generic VNF Manager, containers and Kubernetes have come to be synonymous with cloud native and should now be regarded as absolute requirements for a CNF.

2. Is the software composed from multiple microservice components, each of which exposes an open, versioned and documented language-agnostic API?

Vendors should be prepared to share details of their microservices as reusable building blocks and explain in detail what function each microservice provides.

3. Are the microservices truly loosely coupled?

If two or more microservices access state in a shared store where each microservice relies on a common schema for the shared state, then these microservices must be regarded as tightly coupled.  This is a cloud native anti-pattern since it introduces dependencies that prevent microservices from being independently enhanced.

4. Does the NF comprise a mix of stateless microservices (for event or message processing) and stateful microservices (for storage of long-lived state)?

All CNFs that relate to control plane functions should exhibit this design pattern, which is essential for straightforward automation of scaling, healing and software upgrade.  Data plane CNFs will necessarily be stateful.

5. Do the individual microservices scale out dynamically by adding software instances under the automatic control of Kubernetes?

All stateless microservices should scale out in a very simple fashion by adding new software instances, without requiring complex initialization or configuration steps to bring up each new instance.  Note that scaling of stateful microservices is typically more complex, but this should still be handled automatically by Kubernetes with the aid of custom Kubernetes Operators.

6. Are the individual microservices fault tolerant according to an active-active N+k redundancy scheme?

A CNF should be resilient to the loss of an individual software instance, simply by providing a small amount of surplus capacity.  It should never require 1+1 active-standby protection.

7. Can a failed software instance be recovered simply by killing it and instantiating a new one? 

The health of individual software instances in a CNF is monitored by Kubernetes, which expects to be able to kill and replace the instance if it misbehaves.  Complex healing procedures should never be required.

8. Can software upgrades be applied to individual microservices in a non-service affecting manner by a process of rolling update?

If the microservices are loosely coupled and the APIs they expose are properly versioned, then automated in-service software upgrades can be applied easily and automatically under the control of Kubernetes.

9. Is NF configuration managed declaratively?

A CNF should not expose a command line interface (CLI), nor should it rely on procedural configuration management via sequences of API calls.  Instead, configuration should be declared in documents maintained in version-controlled repositories, where checked-in changes are applied automatically to all the software instances that make up the CNF.

10. Does the NF expose a comprehensive set of instrumentation APIs that are compatible with the appropriate cloud native tools?

Prometheus and Fluentd are now so ubiquitous in the cloud native world for collection of metrics and logs that all CNFs should implement native APIs towards these tools.  CNFs should also expose tracing information that provides visibility of all message and event processing activities, but given the lack of suitable open source solutions for most NF use cases, proprietary tracing collection and analysis solutions are acceptable.

Metaswitch understands the time and effort required to build CNFs because it’s how we’ve built our products for over half a decade. For example, both  Clearwater Core IP Multimedia Subsystem (IMS) and Metaswitch Fusion Core are truly cloud native, employing microservices methodologies and supporting pure container-based deployments.

For more on how to become a cloud native telco, please see our recent white papers