Cloud-Native Network Function (CNF) developers may learn much by studying how 12 Factor Apps are built, scaled and maintained. With X-Factor CNFs (X-CNF), we build on the lessons learned from building 12 Factor Apps. This document builds directly on the work by Adam Wiggins and the 12 Factor App authors at 12factor.net.
Following these patterns will help guide you to construct CNFs which are easier to develop, operate and maintain.
Like 12 Factor Apps, X-CNFs have the following properties:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud and service provider platforms, obviating the need for servers, virtual machines and systems administration;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.
X-CNFs also have additional properties not common in 12 Factor Apps which enable their use as a CNF:
- State their payload type for easy service function chaining orchestration;
- List their supported mechanisms supported mechanisms in order of preference to facilitate wiring to a data plane;
- Connect to Cloud-Native Microservices over their default orchestration-managed network interface;
The X-factor methodology can be applied to CNFs written in any programming language, and which use any combination of backing network services (bridge domain, subnet, VPN, ToR port, etc) communicating over a well defined payload (ethernet, IP, MPLS, VXLAN, etc) and mechanism (Linux interface, SR-IOV, memif, etc) to a data plane (physical, OVS, VPP). The X-factor CNF may also use any number of Cloud-Native services (database, queue, memory cache, etc).
Finally, a CNF level system is proposed. These serve two purposes:
- Guide the community towards best practices that allow the CNF to fully leverage the Cloud-Native environment in which they live.
- Describe the level of operational risk the service provider will take on when introducing a CNF into their environment.
The contributors to this document have been directly involved in the development, deployment and operation of Cloud-Native infrastructure in a variety of key areas.
- Container runtime
- Software-defined dataplanes
- Physical networks
- Cloud-Native Functions
This document synthesizes our experiences of both running software-as-a-service apps in the wild and constructing Cloud-Native infrastructure which CNFs are built upon. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring. X-Factor CNFs is inspired by and borrows heavily from the 12-Factor Apps methodology.
Who should read this document?
Any developer building Cloud-Native Network Functions. Ops engineers who deploy or manage such applications.
– Factors adapted from the 12-factor methodology –
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
IV. Backing services
Treat backing cloud-native services as attached resources
V. Build, release, run
Strictly separate build and run stages
Execute the app as one or more stateless processes
VII. Port binding
Not recommended in X-factor CNFs. However, if necessary, export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
– Factors unique to X-CNFs –
XIII. Do not require privileges
The CNF should run without privileges. Privileged actions should be managed by the scheduler and environment.
Explicitly state payload types consumed and produced
XV. Interface mechanisms
List mechanisms supported in order of preference
XVI. Bind by payload and mechanism
Bind to other CNFs by payload and mechanism rather than by upstream or downstream CNF type
Treat metrics as event streams