At the recent Open Networking Summit Europe 2019 in Antwerp, Belgium, I co-presented a talk on “Crafting Cloud-Native Network Functions (CNFs) Using the X-Factor CNF Methodology” with Frederick Kautz of Doc.ai. If you didn’t have a chance to attend, I’ll explain in this post what we mean by X-Factor CNFs, point to how we use them in Network Service Mesh (NSM), and suggest why they’re likely to become important to many enterprise app developers in the future.
First off, though, I want to give a shout out to Fred, who has been leading the formalization of this work. He was the real X-Factor CNF expert at the talk, while I was bringing the NSM user perspective.
So what is the X-Factor CNF Methodology? Very simply, they are additions to the popular 12 Factor App methodology for building software-as-a-service apps. The original 12 factors came out of Heroku and were refined by Adam Wiggins almost ten years ago. They were initially aimed at enterprise-type applications but have been widely adopted as guidelines for writing all kinds of applications within the Cloud Native landscape.
However, as we’ve started to use a Cloud Native approach to solving ever more complex computer problems, it’s become clear that we need to extend the methodology beyond the original 12 factors. That’s particularly true when it comes to Cloud Native solutions that require telco-type networking and workloads.
So, Fred has come up with five additional factors that we feel account for the additional needs of Cloud Native networking. We’re calling them X-Factor CNF to indicate that they are extensions to the original set. They are:
- Factor XIII: Do not require privileges
High-performance networking applications typically need to run in a special, highly-privileged mode where they essentially take over the whole system on which they are run. That’s not possible with a conventional Cloud Native approach. So, this new factor says that when it comes to networking, your CNF should not require privileges.
- Factor XIV: State your payload types
The networking world works at different levels of connectivity. Enterprise applications typically leverage only layer 4 payloads, for example, which is why we developed NSM to solve lower-level connectivity issues. That work helped us understand that networking applications need to explicitly state what payloads they serve or want to consume.
- Factor XV: List interface mechanisms in order of preference
This is another factor that developed from the work we’ve done with NSM. We use the term “interface mechanisms” a lot within NSM to refer to the different ways in which you can interconnect applications. In the Cloud Native world, you usually just open a network socket and start pushing packets into it. With NSM, you are able to state what type of connectivity you want, and when doing that, you need to place them in an order of preference.
- XVI: Bind by payload and mechanism
This derives from the previous two factors. It requires that when an application states that it wants to consume a specific payload using a particular interfacing mechanism, the underlying infrastructure should select the other end of the communication based on the same two preferences. In proper Cloud Native fashion, you don’t implement your networking packet processing application or telco-type application as a single monolith. Instead, you split it into smaller functions that you can combine and use to implement different types of functions. So when you want to build more complex functionality and bind several of these together, the underlying infrastructure will let you bind them based on the payload and interface mechanisms that each of them have declared they support.
- XVII: Treat metrics as event streams
This last factor is very new and not fully worked through. But the insight informing it is simple: metrics are really important, especially for a complex landscape like Cloud Native where you can expect to have hundreds of CNFs joined together. That makes it essential to understand how they are performing, where the bottlenecks are, etc. The phrase “treat metrics as event streams” is an exact copy of Factor XI of the original set of 12: “Treat logs as event streams.” We’re really just extending the notion of logs to ensure that metrics receive the attention they deserve in the Cloud Native networking setting.
You can see all of these new factors listed as additions to the original 12 (which are explored from a Cloud Native networking perspective in subpages) at a site Fred has put together.
This approach has already been discussed in the CNCF Telecom User Group, and through events like the ONS EU presentation, we’re trying to bring it into the wider community so that people can start trying it out.
We’ve also been following this methodology within the NSM community. I now apply these principles in my work, and I’ve been maintaining our NSM examples repo where we showcase CNFs based on them. Check that out if you are interested in seeing the X-Factor CNF methodology in practice.
While these extra factors are crucial for successful Cloud Native networking, they have value for enterprise applications more broadly. We think they will likely improve how enterprise applications are implemented, for example, as they strive to meet the high standards that telcos typically set for things like availability.
Indeed, it’s becoming pretty clear that, over time, workload types will continue to merge. We’ll see companies like Google getting interest telco workloads and telcos like AT&T wanting to expand more into enterprise-like services. That will likely only increase the relevance of these additional factors.
Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for all the latest open source news and updates from the VMware Open Source Project Office.
