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:
- Because the application developers never specified what network services they need, forcing the deployment team to waste time reverse-engineering the environment.
- Because the application teams never took the ownership of network services.
- Because everyone uses a single humongous firewall or load balancer (well, make that two for redundancy) because we don’t know how to manage a thousand small firewalls;
- Because the humongous firewall became the brittle holy cow that you can touch only every fifth Friday of the month at 5:05 (otherwise a crash might bring down the whole data center).
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.
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?
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.
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.
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.
"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 "
Network outages are a thing of the past if we should believe this nonsense.
http://www.crn.com/news/networking/300077381/united-airlines-flight-delaying-network-issues-would-be-fixed-by-sdn-vars-say.htm
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.
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.
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.
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).
http://blog.ipspace.net/2014/01/control-and-data-plane-separation-three.html