1. Controller Architecture: Distributed vs Centralized

 

How are you defining your controllers or controller clusters; are they centralized?

 

A bunch of new SDN vendors came up with their own definition of controllers; some of these vendors just want to use the term to get into the SDN space without a real controller construct in their architecture. The importance of the controller is key; it’s the heart of the SDN architecture. The Controller is like the brain of the SDN network; a single point of management, Policies, configuration and maintenance. There is nothing like a controller-less architecture in SDN. Note, the interaction between the Controllers and the nodes in the SDN Fabric may use different protocols; some proprietary some open like OpenFlow, OVSDB etc.

 

The key here is to stick to a standard based approach so as to make sure you are not getting into vendor lock in. The popular protocols used by SDN Controllers to communicate with the nodes are OpenFlow and OVSDB. Others protocols that are used by some vendors for SDN Controller are YANG and NetConf.

 

Controller Clustering Concept differs from vendor to vendor; while some believe an Active Standby Controller will suffice; others go with a 3 or more node (odd number) clustering model for split brain scenario decision making simplicities. While both approach work great it depends largely on how the SDN Fabric gets deployed. In the later approach we have seen some vendors even separate the controller functionalities and dedicate nodes in the cluster for specific functionalities for scale and resiliency.  

 

 

2. RESTful or Other Published APIs

 

How interoperable is your SDN solution with some of my other applications?

 

Can they seamlessly integrate? If so, what are the published APIs I can use to integrated it with my home grown or my other Open Source applications?

 

The typical response to this should be yes we use RESTful APIs and we are 100% REST complaint which means anything that is do-able through the CLI/GUI can also be done using REST APIs.

 

REST (REpresentational State Transfer) is an architectural style, an approach to communications that’s plays a key role in web development. The use of REST is gaining fast momentum as compared to a more heavyweight SOAP (Simple Object Access Protocol) style because REST does not leverage as much bandwidth in comparison, which makes it more optimized for Internet.

 

 

REST'S disaggregated architecture provides lighter weight communications between producer and consumer makes REST a popular building style for cloud-based APIs which is used by some of the industry heavy weights like Amazon, Microsoft, and Google.

 

REST will continue its upward growth as customers seek to provide open and well-defined interfaces for application and infrastructure services. The fast adoption of public and private cloud is catalyzing the demand, and will continue to do so in the future.

 

So 100% REST API compliance is a key in satisfying the interoperability strategy for customer application.

 

 

3. Cloud Management System Integration

 

Does your SDN solution allows me to integrate with my other Cloud Applications/Management Tools to provide an integrated approach?

 

This is one of the most common ask you get from almost all the customer who:

1. Have a good amount of understanding of the cloud and what it takes to build a real world cloud initiative
2. Have a have a real world implementation plan for their internal private cloud initiative

Most of the customers have already an orchestration initiative in which they are either looking for a home grown alternative to tie all the silo-ed solutions together or looking for a solution from their SDN vendor which provides integration with Cloud Management Systems to stitch a single Fabric for all different tools to work as a single solution. For example the SDN controller to provide north bound interfaces or plugins to integrate with tools like VMWare vCenter, OpenStack, CloudStack etc. This is a key requirement in providing a state synchronization between all tools that make up a total solution.  

 

 

 

4. Operation Simplicity

 

How best can we operationalize the solution you are trying to sell me?

 

This is a key question to ask your vendor. Some vendors of course, revert to ways to make it complex with the terminology and operational processes to make it look like a sophisticated solution. Gone are those days; the whole promise of SDN is to make it simple to setup, optimize and operate. Customers are looking for solution which is easy to operate and they really don’t need multiple CCIEs in their networking team to manage and maintain a SDN based solution. The vendors not only need to support CLI, GUI and APIs but they need to make sure the configuration parity between each of these access methods are 100% i.e. everything that you can do from GUI can be done through the APIs/CLI and vice versa.

 

Operational simplicity makes a solution more viable form the customer standpoint to move it from PoC stage to PILOT to Production. Customers are asking vendors for best practice operation guidelines as one of the evaluation criteria early in the process. The key is make it simple to understand not only with the setup process but all with the term and terminology the vendor is using so as to make sure it’s easy to translate internally once the project from the PoC stage to Production for the operations team to understand and run it with; most of the time the two teams are separate and operations team don’t get involve when PoC kicks off.

 

Keep it plain and simple and you will surprised how welcoming it gets from the customer. If network administrators don’t have to spend time figuring out the STP or LAG complications and these are something the Fabric can take care of by itself; it will give the networking guys time to focus on the more strategic things rather that configuring repetitive constructs throughout the different nodes in the Fabric.

 

 

5. End to End Analytics with Fabric wide Visibility

 

How can you provide me visibility into the Fabric? How can you help me correlate between overlay and underlay networks? How easily can you help me pin point the root cause of an outage?

 

Analytics is more less a standard now a days with any production ready SDN architecture. Analytics provides a window into the health of the SDN Fabric and sometime is instrumental in detecting issues before thy really happen. Analytics provide a correlation between your overlay and underlay networks and help alleviate the long hours of troubleshooting trying to figure out the connectivity issue in the overlay network for a route leak in the underlay network for example.

 

 

Analytics is not just statistics on packet count; most of the vendors you see provide some fancy charts spitting out packets count statistics; Analytics should be able to predict latency, detect a loss-y path, predict an issue which may run into a major problem down the line. Machine learning is getting a lot of traction in the Analytics industry especially when you talk about predictive analytics and self-healing networks. Vendors are promising the utopia of self-healing networks through machine learning. Analytics should be able to monitor application behaviors across the whole SDN network. Map dependencies and provide simplification to migrate software-defined networking (SDN) and the cloud. It should speed disaster recovery using machine learning to build accurate and dynamic white-list models in hours for zero-trust security.

 

 

6. Support

 

How is your Support team structured? Is it out-sourced? How are you going to support my global organization, what’s the follow the sun strategy?

 

Last but not the least, support is one of the key factors in deciding the optimum operational model especially for companies with presence in more than one country or continent.

 

 

While price and features remain important to providers, according to a survey 82 percent of those surveyed called vendor tech support "a leading competitive differentiator" this year. That support can be through the vendor itself or outsourcing, though 61 percent of hospital workers said they want direct support, and 79 percent that use third-party outsourced tech support are unhappy with quality of the services.

 

Support can be a key evaluation point, a key reason for a customer to choose a particular vendor over others. Even for products aimed at technologically literate users, knowing that someone is on hand to answer questions or fix bugs can influence the decision to buy or sign up for a PoC. Users will always need support even if vendors claim to have a bulletproof product and the most excellent tutorials and documentation, and someone will find a way to break it or just not read the information staring them in the face. Vendors should expect to offer support and build it into the price of their product and their support systems should also help you track the amount of time being taken up by support, so that you can plan for future requirements.

 

 

Conclusion

 

As the SDN provider market is getting more and more crowded and every vendor is promising the utopia of simple and an integrated solution; it’s important to understand and grade the vendors on all of the above metrics. A vendor may excel at one or more metrics while the same vendor may lose on others. So creating an extensive evaluation matrix and grading each vendor you are doing a bake-off with, is key. It will help you to make the right decision and reduce the operation risk in going from a legacy 3 tier networking solution to a best of the breed SDN-based networking solution.