It’s About Application Delivery, Not Networking


@DrDust tweets:

@packetpushers – at the beginning you appeared very Cisco centric. Now not so much. What do you guys “like” working on?

Be warned, @DrDust. This is probably not the post you’re looking for. But it’s where my mind went after reading your question. ;-)

On Early Cisco-centrism

I don’t especially remember that early Packet Pushers podcasts were or weren’t Cisco-centric. We’ve been doing the show for almost 5 years (!), and there is not a contiguous thought process that ties nearly 300 chunks of audio spread over several channels together. We’ve gotten more conscious about our production schedule now that we’ve built a business around podcasting, it’s true. But certainly in the early days, we were more like the Joker in The Dark Knight.

Do I really look like a man with a plan, Harvey? I don’t have a plan. The mob has plans, the cops have plans. You know what I am, Harvey? I’m a dog chasing cars. I wouldn’t know what to do with one if I caught one. I just DO things.

Yeah. We just did things early on. Lots of that. And so, lots of Cisco came up. Why? For me personally, Cisco was a huge part of my world. I was a somewhat fresh CCIE, having passed the R&S lab 2 years prior. I had taken a job as a Senior Network Engineer at a company with a significant Cisco relationship. That was the proximity knowledge well I was drawing from.

As The Podcast Grew

Packet Pushers started up at an interesting time in the networking industry. For a decade or more, enterprise network designs stood on spanning-tree, largely stable routing protocols, reasonably well-accepted reference architectures, and predictability. A network upgrade was often driven by the need for bigger pipes, as opposed to a new design. For Cisco shops, there was no reason not to upgrade to Yet Another Cisco Product if all you wanted to do was the same thing, just with more packets.

And then things got weird.

OpenFlow came along. A few different L2 multipathing technologies showed up. Ethernet and IP fabrics went mainstream. And of course, SDN architectures (and marketectures) appeared. The weird part isn’t that there was new technology, although that was a bit weird considering the previous decade of relative boredom. It was more that Cisco wasn’t the industry player showing the way forward. Cisco seemed to be a bit slow on the uptake, and not leading as we’d grown used to. Lots of other companies had (and have) ideas that came across as more engaging than the stories Cisco was telling. Easier to use. Solving specific problems. More operator-centric. And in many cases, more cost effective.

While that industry trend was happening, the Packet Pushers audience was growing. As we grew, we found that lots of non-Cisco vendors wanted to talk to us. They wanted to share their stories, and we were engaged by the stories they were telling. So that, as much as anything, is why we’re less Cisco-centric than perhaps we once were. We never wanted to be a vendor-specific show, but rather we just drew from what we knew.

At this point, we try to have as wide a set of viewpoints as we can on the show, talking to established vendors, startups, and the open source community. And still Cisco, who has been a steady supporter for years now, so don’t get me wrong. Cisco still has an important voice – just not the only voice that matters. The conversation has shifted dramatically.

What I “Like” Working On

Now, I need to get the original question, as nothing I’ve written so far really addresses the point @drdust raised. What sort of gear do I like working on, if not Cisco?

Let’s address Cisco first of all. I still do work on Cisco gear. IOS is the CLI I’m most familiar with. The vast majority of networking training I’ve received has been on Cisco gear. Most of the networking books on my shelf are from CiscoPress. I’ve built more Cisco infrastructure than that from any other vendor. I even have a BugID of my very own from many years ago.

Here’s the thing, though. Networking is networking. No matter what the label says on the front of the box, a network takes packets from one place and delivers them to another. In that context, I’ve been looking at networking with far less concern about the specific vendor.

Here are a few highlights of technology I like working on these days. With one exception, this is not hardware or vendor specific, because I believe less and less in vendors and more and more in technology paradigms as a whole. How does the product work? How will it work in the environment I support? How does the technology interact with other technology I’m already committed to?

1. I like the Junos CLI. If I had to pick one CLI, Junos would be it. The CLI is (mostly) intuitive, powerful, and caters to operators. I say that, and I’m still an utter Junos hack. I get e-mails from more experienced Junos jockeys who point out all sorts of time-savings tips that I’m too ignorant of to use properly yet.

Junos is good at helping prevent humans from making stupid mistakes and recovering from them when they do. Junos is (at least thus far in my experience) very similar from platform to platform. I use it on EX switches, MX routers, and SRX firewalls, as well as Olives and vSRXs in my lab. Junos is pretty much the same everywhere.

2. I like virtual networking appliances. Now before you get too excited, allow me to state that the world still needs networking hardware. Lots of it. Hardware matters a bunch. Silicon is a big deal. That’s never going to change, no matter how much the software-focused folks of the world want to minimize the relevance of hardware. Hardware matters. My point isn’t to wave the flag for software and then go, “Boo, hardware.” Rather, my point is to say that virtual appliances are an early indicator of what’s coming with network functions virtualization (NFV). And NFV gets me excited, along with service chaining. The network design options get more interesting, and the reference architecture for NFV and service chaining doesn’t even exist yet. Heck, the protocols are still being debated. Excellent! What a fascinating time to be able to watch networking change, as all of these new ideas are emerging.

Virtual networking appliances aren’t SDN by themselves (despite some marketecture claims, you need to have an application and controller involved), and virtual appliances certainly eat CPU & memory that could be used by other compute loads. But it’s a step in the right direction. I’ve spent a bunch of time cogitating on what virtual networking appliances mean for design models. When you start studying what clustered hypervisors are capable of as far as moving workloads around, the question of network appliance resilience has more possible answers depending on downtime tolerance.

So, which virtual appliances do I like? Really, I’m not picky. I’ll play with any of them I can get my hands on. The CSR1000V is nice, but painful to license. F5 offers a BIGIP in virtual form that can do many things (although the real F5 magic these days is in dynamically spinning up BIGIP instances on demand with the BIGIQ controller). I loaded up a Brocade Vyatta vRouter eval last night to see if I can get it talking to DMVPN infrastructure. The point is that it’s a whole lot easier to see what’s out there now that trial images are so readily accessible for evaluation. So try everything.

3. I like programming. I am teaching myself Python, as well as taking a Python class. I have a lot of programming background. Four year CS degree (COBOL, anyone? BASIC? RPGII? FORTRAN77? No takers? Really? You guys are a bunch of babies…) Much time spent as a casual user of perl. I built a website out of my own PHP code and mySQL schema. It wasn’t much of a site (that’s not false modesty, it really wasn’t), but I did it, and it lived on the Internet for many years.

The rise of network automation, the usefulness and plethora of APIs, and brave new world of IT stack orchestration has convinced me that programming is a skill worth dusting off, and Python is the language to start off with because of how much it’s used in networking circles. Go and Java are next on my list, assuming I can do useful things with Python first.

Wait. Are You Still A Network Architect?

Yes. More or less. But “network architect” isn’t precisely how I think of myself anymore, despite whatever title my current employer labels me with. Network architecture happens to be the IT discipline I know the most deeply. But overall, I think in terms of application delivery. I’m taking pains to learn much more up and down the IT stack, and avoid focusing excessively on routing protocols and whether or not my STP root bridge is in the right place. Not that those aren’t important things. They are. But they aren’t the only things.

IT is more complex than any one of its pieces, and increasingly those pieces are both interdependent and interrelated. Knowing the IT stack is what matters the most, and technologists who understand the entire stack are best positioned to help deliver applications successfully. Silo myopia (Silopia? Is that a word? Can I lay claim to that? Do I want to?) is a problem businesses can’t afford to have anymore. Insert rah-rah speech here about breaking down IT silos, etc.

I want to be in a position in the not-too-distant future where my skill set means I might be best at networking, but quite competent at lots of other things. That’s what I like these days.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • It has always been about application delivery. ;-)

    Now it’s also about automating more and more of that.

    Could it be lots of people will be moving up the stack and the number of people needed on tacking care of the lower parts of the stack will be less ?

    For example if you look at things like Docker. They don’t deal with IP-addresses, they just link applications or services together. Service discovery and all the layers below it do the rest.

    Is it just me, or could it be that we are all starting to solve the same kind of problems because we haven’t found the perfect way yet ?

    To me it looks a lot like all we need is for one tool to hit the sweet spot and everyone will start to use it. An other part or layer of the ‘problem’ taken care off.

    Maybe it’s multiple tools, hitting different sweet spots. That could also be the case.

    There are a number of tools which already try to solve that with: define some yaml-files to create a microservice and one yaml file to define how a set of microservices fit together. To me it looks like we are getting closer.

    Distributed/replicated persistent data for smaller scale projects is still the biggest problem that needs to be solved. Or maybe you just need to start more replicas and pay a little more now. That price will go down eventually.

    Getting from idea to (change of an) application quickly is the ultimate goal.

    I think it’s an exciting but also a crazy world.

    • “Is it just me, or could it be that we are all starting to solve the same kind of problems because we haven’t found the perfect way yet ?”

      I think the key to ultimately working this out is addressing services in a globally unique way that separates location from identity. That’s what we haven’t managed to sort out yet. I don’t know of a new idea that’s got technical flesh on the bones that handles this. Ethernet was never intended for this. As we move up the stack, IPv4 is not sufficient without egregious band-aids, as time has proven. IPv6 doesn’t change the paradigm of IPv4 enough to separate location and addressing, but certainly helps. (Although the way the RIRs are still fighting end users before granting PI space grants *doesn’t* help. I know, I know, it’s a routing table explosion problem they are trying to prevent. Ridiculous that such a precaution is necessary, shame on providers and vendors both.) LISP of course has its purpose in location independence, but relies on tunneling between routers for backwards compatibility with legacy infrastructure. OpenFlow has issues of scale, widely varying support, and unpredictable performance depending on platform, but could be a long term answer. I think BGP is probably our best bet at the moment.

      Mark Burgess has posted, at least indirectly, on your observation. He’s calling SDN DOA as currently conceived. Lots of ideas in his blog post of where we really need to go next. I need to read it 3 or 4 more times to take it all in, and translate his point of view into some vague technical comprehension of how his vision might come about. http://markburgess.org/blog_broadcast.html

  • Thanks Ethan, this post just points out on what I have been thinking in the last months, how to span my skills and what to learn: virtualization, programming, etc. You give some hints regarding the path a network engineer may take, with and opening vision of technologies and vendors. You mention more than once “IT stack”, can you please elaborate what is it and what IT comprises ? Thanks

    • I have just begun Kirk Byers’ “Pynet Applied Python” class this very week. Logged into the lab environment and watched the first set of videos yesterday, in fact.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.