SDN Implementation Planning

The long-standing joke among networking folks is that software-defined networking, having sat on the hype cycle for so long, stands for Still Does Nothing. Yet there is little doubt that SDN actually is taking hold in the industry. Telecommunications organizations have led the charge, but now enterprises are also finding ways to implement SDN to solve distinct challenges they face.

These companies are sharing their experiences so others can learn from them. Successful implementation of SDN in the enterprise requires focusing on use cases tested by others and developing clear plans.

If your SDN implementation plan begins with "we need SDN" instead of "we have a problem which an SDN platform can solve by doing [something]," you will find a rapid path to failure. Introducing SDN into the portfolio without use cases and buy-in from all stakeholders won’t work

SDN challenges

SDN increases complexity. That's a fact. Along with the complexity, you gain a higher-level abstraction. The operational complexities become something we have to weigh as trade-offs.

The ability to support an SDN platform can be a challenge for enterprises. However, this is becoming less of an issue as more SDN adoption and innovation occurs.

Another challenge is that sometimes it's just too much solution. Many organizations do not have the use cases to be able to be comfortable taking on the challenge of owning and operating an SDN platform. This is why the use cases are important to understand.

SDN benefits

There are a variety of ways that SDN is a strong proposition. Here are just a few that help drive its value.

• Consistency through programmability -- Automation is about consistency first, then speed. Using programmatic processes ensures that consistency.
• Visibility and control -- Network management centralized through a common platform and set of protocols is a strong driver for adoption. We can effectively commoditize the underlying physical network infrastructure and work at the control plane rather than interacting with all of the under layers 
• Portability of policies -- With that distributed control plane comes the distributed policy engine to ensure polices are enforced using the higher-level abstraction of SDN. Transitory workloads keep their policies with them as the move.
• Cross-cloud capabilities -- Using the same policies to deliver network security and services across multiple clouds is a powerful use case. This means that the SDN provider becomes a consumer of the northbound API of the underlying network architecture and abstracts away the idiosyncrasies of configuring multiple distinct networking products.

Once we have use cases lined up, we can map those requirements to the logical and physical design of the SDN solution. This is the reason that starting with a vendor product and working backwards to the use cases is the wrong approach and leads to inevitable failure. It's the tail wagging the dog.

SDN implementation tips

Initial implementations without a clear plan will fail at an incredibly high rate; this is well documented. Once you have use cases in mind, here are some tips for a smooth SDN implementation:  

• Find a partner -- You're leveraging a VAR or network hardware provider today. Use those partners to get you up and running; there's no need to go it alone.
• Conferences -- Being onsite among peers who share similar challenges is a huge opportunity to learn. However, if you can't attend in person, many conferences share their session content online.
• Educating your team -- There's no shortage of SDN resources that are either freely available or paid training through classroom experience. Developing an SDN plan with an educated team will greatly increase your success rates.
• Labs -- The value of SDN is that you can implement it using virtual labs, both on-site and in cloud-based environments. Most SDN products are available in a test lab environment thanks to the fact that software is portable.
• Look to your peers -- Just like with your vendor partners, look to your peers in the IT community and also your business peers. Knowing that other organizations with similar use cases are using product X for SDN means that you may have value and success more quickly.

The benefits of SDN don't come automatically. The S in SDN can also stand for sweat equity because of the effort needed up front. The good news is that others have forged these paths for us and shared their knowledge.