Found on the Web: Your CLI Should Be a Server

Guess what I found: a software developer trying to persuade his peers that they need an API version of their CLI tool. Yes, I checked and it’s still 2018, and the year CLI dies seems to be a bit further out than some people thought.

I’d guess this proves that the rest of the world is not so far ahead of us lowly network engineers as blabbering pundits and vendor marketers would have us believe.

Needless to say, the engineers architecting Junos knew this almost 20 years ago.

Latest blog posts in CLI versus API series

More blog posts in this series

Recent posts in the same categories

4 comments:

  1. Anonymous 21 April 2018 10:35
    Paragraph 6a from RFC 1925 strikes here once again. It's amazing to see that you can in fact explain every problem in the tech field with RFC 1925. Ross had very visionary findings over 20 years ago. I think people turn around in a circle (and they can't escape).
  2. Anonymous 21 April 2018 16:00
    The year CLI dies will coincide with the year of the Linux desktop :) ;)
  3. Tony P 21 April 2018 18:03
    Funny, I actually forgot Phil did last year this podcast and (re-)listened now. First, Phil is one of the coolest DEs around here and always a privilege to work or have a beer with for one. And NETCONF is one of the darn'd magic pieces here that allows you to do stuff in days that would take you months elsewhere as customer/developer. Not only the frontend which allows you to bash quickly whole beds of JunOS devices with bitsy ssh & rollback, patch loads but also pyEz, albeit slower, makes doing insanely complex stuff hilariously easy. You'd like all disabled OSPF interfaces, just XPATH 'protocols/ospf/area/interface[disable]/name' out the returned XML config and you're done. And on the newest front take a look @ the JET stuff and GRPC real-time telemetry we ship today where automation is being taken even further ... Yes, shell is shell and it's great to stick together bunch unix filters on a host but managing complex data models on large number of networking devices, if you care whether things ultimately work ;-), is a bit of a different pair of shoes that is something that is probably RFC1925 clause 4 so it doesn't bear to explain further ;-)
  4. Anonymous 03 May 2018 20:36
    Anytime I hear an "end of 'xyz'" announcement, I ask why. Why tells you a lot - if the reason to move off from a CLI-based interface is so that the view of every networking device is consistent and making changes better fits the model of how things work, yes. If it's so you can use a mouse instead of a keyboard - really? I've never been a fan of form over substance, since it usually just recreates an existing problem in a new form. If a gui helps someone understand the underlying mechanism of something, then it's a good long term thing. If it hides things from view or worse yet distorts the view of underlying things, it can do harm.

    I recently heard someone parrot "This is where IaC saves us" - not realizing that code isn't magical. I do think that Cisco's declarative model (Opflex) is step in the right direction because it allows implementation to be separated from design - not because you can use a mouse. Just stop caring if it's a gui or a cli and start caring if it's consistent and helps to clarify how things work in principle.
Add comment
Home
Sidebar