Faucet represents the convergence of modern DevOps practices with SDN—a lightweight, YAML-configured controller that treats network infrastructure like server clusters. With a score of 69.3% in our comprehensive evaluation, Faucet’s configuration-as-code approach and container-friendly architecture make it ideal for organizations embracing CI/CD pipelines, GitOps workflows, and infrastructure automation at scale.
This is part of our comprehensive SDN Controller Comparison Guide, where we evaluate 6 leading open-source controllers across 13 technical criteria.
Faucet at a Glance
| Attribute | Details |
|---|---|
| Overall Score | 69.3% (Ranked #5) |
| Best For | CI/CD pipelines, DevOps workflows, lightweight deployments |
| Architecture | Lightweight, distributed with YAML configuration |
| Programming Language | Python (built on Ryu framework) |
| Primary Protocols | OpenFlow 1.3 |
| Clustering | External tools required (replicated YAML configs) |
| Community | Active and well-supported |
| Key Differentiator | Configuration-as-code with YAML files and GitOps-friendly |
| Deployment Complexity | Low (container-friendly, minimal dependencies) |
| License | Apache License 2.0 |
What Faucet Does Best:
- YAML-based configuration (version control friendly)
- Lightweight and containerized deployment
- CI/CD and GitOps integration
- Built-in telemetry (Prometheus/InfluxDB)
- Production-ready despite simplicity
Architecture Deep Dive
As shown in the figure below, architecturally, each Faucet instance has two connections to the underlying switches. One for control and configuration updates, the other (Gauge) is a read-only connection specifically for gathering, collating and transmitting state information for processing elsewhere using Influxdb or Prometheus.
Modularity and Extensibility
Python based controllers provide a well-defined API for developers to change the way components are managed and configured.
Adding functionality to Faucet is achieved through modifying the systems that make use of its Northbound interfaces. This provides the added flexibility of using different tools and languages depending on the problem being solved. Additionally, increasing the complexity of northbound interactions does not negatively impact the SDN directly.
Scalability
Faucet is designed to be deployed at scale such that each instance is close to the subset of switches under its control. Each instance of Faucet is self-contained and can be deployed directly to server hardware or through containers, moving the administration back into well understood areas of automation.
Due to the lightweight nature of the code and the smaller control space for each instance, no clustering is required – each instance is completely idempotent and concerns itself with only what it is configured to control.
- Faucet contains no intrinsic clustering capability and requires external tools such as Zookeeper to distribute state if this is desired. Extra instances of the controller can be started independently as long as the backing configuration remains identical.
- PCE functionality for these controllers could be pushed down to the instance in the form of modules, or implemented in a similar manner to OpenKilda, backed by a processing cluster of choice.
Architectural Scalability
- It does not yet support a cooperative cluster of controllers.
Interfaces
- Southbound: It supports OpenFlow v1.3 as a southbound protocol and has a support for feature such as VLANs, IPv4, IPv6, static and BGP routing, port mirroring, policy-based forwarding and ACLs matching.
- Northbound: YAML configuration files track the intended system state instead of instantaneous API calls, requiring external tools for dynamically applying configuration. However, it does open the SDN to administration by well-understood CI/CD pipelines and testing apparatus.
Telemetry
Faucet can export telemetry into Influxdb, Prometheus or flat text log files. While Prometheus saves data locally, it can also be federated, allowing centralised event aggregation and processing, while maintaining a local cache to handle upstream processing outages and maintenance.
Resilience and Fault Tolerance
Faucet has no inbuilt clustering mechanism, instead relying on external tools to maintain availability. High availability is achieved by running multiple, identically configured instances, or a single instance controlled by an external framework that detects and restarts failed nodes.
For Faucet in particular, which is designed to sit in a distributed, shared SDN and be controlled by static configuration files, restarting a controller is a quick, stable exercise that has no reliance on upstream infrastructure once the configuration is written.
Programming Language
Faucet is written in Python.
Community
Faucet has an active community developing the framework and it is well supported.
