Now let me address this right now, before you go any further. The answer is both. I also apologize for the lack of pictures in this post.
Being that my profession is to create content and, quite honestly, put myself out there, I am open to criticism and debate all day everyday. I expect to get negative feedback. It’s fine, I’m only human and can’t be rock solid every time. I apologize now if you thought my title on SDN vs Automation was click-bait-y, and chances are you found this title to be the same. Sorry again. I really wrestled with what to title this one before going “No, I think CLI vs APIs is what it has to be.”
A series of tweets took place criticizing my post on SDN vs Automation (again, that’s fine), but I wasn’t expecting a remark from… let’s just say someone I respected quite a bit and whom I recently contributed a fair amount of hours to supporting. I won’t dive into how I felt about their comment, either. But they apologized and this is the interesting part – they mentioned that they are seeing the same discussion rehashed over and over again. And that begs the question….
Should we still talk about APIs vs CLI?
I’ll leave IPvZero out of this one since I namedropped him in the SDN blog that spawned all of this. These remarks are my own.
I do think we should have this discussion, and that it remains relevant today. Why? Because the DevNet certifications have only been “a thing” for 9-ish months at the time of this writing. Right now, there are thousands of people cramming for DEVASC to try and achieve their DevNet Class of 2020 badge. These Cisco certifications have created a trend in networking that is, in turn, creating thousands of their own pioneers and trendsetters within their enterprise as they roll up to work ready to write Python code rather than SSH into a terminal today.
Put another way, the API is out of their comfort zone, and people are just now starting to warm up to it.
So, in my opinion, this conversation – while it is one that may have been around since “2015” – is one that is still relevant, and honestly, more relevant to a larger audience now more than ever. This conversation may be a new conversation to newcomers to this technology. Or maybe they are viewing this conversation in a new light now that they are trying out automation.
So let’s cut to the chase. Maybe the coolest thing about automation and APIs is how much it has changed, even over the last year. I remember when I saw the Cisco Nexus API that accepts CLI commands (NX-API CLI). You POST basically any command (or series of commands) to the API, and it returns structured data. I thought that was wizardry. Fast-forward to today, with the advent of NetworkToCode’s parsers, the Genie parsers, the TTP library, and so many more options that I’m forgetting, now you can get structured data back from basically any platform, and even create your own parser if it doesn’t exist. Kudos doesn’t even begin to describe the respect that these contributors deserve and how they are shaping the next generation of network engineer.
But I’ll also take IOS-XE devices for example. They run the good ol’ fashioned CLI that we know and love, but also combine the power of YANG modeling for API and automated interactions. Getting really comfortable with YANG is a big lift for even intermediate automators, and it’s a skill I’m glad I took the time to do. Now I view a YANG model sort of like this – it takes the “show run” or “show protocols ospf” or whatever command that I am used to running, and it turns it into a pre-structured data output that I can interpret on the fly, or study up on in advance.
But let’s not also forget the vendors who had network automation in mind from the get-go. I’m talking about Juniper and Cumulus here (and I’m so sorry if I am omitting your brand that does automation well for decades – I just simply have experience with a handful of platforms and haven’t test driven every solution there is). I quite frankly find it more pleasant to work with their APIs and structured results rather than their “set” commands. How nice is commit check, commit confirmed, and rollback, too? It’s like version control is built onto the box (Note: do not consider this a replacement for version control). You may have been working with APIs and structured data this whole time and didn’t even know it.
The point is, this day in age, it’s actually quite easy to use both at the exact same time. The transition from “show commands” to “show commands over an API” isn’t a colossal leap anymore.
But here’s the thing –it all comes down to the individual’s skillset and preferences. There are people out there (you are thinking of them in your head as you read this) who are better at the CLI than I am at either the API or CLI. Should I demand they learn APIs?……
Maybe not demand, but encourage?
“Demand” is a strong word. You never want to FORCE anyone to do anything they don’t want to do. Don’t roll up to work and tell your senior architect “YOU NEED TO LEARN PYTHON.” But it’s fun to dream about “what if they did…?” Could you imagine what solutions they could come up with if they even knew basic Python and HTTP? Especially in an era where you can keep your CLI commands, but interact with parsed or already-structured/modeled responses. I dunno. I think I would tell said architect about the power of Nornir’s concurrency or Ansible’s state management to see if there is a spark in interest – at least try to say “we can take your awesomeness, because you are in fact awesome, and maybe even do more with your awesomeness.” Isn’t that how automators really became automators in the first place?
If you really think about it, learning the CLI isn’t a choice. It’s just what you have to do to learn networking and how to configure devices. You can get through CCNA -> CCNP and barely touch automation. Just learn enough JSON and EEM to pass the test.
Choosing to get really good with Python, APIs, and automation is a choice, though, so why do you choose to learn it if you already know the CLI? It’s because you see potential in it, somehow, to do more than you can with just the CLI alone.
Look, you should never, and I mean ever, consider an API for a replacement of the CLI. I will tell anyone right now get your CCNA before your DevNet Associate. I know I know – I opened up my portion of the DEVASC course singing “Bye bye to the CLI” – it was a joke(ish). The CLI will always exist, it will always be the de facto standard and how you learn to configure a device first. But you should also recognize that it isn’t as relevant today in an era of SDN and scripting as it was, say 5 years ago. You can even look at the exam blueprints to validate that. “Clicking” and “Scripting” now make up 40% of the CCIE score. 40%. Forty. Let that sink in. An expert should have 40% – almost half – of their skillset in non-CLI tech. Yep, CLI still has the majority. And it will always have the majority, because that is the nature of the CCIE. There is a forthcoming DevNet Expert certification where I expect the opposite weights to be true.
So which one is better? Lol. No, that’s not the question. The truth is that no matter what, play to your strengths. If you are a BOSS at the CLI, roll with the CLI. If you prefer working with Junos’s PyEZ SDK because of how automation-friendly it is, roll with that. If you believe in the power of YANG models or open standard libraries like NAPALM, enjoy.
Whether you are new to networking or a 6x CCIE, I would say this. Learning Python, then APIs, and THEN all the automation stuff is hard. I get how or why you would feel strongly about sticking with the CLI. Like most skills, though, I believe there will be a reward for chugging through network automation studies, even if it takes years. Growing from one awesome skillset to two awesome skillsets should only pay dividends in the long run.
Thanks for bringing this up Knox! We definitely need more discussion as we rush headlong into learning Python in order to automate all the network things.
I have a problem with our current approach: that network folk are being sold the vision that becoming a programmer will solve all their problems. It won’t. Scripting and APIs give us alternative approaches for curing some of our configuration headaches but programmability alone doesn’t help us move the needle.
Our current automation tools – be that CLI scripting, SDN controllers accessible over API, policy engines pushing specific policy data into templated configuration – still leave us with too narrow a view of our networks. This is typically limited to a specific vendor, platform or network domain – and so we need to be able to orchestrate activities across a number of automation approaches in order to deliver operational shifts on a larger scale. We need to take a look at the bigger problem and understand what we are trying to solve with automation.
This is where the ideas of Intent-Based Networking come in. Very simply, the business problem is defined and a number of translations take place to change the business requirements first to technical requirements within each network domain, then into configuration intent in each so it can then be fulfilled using orchestration workflows. Each workflow will have a number of associated actions and potentially kick off a series of automated activities in device configuration and policy instantiation. At the same time, rules are defined and pushed to an assurance engine that can then verify that intent is correctly met by the network, and if not, what needs to be changed.
On top of all that, the usual operational ecosystem for a network needs to function so that all our processes around maintaining, supporting and troubleshooting the network to maximise availability. Eventually, once the Intent-Based Network is trained and able to self-heal (!) that will lessen the need for these systems but there will *always* be a need to understand the underlying technologies because software goes wrong sometimes so they tell me!
I’ve been lucky enough to work first in the design and architecture space which has allowed me see the big picture in terms of building networks which maximise availability of application service, and are supportable first and foremost. And now in the Intent-Based Networking space for a software vendor – IP Fabric – who are working on building the intelligence into their assurance engine to enable exactly this kind of approach.
As such then, as you rightly suggest, the idea of “CLI vs API” is almost irrelevant. To answer that question in the long run is to recognise how configuration interaction is going to happen with the network devices? And how much visibility of the network is required from a troubleshooting and maintenance perspective? It’s a fact that when it comes to getting down to the nitty gritty with a failed device, network engineers like nothing better than a CLI to give them access to the detailed info they need. So unless there is something in the operation tooling or assurance platform that contains a centralised view of that state and config detail (such as in IP Fabric) then CLI will remain key. How can you query an API to a box if its connectivity is down?!
We need to ensure that all network engineers appreciate that “CLI vs API” is only a very small part of the real Big Picture, and that designing networks to be available and supportable using *whatever* means are necessary and appropriate is the most important thing.
This comment … This comment is everything. Thank you for it. It is constructive, informative, educational, and backed by experience. Even sitting here reading it, I found myself thinking “hum. I never thought of it that way.” I also thought “hum. I need to check out IP Fabric.” Guess it’s time for me to grab that OVA!
Thanks Knox! I know that the team have been in touch regarding that and we’ll do everything we can to help of course!
Very keen to show how we help with people’s network automation projects, as well as how we fit into the bigger IBN picture!
Thanks again for bringing focus onto the points in your post! Great conversation to open up!
Hi, I found your site by mistake when i was searching yahoo for this issue, I have to say your content is in actuality helpful I also love the theme, its amazing!. I dont have that much time to read all your post at the moment but I have bookmarked it and also add your RSS feeds. I will be back in a day or two. thanks for a great website.
This is a good subject to talk about. Generally when I come across these sort of things I like to post them on Digg. This article probably wont do well with that crowd. Ill take a look around your site though and submit something else.