* Posts by mbushong

5 publicly visible posts • joined 28 Feb 2013

Q: Just why are AT&T, banks snubbing kit from Cisco & co? A: Control


Pricing vs value

The networking industry has had good margins for a long time. This isn't because of the hardware being intelligent or not (which is the wrong way to think about it btw). It's because there hasn't been much competition. The thousands of features that get deployed mean that the number of functionally equivalent devices for a particular spot in the network is small. With little competition, pricing stays high.

Things like SDN are important for two reasons: first, they reset the architecture to some extent, which reduces the power of all those legacy features, and second, it helps automate workflow. The first point increases competition (read: drives prices down). The second addresses the bigger cost issue: managing all the devices.

Ultimately, Cisco will drop their prices as competition heats up. They will be a player in the future of AT&T, just maybe not to the same extent they are today. But the real battle is going to be over long-term OpEx reduction. Merely making a cheaper switch doesn't really address that. If AT&T just wanted the same network they have today at lower prices, they would put pricing pressure on Cisco. That's not what this is about.

Mike Bushong (@mbushong)


I want SDN and I want it now!


Re: Right on.

Having a controller doesn't immediately mean creating one very large failure domain. And I don't think anyone actually involved in the SDN architecture discussions has been saying that. This feels like unnecessary FUD to me.

First, not all controllers are active in the data path. It is entirely possible that architectures can be resilient to controller failures. Second, most architectures are likely to include redundant controllers. This concept isn't really that new in networking. And third, the likely use of controllers is in a federated (read: distributed) fashion. You won't have one controller to rule an entire network, because of the failure and maintenance domains.

What controllers do that the current distributed protocols do not is provide a global view of the network as a resource. This makes it possible to look at traffic patterns, application requirements, resource availability, etc and make intelligent decisions. The days of managing a large distributed system through pinpoint configuration control are coming to an end eventually.

Mike Bushong (@mbushong)


Oracle and Pluribus team up, flip the switch on Cisco SDN killer


Oracle inching ever closer to Cisco

While I don't think that anything will happen quickly, we are seeing tectonic plates moving about in the IT industry. If Cisco pushes an application-centric infrastructure, how long before they start integrating applications? Similarly but from the other side, how long before the application guys start dabbling in infrastructure?

If you listen to John Chambers closely, he is always talking about Cisco being the number one IT company. His competition isn't just the networking guys.

Interesting to see these little moves playing out. It should make things interesting over the next 5 years.

-Mike Bushong (@mbushong)


Industry execs: Network admins an endangered species


"Endangered species" is too strong

I do think that we will see more devops type roles. But I don't know that it spells doom for all network engineers. I think of this shift a lot like the ERP shift. Sure, you have people who architect across silos, but you still require people with specific systems expertise, particularly when things go wrong. The higher-level architectural type tasks will elevate above specialists, but at the end of the day, you still need someone who knows how this stuff works.

If people essentially let go of all of their specialists, they run the risk of not having them when they need them. You don't need someone who knows how your carburetor works... until you do. If you can afford to take your network to the mechanic shop and wait, then that's fine. If not, then you need to have someone who can cover deeply technical issues as needed.

Let software take the strain off your data centre


Promise of SDN depends on abstractions

[full disclosure: I work at a startup in the SDN space, and previously drove SDN strategy at Juniper]

The discussion of SDN as more than a means of automating provisioning is spot on. If all we get out of SDN is a better managed system, we have aimed too low as an industry.

That said, I thought it odd to talk about OpenFlow. For any of the really cool application-network interaction to happen, we need to settle first on some of the higher-level abstractions. The underlying protocols are perhaps the least interesting thing to settle on.

I would rather see discussions about how to describe workloads, what properties need to be preserved for those workloads, and how we manipulate work loads. I think that those in the OpenFlow camp might prove to be right in picking an underlying protocol, but they will have failed to deliver anything exceptional because they missed the forest for the tree.

Mike Bushong (@mbushong)