Heavy Networking | January 15, 2016
Show 271: IT Work Culture & Moving Beyond Silos
Ethan
Banks
Greg
Ferro
Listen, Subscribe & Follow:
Today on the Packet Pushers Weekly, we’re going to have a chat about how IT work culture is changing. Some companies are moving from technology silos (I do networking, you do storage, this other person does virtualization, etc.) into being cloud builders.
This shift in mindset also changes how IT organizations think about networking. When you’re building an infrastructure cloud for your customers to consume, what does the network need to look like? How is the network to be constructed and consumed in this new model?
Joining us to discuss this change is Bill Koss, Vice President at Plexxi. You can check out his blog at siwdt.com and the post that spurred this conversation.
Sponsor: OneConfig
OneConfig creates easy-to-use SaaS-based management tools for Juniper Networks. You can simply, centralize, and save on management of EX, SRX, and VSRX platforms. A single Web tool controls all your Juniper devices, including device details and configurations. It’s intuitive, web-based management for campus, branch and managed service provider environments. Check out OneConfig.com/packetpushers and register for a free test account.
Show Notes:
Introduction
- In your “Four Years Later” post, you criticized self-described networking experts as being trapped in a time warp between 1998 and 2007. What did you mean by this?
- In your mind, a modern network:
- Treats bandwidth as a pool
- Focuses on application needs
- Is managed holistically
- Eschews traditional protocols to compute optimal forwarding state
- Features centrally managed state
Rethinking Best Of Breed
- When you present a modern networking approach to engineers, what reactions do you get?
- You mentioned in your blog that there is a shift in the consumption model away from siloed, best-of-breed technologies and towards cloud networking. What does this mean?
Parting Thoughts
- Is siloed consumption (best of breed) going away industry-wide? If so, what do you think is driving the shift?
- If siloed consumption does indeed die, what does that mean for enterprises? Do they move to cloud for their infrastructure, or do they become cloud builders themselves?
- How should a network engineer think about infrastructure to stay relevant for the long haul?
Share this episode
Do you think you could give examples of what gets done differently when a design is done by comp sci qualified, converged ops teams as compared to the traditionally siloed teams? having listened to #271 I’m not sure the benefits of, for example, Plexxi, except that they want to sell to the CIO rather than the networking guy.
Cue Steven’s rant about Computer Science degrees…
One of the reason the networking guys have not followed the trend of using resources as pools like compute is costs… That’s changing, and we’ll be able to start changing the mindset. Hopefully.
I used to work for a regional ISP, on the enterprise side of things. On the customer side of things, the real guru of the place, multiple CCIE dude, super bright guy was one of those not believing SDN. He literally told me that it was a fad. Young guy too, late twenties, early thirties. I was telling him how much trouble it could save him and…. no, fad.
One big problem I am seeing is this: in a lot of places, the life-cycle management of network gear has been: spend a ton of cash, manage it, turn on nerd knobs to extend its life, let it go end-of-life, scramble to get funding because it becomes a huge risk, buy stuff from incumbent because of all the nerd knobs you turned on that others don’t have, rinse, repeat. Getting funding to build a small infrastructure to scale over time is just not how it was done… So starting now is a huge hurdle to jump in a lot of organization.
Thanks for mentioning that Simon. Here are the links to the two places I’ve commented on degrees and some of the other subjects raised in the podcast;
* https://packetpushers.net/podcast/network-break-60-cisco-acquisitions-verizon-iot-ambitions/#comments
* https://packetpushers.net/podcast/pq-show-66-competency-enterprise/#comments
Sure, lots of network engineers are very conservative – but there’s a good reason for it. You are likely to try new and cool techniques of healing a blister, rather than a new technique for open heart surgery, because the price of a mistake is very different. I have seen an environment where OpenStack would fail to create new hosts once in a few weeks, but besides being a pain for ops team – that wasn’t an issue. Imagine a network that doesn’t want to forward any new connections – how many things would brake?
Now, I don’t know what is your experience with modern data forwarding technologies (like TRILL fabrics), but mine are – without an access to a very highly qualified engineer you are doomed. I have tried to troubleshoot an OTV issue with regular Cisco TAC – after 5 days they told me that I have to go and do captures in 6 different places simultaneously, so that they can analyze the issue. But the real issue was that engineer had no clue what was going on and I couldn’t escalate any higher. And this is just OTV – fairly basic and relatively well-known technology.
Or another example – Brocade VDX platform. Great stuff and all, but a hardware failure of 1 switch in a fabric (not necessary a core) – and the whole fabric can stop forwarding traffic, until you find that bad switch and unplug it. I do hate spanning tree and all that it brings, but it’s pretty hard to achieve such a spectacular result with it.
But the main thing why most of network engineers don’t go into these new technologies – is because enterprise doesn’t really need them. Vast majority of the enterprises can be satisfied with 20-year old network. Add some scripts to help you manage devices (even if they just generate a config and you copy-paste it) – and you are pretty well off.
And there’s another important reason why network people don’t want the change – the blame game. Have you ever tried to replace a Cisco gear with something else? I did. You know what? I am not doing it again. New storage hardware arrives and can’t form LACP aggregate: “hey, these new switches you bough are broken” (nope, known issue of the new array). Have to reboot for a software patch (first time in over a year): “these switches surely need lots of hand-holding”. And the best one: small vendor’s appliance, doesn’t work properly. “It’s network fault, it works great with Cisco”. Plug it in to Cisco – indeed some issues go away. Vendor: “I am not wasting my time working with your crappy switch X, just use Cisco like everyone else!”.
So yeah, I am not doing it again. More than happy to recommend a different vendor to CIO or a group, but not going to make this decision by myself.
I didn’t take much from this; we all know well the issues the industry and those within it (for or against change) face. I share Bill’s frustrations (as many others do) but not the target of his ire or his somewhat self interested approach (you’re all too dumb to understand how great my product is).
Many would love to work in an integrated, multi-discipline team with forward thinking leadership (and money to match) but are more likely to win the lottery for many years to come. Incumbent vendors are hardly helping anyone support change (again in their own self interest) and this and other issues are rapidly leading to irrelevance for many.
Nothing like being kicked when you’re down. No-one’s intention I’m sure but the gut feeling I get.