From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

It’s About Application Delivery, Not Networking

1,689 Words. Plan about 11 minute(s) to read this.

@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.