Overview

• 1: What is it?
• 2: How does it work?
• 3: Why a standard?
• 4: Why the project?
• 5: What can it do?
• 6: Project history

1 - What is it?

FreeCONF is a software library you add to your application to allow it to be managed by DevOps tools. Whether you use FreeCONF or any other library that supports the same standard, they all appear the same way to the DevOps tools. This approach is similar to JMX or SNMP but much, much more powerful.

DevOps tools all provide a variety of ways to integrate applications to their tool. This is different. Here applications export a “map” of their management capabilities that DevOps tools can use to eliminate the integration step and let you immediately start automation. You can read more about how this is done or look through the examples to get an idea.

What a minute! You still have to integrate a library like FreeCONF into every application and DevOps tool. True, but you do it once for every application and once for every DevOps tool and now they all interoperate with each other forever no matter the application or the tool. This keeps software developers away from your Ansible playbooks, and DevOps engineers away from writing Terraform Go plugins (unless they want to).

FreeCONF is written in Go but work is in progress to make this available to many other computer languages. To that end, because this is a standard, you can use any software in replace of FreeCONF that implements the standard and still interoperate with all the same DevOps tools.

What sets FreeCONF apart from other solutions is its utilization of well-established IETF standards such as RESTCONF, YANG and gNMI. Without these standards, this approach would just look like another platform requiring community plugins to be useful. No plugins or repos of playbooks here!

You don’t have to be all in! Incorporate as much or as little of FreeCONF to suit your needs and use this alongside whatever you are using now.

2 - How does it work?

Applications that use FreeCONF become available on the network to compatible DevOps tools through auto discovery or direct list of addresses and ports. DevOps tools can pull the list of management capabilities from applications. DevOps tools do not understand what the application is but it knows how to send or get configuration, pull or push metrics, call functions or listen to alerts. As a DevOps engineer, you are still in control of every management facet the application makes available.

To illustrate this concept, consider the hypothetical scenario where an individual has developed a novel toaster service and seeks to imbue it with manageability.

Steps as a developer:

1. Describe the management capabilities of the toaster in a YANG file like this one..
2. Write and/or generate code to connect toaster software definitions described in the YANG file.

Steps as a operator:

1. Start toaster service within your IT infrastruture (doesn’t matter how : docker container, bare metal or physical device).
2. Any tool that can utilize REST APIs can perform access management operations. Tools that integrate RESTCONF-client support would likely make things easier.

For Example:

• An alert tool can read toaster’s YANG file and discover there are two events exported by the toaster service: toasterOutOfBread and toasterRestocked. Operator can configure alert tool to notify operator on Slack when toaster is out of bread.
• A configuration can get the current toaster configuration and then send an updated copy relying on the configuration being rejected if invalid for any reason.
• A metrics tool can pull toast making metrics in JSON format and at any frequency they like. In addition, the metrics tool can parse the YANG and pass along the field descriptions to graphing system such as Grafana. Pushing metrics is possible but requires special server library support.
• A toaster, web admin portal can do any of the above and also call RPC functions like toasting bread by just POSTing JSON data as input and parsing the JSON output response

3 - Why a standard?

Standards obviate the need for integration because both sides can communicate using a predetermined protocol. You don’t need to build your own adapter if you can plug right in!

Standards like TCP/IP allowed computers from different networks to communicate without having support for each other’s specific networking stack. SMTP did the same for electronic messages and HTML/HTTP did it for information.

Are RESTCONF, YANG and gNMI the next standard for application management? They might be, but whatever it is, with a library like FreeCONF, you don’t need to care. As new standards emerge the FreeCONF community will support it and your code doesn’t need to change.

Aren’t defacto standards good enough?

“Tool X is the defacto standard for doing this in the industry so I don’t see the need for an official standard”

Every standard, defacto or official has a life span. Defacto ones might be a few years, official ones can last decades. When a standard lasts long enough for an application to ship with support built in, it changes the game. An application with built in support does not rely on fragmented set of communities to fill the gap sometime later. When support is implemented by the application developers it tends to be complete because they know the application the best.

Additional reading

To get an understanding of the genesis and impact of standards you can read the book Where the Wizards Stay Up Late to appreciate the before and after of each standard.

4 - Why the project?

Current systems

Terms

Let’s settle on the following definitions:

• Management - Configuration, Metrics, Alerts, RPCs, Security
  Example RPCs: Backup, drain queue, build report, take snapshot
• Applications - Running software critical to your business
  Examples: Mysql, HAProxy, Kubernetes, Custom Applications
• Tools - Software used by DevOps to manage your applications
  Examples: Ansible, Grafana, Kubernetes, Terraform
• Integration - Custom scripts or software written by DevOps to allow tools to manage applications
  Examples: Ansible playbooks, Terraform plugins, Bash, Python, Admin Utilities
• Automation - High-level data and orchestration. The “Fun Stuff!"
  Examples: KPI, Application Lifecycle handling, A.I., auto-scaling, auto-repair

Obstacles for DevOps

1. DevOps has to build the “Tool/App Integration” part only so they can get to the fun “Automation” part.
2. Every line of code in “Tool/App Integration” locks DevOps into each tool.
3. Applications upgrades or rollbacks often require changes to “Tool/App Integration” which require testing and change management control.
4. Each application is different and code reuse can be hit or miss.
5. Copying code from internet to jump start integration often finds incomplete, buggy unmaintained solutions. Anyway you look at it, you now own it.
6. When you discover a new config, metrics or alert you want to capture, it means redeploying code “Tool/App Integration” which requires testing and change management control.
7. Configuration often requires creating a template even when you want to change a setting or two. This template is constantly changing with each application version which means deploying a new template which means more testing and change management control.
8. Each and every management change requires application developers to communicate the change before support is needed and enough time to accomodate the change.
9. Often you need to support multiple versions of an application which means support both versions of an application in case of rollback. It also means knowing when to safely remove legacy versions.

Obstacles for Application Developers

1. Creating new configuration means relying on DevOps to support it first
2. Watching for health related events often means documenting precise logging conventions and then coordinating with DevOps. Once defined the structure is difficult to change and prone to siliently breaking on subtle application changes. Because these are alerts, you don’t find out they are broken until after your customers do.
3. Like health events, creating new application metrics often requires DevOps to write structured log parsers and possibly new ingestion scripts. DevOp will prioritize metrics that indicate stability over simply informative metrics and could push back in implementing at all.
4. If any of the above is slowing you down and you want to help, you need to learn a lot of tools, how to use them safely, securely and in a maintainable manor.
5. Any time you spend in DevOps is time you are not writing application code
6. For streaming metrics, you need to integrate client libraries into your application code locking you into that tool. This also means when developing code locally, you need to be able to disable metrics. This also means issues with metrics streaming won’t be discovered until in production.

Obstacles for Software Vendors

1. When you have multiple services, customers often struggle to get everything perfectly configured together. You end up building custom tools to help them. These tools are expensive to build and sometimes conflict with tools customers are already using.
2. Producing helper scripts for each and every management tool is a lot of work and will never meet every customer’s needs.
3. Applications metrics are often off the table because it means coupling your software to every conceivable metrics system available. Only option is logging and hope your customers implement log parsing. It also means never changing your logging strategy.

The ideal system!

Here all the applications and tools agree to a predetermined, industry wide, management standard protocol. Tools download the applications published management manifests and operate on behalf of the DevOps teams for automation. Manifests list every configuration, metrics, alert and RPC. Once the manifest is exchanged, then tools know how to fullfill automation tasks from the tool on behalf of the DevOps engineer.

Aside from removing every obtacle list above, some more reliefs come forward:

Reliefs for DevOps

1. Entire configuration, metric, alert, RPC available across every appliction, infrastructure, tool and OS available ready for automation with zero effort.
2. Precise documentation on every management facet.
3. Freedom to change tools or use multiple tools as they see fit without having to change application or integration code.
4. Configuration is validated before being applied. If configuration is wrong, it will not apply.

Reliefs for Application Developers

1. Empowered to connect all application management operations without requiring any tasks from DevOps.
2. Freedom to use different sets of tool for different environments. Use Prometheus in local development, log to postgres in end to end testing and use AWS Active monitoring for production. All work on the same application binaries unaltered.
3. Generate all documentation. Documentation is still important so DevOps can decide which options they need to automate.
4. Your applications get deployed faster because integration scripts do not need to be updated or tested.
5. Safely do rollbacks and again because of no integration code to break

Reliefs for Software Vendors

1. All your software is compatible with every customers mananagement tools.

The catch

1. Everyone would have to agree on a standard.
2. Standard would have to be capable enough to match everyone’s needs.
3. After agreeing on a standard, all applications and tools would then have to implement the standard.

Let’s tackle each one.

Agreeing on a standard

Every tool and application uses a library to implement the standard. If there were multiple standards, then the libraries can abstract out the difference by supporting them all. FreeCONF supports both RESTCONF and gNMI wire protocols. Any new emerging standards would gladly be added to FreeCONF.

Capable enough standards

YANG, RESTCONF and gNMI are all very capable. Networks have had years of experiences with these standards and their capabilities are well documented but you should judge for yourself of course.

Implementing the standard

1. Challenge: I need a library that implements the standard.
   Answer: FreeCONF and others
2. Challenge: Awareness the standard exists:
   Answer: You’re here aren’t you? Spread the word, share this site.
3. Question: Time to implement the standard:
   Answer: Take it slow. See “What can it do” for strategies to get there in parallel to what you are doing now.

5 - What can it do?

It is important to remember FreeCONF is a software library. If you are looking for final applications to download see some options in Resources. With a library however you are in complete control of building what you need.

Ideal

While this is the goal:

The basic unit starts with this:

With this basic unit, you can do a lot.

Just a few example use cases

1. Document existing configuration - Describe your current config in YANG and generate docs. You’ll have to make sure your application code and your YANG stay in sync but this is true of any manual documentation. This way you can separate content from format. YANGs ability to reuse definitions it very useful.
2. Validating configuration parser - Use FreeCONF to load your configuration files into your application. Follows the Inversion of Control pattern. Your configuration document will be accurate and configuration will be validated before it hits your code.
3. Edit live configuration - Loading configuration from files or REST is no different. You can expose just the configuration that you want to support live changing like debug log level or manage a list of users.
4. Decoupling metrics systems - Unlike configuration or structured logging, implementing metrics almost always requires coupling your application code to a proprietary metrics service locking you in. Use FreeCONF to decouple that. You don’t need to capture RPCs, config or events in YANG. See one of the metrics examples like Prometheus to see how it works.
5. Wrap existing REST APIs - Having a schema to a legacy API helps consumers and also makes the API available to RESTCONF and gNMI tools.
6. General purpose REST API - I may be biased, but RESTCONF APIs are far more powerful, easier to maintain and easier to consume then OpenAPIs. “Management” is really a perspective. Putting items in your web cart is really just managing objects in another object.
7. Admin Portal - While this may seem out of scope for FreeCONF, the ability to organize large sets of configuration quickly while providing both a REST API and dynamic user interfaces is quite useful. You can send configuration to endpoints by calling Ansible playbooks or editing Chef databags.
8. Bridge to other protocols - Just like RESTCONF and gNMI are just wire protocols to the basic unit, you can write a bridge to other protcols like JMX, SNMP, DOCSYS, COMI or proprietary protocols.
9. File Parser - Generate code based from YANG to decode bytes in a file or wire protocol like msgpack or protobuf that do not contain self-describing meta data.
10. Generate OpenAPI definitions - YANG is truly a superset of all other protocols. Partly because it is very complete but also because you can extend the YANG to include meta data used in other definition systems like defining 404 errors. Here is one project that converts definitions. But you can create your own fairly easily by converting the YANG to JSON using fc-yang utility and then use jinja or your favorite templing system to convert to openapi definitions.
11. Generate gRPC definitions - Rationale and strategy is same as above
12. Validate YANG files - Just use the YANG parser in FreeCONF to parse YANG files and look for specific things or ensure they are syntactically correct.
13. Generating end-to-end tests - Walk each item in the YANG and generate isolated tests for just that item.

This is not the end of the list by no means, just ideas.

6 - Project history

By Douglas Hubler

In 2001, I was first introduced to management software for a telephony system, which marked the beginning of my involvement in this field. Together with my colleague, Damian Kremenski, we developed a basic meta language to assist with management duties, which proved to be crucial in our work. Over the course of the next decade, we dedicated ourselves to developing plugin APIs to allow third-party developers to add services to the telephony system, with our modeling language serving as a key component.

While we were proud of the management system we had created, we were also aware of the challenges involved in accessing it due to its proprietary meta language and reliance on plugins.

In 2014, I transitioned to a new role in the networking field, where I became familiar with two management standards, NETCONF and YANG. YANG is a modeling language, while NETCONF is a protocol that leverages said management model. Given my experience in developing a management meta language previously, I quickly recognized the value of YANG. While NETCONF was powerful, I found its newer REST-based counterpart, RESTCONF, to be more exciting as it was expected to increase adoption rates.

As a user of these standards, I was impressed with how they addressed interoperability, which led me to envision the potential for an open-source implementation of these standards that could be used in general-purpose application development. This solution would break free from the limitations of proprietary management tools and the plugin-oriented systems that I had contributed to in the past.

Between 2015 and the present day, I have been actively implementing the YANG and RESTCONF standards. Throughout the development process, my main objectives were to ensure that the library did not interfere with developers’ work and to make complex tasks possible while keeping simpler tasks easy.

In 2023, ground broke on supporting Python. After many attempts to port FreeCONF to other languages, we finally found a way that is scalable, maintainable and familiar to Python developers. This same strategy can be used to support every language. This is still a work in progress but well past proof of concept.

Also in 2023 support was added gNMI; a wire protocol that can work in replace of RESTCONF. Not only did adding gNMI bring a greater set of DevOps tool support it remains completely abstract and optional for all applications that use FreeCONF.

I cannot see DevOps in the same way now. Ansible playbooks look like homework ripe with fleeting assumptions. Terraform plugins look endless. JuJu looks sexy but too few applications. Datadog integration looks like a decision that cannot be easily undone. All of these tools are amazing and necessary but if each added support for these management standards then they would remove the burdon put on their community to build elaborate bridges just to use them.