Our President and CTO, Jamie Doherty, recently spoke at one of our Lunch and Learn sessions about Software-Defined Networking (SDN). Here are some of the highlights from his talk.
Software-Defined Networking or SDN is a number of technologies wrapped up into a tidy package. It features Software-Defined overlays or controllers that are separate from the underlying hardware, which results in a network that gives you faster, automated provisioning and top-level security. In the past, we went for high availability and redundancy, and we left security to deal with later. We can’t afford to leave security as an afterthought. Network routers usually only know about neighboring network gear, but a SDN that’s properly configured can control everything, whether that means changing policies or simplifying configurations across the board. Basically, SDN improves your network performance and monitoring across your data center, cloud, SD-WAN, and SD-LAN, or campus infrastructure. SDN is each of these technologies combined.
Security is the number one motivator for any Software-Defined solution. In every piece of equipment, a company buys, it strives to cover security, performance, availability, flexibility, identity, automation, manageability, and visibility. To find each of these features in a single product, was always ideal in theory, but very difficult to achieve in practice. Enter SDN. SDN delivers the key features and functionality your organization needs, more specifically:
This is the #1 motivator to get any Software-Defined solution. Ransomware attacks occur every 14 seconds. This is almost as often as a new human is born, which happens every 7 or 8 seconds. Companies were being hit a few years back for ransom amounts around $7,000, but nowadays attackers are taking advantage of insurance policies to ask for much higher payouts. Insurance providers are actually capping payouts for ransomware threats, often well north of $100,000, so you can no longer just pay up and move on. With SDN, you can now have the security policy you want.
The second reason to adopt SDN is performance, because it can do things for you that you wouldn’t do yourself. These include better multi-pathing, better availability and failover, and better management of frame over-sizing, for example. SDN does it all automatically with a bandwidth command, because it is pre-programmed with features, redundant paths, and automatic optimizations.
Then there’s visibility, which your CEO thinks you have, but the reality is most companies have only 25% or 30% across their networks. This doesn’t give you the east-west leverage you really need in order to know when someone goes home and installs an application that isn’t clean. With SDN, you can get this kind of visibility without impacting the user experience.
In terms of availability, MPLS is on the way out. At around 1% of AT&T’s services, it’s still going to be used for a long time, but it’s not required and the technology really only did two things: guarantee bandwidth and guarantee priority of service. SDN’s entire job is to guarantee bandwidth and priority, and it does much more—and more natively—than MPLS can.
Ideally, you should adopt SDN now, especially if you’re implementing a security initiative it’s a good time to adopt a software-defined data center or LAN architecture. For a Software-Defined WAN architecture, doing it during renewals or expansions is another great opportunity to get it into your environment. The Meraki cloud is super easy to work in, so if you’re a Meraki customer and you need to add access points, the SD-WAN is a cinch to add and so is the SD-LAN. Even if you don’t need all the features now, it’s still good to buy the newer technologies available to you and to turn them on when you need them.
There’s no requirement to wait for a full overhaul or full data center takedown to adopt an SDN component, either. You can do it as a brownfield project, here’s one example:
If you have one PCI-based application that lives in VMware and runs on four of your 31 hosts. By getting SDN for those four hosts, you can get into the SDN environment, apply the protections required and remove an entire component of PCI without taking it all down. Best of all, it doesn’t have to be a massive investment to take advantage of some SDN architecture and quickly reap the rewards.
In almost every environment today you can find a way to make SDN a part of it, and choose between managed, self-managed, or co-managed options. Meraki is a self-managed device at 10 sites, and even at 30 sites. When you get to 60 or 100 sites you might need help, it’s entirely up to the customer.
It’s essential for you to decide whether your organization is going to be cloud-based or on-premise in the future, so you can make the right choices when moving to SDN. Cloud smart differs from cloud first by focusing on finding ways to adopt cloud effectively to meet your company’s individual needs, instead of simply deploying the technology any way you can. The thinking back in 2011 used to be cloud first, even for the federal government, but that has now shifted to cloud smart and we’re in agreement with the move. When you’re talking about the SDN world, people are still going to connect to wireless, to access points or to switch ports, but if they connect to backbone switches, SDN doesn’t live there yet.
The bottom line when it comes to SDN is that it’s designed to be easy. Everything you want is right there, and it comes with a ton of options. In the past, we’d spend half a day just trying to get the network configuration done. Now, the equipment’s already pre-configured, it gets shipped, you plug it in on arrival and all of a sudden, everything’s up. It’s huge.
Get a free assessment today to determine how well your technology supports the evolving requirements of your business and customers.
