SDN Will Not Solve Real-Life Enterprise Problems

It’s hard to visit an IT journal web site without stumbling upon an SDN fairy tale. Here’s another one:

The idea is to cut away the manual process of setting up new firewalls, load balancers and other network appliances, and instead open the door to provisioning a new network infrastructure within a few minutes.

And why exactly is it that you can’t do that today?

How about:

While new technology might help you get the job done quicker, no amount of shining magic and unicorn dust peddled by vendor marketers will solve your problems until you realize it’s time to change the processes and responsibilities.


  1. Don't we already have to know how to manage thousands of firewalls in order to implement Internet VPNs and now SD-WAN (e.g
    1. You wouldn't believe how many people pull all the Internet traffic through the central BFF (Big Fat Firewall) instead of using local Internet exit ;)
    2. Surely it's a massive issue to manage and control the ACLs on the local internet access routers (As surely a FW at each site is not realistic) with existing tools at any kind of scale? And that's before you even consider internet access being policy based rather than just unhindered outbound 80/443.

      I "own" a 300+ site WAN with your central BFF exit providing direct access for very specific use cases with general internet access via Proxy (McAfee) that enables AD group linked policy control so fairly painless once up and running.

      I know there are cloud based proxy services (Our laptops drop back to that control when off the corporate network) but the controls are significantly less fine grained.

      Just feels like I am missing something or people running that model have made comprises I'm thinking of as deal breakers?
    3. My org pulls thousands of sites internationally through two DMZ's. All the edges are unique little flowers, and no one wants to be the person that missed an ACL at a remote site and got us in the news. This policy is changing very slowly, and all the breaches in the news don't help.
    4. The reason for not using local Internet exit isn't the firewall (in my experience anyway), it's the proxy server. I haven't a full-featured cloud-based proxy server at any price (say, something that compares feature-for-feature to Cisco WSA; Cisco's own cloud proxy doesn't), and the non-comparing ones are already overpriced.
  2. Perimeter FW or even distributed virtual perimeter concept vs. many local logical FW concepts is the debate today.

    I agree with your post though. However, having been to many IT shops there are some where, I hate to say it, the network group acts like a good fellas gang and they are very difficult to work with the rest of the organization(everything is drama). Now in my travels this is the very exception but once in a while I encounter one group like this and I wonder if on the broader scale if this is becoming the norm. Thus, no wonder the enterprise want's to marginalize the network dept. away and move it to the developers for more control and cooperation and SDN is the dust to do it. Just an observation.
    1. To be fair, this "everything is drama" thing didn't come up out of thin air. Everything is drama because it is typical that nobody talk to the network until 4pm on Friday for a midnight implementation of an app that requires major network work. Everything is drama because every project assumes that network will solve the issues of badly written code. Everything is drama because every time a new piece of complicated infrastructure is put in place to resolve bad code, it makes thing more likely to fail. Everything is drama because, as Ivan often points out, the network is not like utilities, because if it was, none of these applications would work.

      The network is expected to be something that is simple and efficient, but at the same time provide all sorts of services and nerd knobs that points in the other direction. Those things don't mesh. That's why everything is drama.
    2. I agree with you Simon there too. I have been in the debates of " Do you architect your network around your application or architect the application around the network". I have seen the poorly written applications and the network was blamed and have had to prove otherwise, many times. It is true yes the network WAS the utility but has become more complex to change with the business and as a noted IP author mentioned in an SDN video "the network is in the way" is what enterprises view it as.

      As a network vet of almost 30 years I heard the old mantra of IT has to become part of the business, not an expense, the network group has to become part of the business not an expense. Here is the kicker, maybe at this point in time some enterprises and network groups see SDN as that opportunity for the network team to become part of the business(with the developers etc) to help grow and guide the business and not just as another expense. However, there are some who will see SDN as the opportunity to remove/marginalize the network group or reduce that level of "in your way" or "expense" . Obviously there is no one size that fits all.
  3. I don't know if SDN is a solution to real-life enterprise problems but there is a need for change. The cost to acquire and manage server and storage architectures has declined over time while networking stays stubbornly expensive. Maybe it's because a network engineer has to deal with no less than five different OS, CLI, and management platforms to deal with ever-changing application requirements. SDN is attempting to standardize all of this into a single programmable architecture.
  4. Internetworking and its management is still a research project and there is a lot more research left to do. Things haven't got that much better since Douglas Comer wrote this 15 years ago:

    "During the early 1990s, those of us who were involved with the Internet marveled at how large an obscure research project had become."

    Excerpted from "Internetworking With TCP/IP Vol I: Principles, Protocols, and Architecture , Fourth Edition , DOUGLAS E. COMER "

  5. Don't you guys realize SDN will solve everything ?

    Network outages are a thing of the past if we should believe this nonsense.

    1. Unfortunately so far the SDN evangelists failed to invent the cure for stupidity and fat fingers ;))
    2. I don't think I can take that article seriously. I think they interviewed a salesman and some of his customers who can't really explain what happened and how the secret sauce he wants to sell you will really fix things.
    3. @Ivan, SDN may not solve stupidity but it does, to some degree, solve the "fat finger" issue. Some SDN solutions automatically configure interface characteristics (we all know that) and at the same time self label, so that vSwitch connected to the vNIC/pNIC labels the physical interface on the device and at the SDN controller. All learnt and discovered through automation.. This isn't earth shattering, but it is a step in the right direction.
    4. Let's rephrase that into "SDN (or any other network services- or cloud orchestration system) gives you fewer chances to apply fat fingers" and we're in perfect sync ;)
  6. SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

    However, if you truly want to prevent what happened at UA, the exact opposite is needed. Less config. Less knobs. Less tweaks. Less "smart stuff" invented by indivuals or indivual customers.

    What you want is equipment that doesn't need any configuration. So nobody can make mistakes. Or at most very very minimal configuration. In stead of thinking how you can add more configuration options, protocols and knobs, the industry should try to *remove* as many config commands as necessary.

    Network engineers do a lot of smart stuff in their networks. I am convinced that some "AI" (just some smart algorithms) could do a better job. Is it necessary to configure all those time-out values ? Or could a router determine what the best value would be ? I bet half the configuration commands in today's routers could be removed.
    1. I don't know that it is a good thing if we have network engineers or your average dev "tweaking" routing algorithms. I know my own coding skills are severely eroded and none of our devs understand networking at all.

      Currently routing protocols, in my opinions, are well-behaved and robust, and have evolved more or less organically. I'm sure quite a few sdn solutions use them under the hood too.
    2. "They will be able to program their equipment themselves" exactly!!!
      The big difference is if you program your app and make a mistake only the app/users suffer(depending on app) if you take this approach to the network everyone could suffer from one mistake, and I am not referring to a fat finger type mistake.
    3. I'm sorry I was not more clear. My response "everybody programming their own network is gonna be awesome !!" was sarcasm. Sarcasm on the Internet never works, unless you use a lot of emoticons. I forgot. I don't believe that many companies will have the time, money, expertise or confidence to truly program their equipment. And the ones that will attempt will run into some real troubles, if not only because of "fat fingers".
  7. If we don't trust the application deployment teams with "mls trust qos", and we have complex policies to mark packets, why would we trust them with programming the network?
  8. SDN was invented so that companies can sell some new, and equally expensive boxes...nothing more nothing less. We all know that management needs to change stuff, or they're not doing their job, execs need new ideas on how they are going to cut costs and make more money to give to the media so their companies share price goes up.

    Server admins/windows admins/and omg wtf are you thinking software developers running the network is laughable...I literally start LOL as soon as I even think about this! I've been hired to fix simple networks with just a few switches and a firewall or router that a server guy did and screwed up...I can't even imagine a complex DC or WAN environment that has multiple overlay networks running on top of it. Even if they had a tool that builds it automatically what's going to happen when something breaks, and they need to troubleshoot networks on top of networks, that ride over the actual network (GRE or VXLAN over MPLS over L2/L3 network).
    1. "SDN was invented so that companies can sell some new, and equally expensive boxes" - that was phase II. It all started with a few huge cloud service providers trying to (A) get features custom-written for their environment or (B) squeeze suppliers' margins. The first phase worked really well (or not):
  9. Im probably missing the point here, and maybe have totally misunderstood the whole SDN thing (dont get me wrong, i understand how wonderful its going to be having SDN magic datacentres and glorious pixie dust IWANs), but I still dont understand how SDN is going to fix the plethora of broken applications I work with day in day out? Have i missed something fundamental? should i go back and read my CCNx books? I just dont get it. It just feels like another layer to work with and another set of workarounds to my broken apps...
    1. You're not missing a point. We do need something that will help us manage our networks better, but most of the promises made by SDN evangelists are totally meaningless.
Add comment