Why RESTCONF

Every service in production needs:

1. fault monitoring - i.e. events on errors
2. configuration
3. administration API - e.g. flushing cache or pausing for db backup
4. performance metrics and analysis - gauges, counters or any read-only data
5. security - for both the management and non-management communications

With just 6 different services you would need to develop and maintain up to 36 custom integration scripts or plugins.

However with a management standard there are NO integration scripts or plugins to write.

How does it work?

Every running service publishes one or more files called "YANG files" describing their management capabilities. IT tools can then read these "YANG files" directly from the running service to discover the service's management capabilties. Once the management capabilties are known, IT tools can manage the running service even though it had no prior knowledge of the service.

For example let's say you wrote a new toaster service and you wanted it to be manageable.

Steps as a developer:

1. Describe the management capabilities of the toaster in a YANG file like this one..
2. Use FreeCONF library (or any other library that supports proper server-side IETF RFCs) to serve YANG files and help developer implement the management capabilties.

Steps as a operator:

1. Start toaster service within your IT infrastruture (doesn't matter how : docker container, bare metal or physical device).
2. Choose an alert service as part of your IT infrastructure (or write your own with FreeCONF) that supports proper client-side IETF RFCs.
3. Alert service will read selected services and discover there are two events exported by the toaster service: toasterOutOfBread and toasterRestocked. Alert service can then ask any operator which events they'd like to be notified about.