During a recent NetOps-focused discussion trying to figure out where Puppet/Chef/Ansible/… make sense in the brave new SDN-focused networking world I made this analogy: “Puppet manifest is like Prolog, router configuration is like Java or C++.” It’s a nice sound bite. It’s also totally wrong.
Declarative versus Procedural Programming
Unfortunately nothing good just happens to happen (at least not in IT world, or it might have to do with the second law of thermodynamics), you need something that will make the transition (or find a path) from where we are now to the final state (the what). The something might be a language interpreter (in Prolog’s case performing an exhaustive search of the solution tree to figure out if it can satisfy the requirements specified in the declarative program) or a Puppet agent that:
- Compares the current state of the system (example: web server) with the desired state (Puppet manifest);
- Figures out the differences;
- Applies changes (modifying configurations, creating files, executing commands…) that have to be made to transition the system from the current state to the desired state.
It’s obvious router configurations aren’t procedural programs – they tell a device (or software) what needs to be done not how that behavior should be implemented. In most cases you cannot influence the implementation details; EEM applets are an obvious exception, but the only reason they reside in router configuration is the lack of decent text editing tools on network devices convenience of manipulating router configuration as compared to anything else.
So What’s the Difference?
The real difference between Puppet manifests and router configurations is the level of abstraction. Puppet manifests should focus on resources (example: VLANs) and desired state of resources (example: VLAN 10 present on port GigabitEthernet0/1) not on the implementation details.
Did I say implementation details? Isn’t that procedural programming? No, we’re still in the realm of declarative programming (we never tell the switches how to implement VLANs, do we?), but working at a lower level of abstraction and dealing with how individual devices (or vendors) expect things to be declared.
Confusing? Sure it is, but don’t worry. It’s no more confusing than other things we have to deal with. You just need a bit of practice… and don’t forget to focus on principles, not implementation details.