Now let me address this right now, before you go any furtherThe 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.

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 score40%. 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.