5 comments:

  1. Anonymous 17 July 2015 20:03
    Probably the most pragmatic view on the DevOps / SDN hype I've read yet.
  2. Henk 17 July 2015 23:29
    I don't get this guy.

    So Oswalt doesn't like Big Fucking Things. He wants the Unix Philosophy. What's that ? Firstly it's the approach where you build a lot of small programs that act as building blocks for the user. And then the user can glue those block together and build the system he wants. Secondly, all the other guidelines in that philosophy are about writing code.

    So what I get from that is that Oswalt doesn't want a Big Fucking Thing. He wants building blocks, so he can glue them together and build his own system.

    Isn't that what everybody had for the last 30 years ?

    Network design consists of a *huge* pile of building blocks. Physical blocks, like routers, switches, load-balancers, firewalls, application-gateways, dns-servers, you name it.

    You can take this even further. Network design has even more non-physical blocks. Like 4 different routing protocols to chose from. Plus you can misuse BGP in all kinds of filthy ways if you want to. :) Different bridging protocols (3 linkstate bridging protocols alone !). Different tunneling protocols at layer 3. Or at layer 2. A dozen different VPN technologies and protocols. The DNS. NAT. There are hundreds of building blocks already.

    There you go. There's your pile of neat building blocks. Go and have fun.

    I thought one of the reasons people wanted SDN, is because they wanted to deal with "the network". Think about "the network"'s performance, "the network"'s robustness, the service that will run over "the network". They didn't want to deal with 100s or 1000s of individual boxes. They didn't want the distributed config and troubleshooting nightmare anymore. They wanted One Big Fucking Thing. So they could think and deal with just one thing. And keep a sane mind.

    So what is ? I don't understand it.
    Just curious.
    Replies
    1. Anonymous 20 July 2015 16:21
      From an engineer's point of view, the whole Big Flowering thing gives me a network made of a lot of building blocks together in a configuration that should be 'optimal'. Only 1) it's not optimal for the particular network I need it for and 2) if one of the building blocks breaks (which it will inevitably do at some point), I'm stuck with a premade solution that I can't troubleshoot.
      It *could* make my job redundant: just call the prefab manufacturer (vendor) and let him deal with it.

      Oh wait, I almost forgot. 4 hour SLA time just to pick up the ticket, 15 service desk guys not getting it, escalation and finally some engineer that was involved in the prefab process telling you it's a bug and we'll research it. No there's no way to work around it, it's all prefab, remember?

      For me, SD was invented to work around the problem "we're unable to communicate properly with the network engineers" so it gives an alternative that will work right away, or so is claimed. I'll leave it in the middle who can't communicate properly here: managers and customers aren't always clear about what they want, engineers however need to learn to ask the right questions and understand what they're providing to them.
  3. Unknown 19 July 2015 17:49
    Networkers want building blocks to build networks. Everyone else who need networks to connect up their applications and users want one big flowering thing. Every discipline above networking including the network engineers boss wants the network abstracted away. In my opinion networkers and their vendorsmshould be building transport networks and everyone else should be building overlays.
  4. Timothy Brown 29 July 2015 17:14
    Henk said:

    Network design consists of a *huge* pile of building blocks. Physical blocks, like routers, switches, load-balancers, firewalls, application-gateways, dns-servers, you name it.

    --
    That's not really true. Yes, those are building blocks, but at a larger scale than what Matt is advocating for. Think about the number of times you've bought a switch from a vendor, or a router, which had feature X but not feature Y, when the best device for your application would be feature X + feature Y. This is a very common case in service provider networks and is also common in enterprise networks. The devil in the details is "positioning" and most vendors would like you to buy two boxes rather than one. The cost for development of a feature tends to be born by individual product teams who don't work collectively towards a shared set of goals. The situation is improving, but it's not improving fast enough.

    Matt's conjecture seems to be that if you're going to give me feature X, then give me feature Y as well but let me choose where to put them. His argument is that it's not up to the vendors to determine whether or not I get feature Y in my data center switch; it's up to me as the customer. And that makes total sense.
Add comment
Home
Sidebar