Platform as a Service (PaaS) developers work together locally and remotely on developing and testing information systems on different parts of a development system life cycle. If the proprietary network is operating normally, no worries — the developers continue their work uninterrupted. If the proprietary network has not been operating normally, the developers most likely have encountered network latency problems.

Network latency problems

Let’s suppose a team of PaaS developers live chat with one another to resolve system development issues. One day network latency problems surface, and the developers encounter significant delays in sending and receiving texts. They can’t meet the deadline of deploying the information system.

The next day live chat is up and running. The developers are granted an extension to the deployment deadline.

In an attempt to preserve their reputation as a reliable, dependable, and trustworthy deliverer of flawless, custom information systems, they take their network latency concerns to an Infrastructure as a Service (IaaS) network specialist. The specialist who is on the team follows up with an IaaS provider’s network administrator.

The PaaS developers discover too late that the network administrator can’t reroute traffic from proprietary network devices to healthy ones. His view of the network is limited; he can’t see which network devices are performing well and which are not.

To make matters worse, proprietary devices are often not compatible with one another. Vendors leave little or no room for the network administrator to reconfigure the devices.

Network decoupling

The IaaS specialist suggests to the provider’s network administrator to consider software-defined networking (SDN); this option can give the administrator a global view of how the traffic behaves from one network device to another. If he discovers a device is failing, he can use the SDN controller to quickly detour the traffic without bringing down the network.

The controller is an open source application that decouples the control plane from the data plane. It complements network functions virtualization (NFV) that separates network functions from the service provider’s network.

The SDN administrator must ensure the controller is properly configured to:

  • Direct the packets to network devices;
  • Speed up bandwidths for large data sets; and,
  • Detour the traffic.

To tweak the configurations, the SDN administrator first looks northward to programmatically make changes to network devices. He then sends the information southward to an API via the OpenFlow Protocol that the controller uses.

Improper configurations come with vulnerabilities that a hacker loves to exploit (like directing the traffic to the hacker’s website). To achieve a low risk level, the controller should be tested for configuration flaws and then for traffic optimization.

SDN testing types

Here is a list of controller test types you should perform on the PaaS to help you optimize the SDN.

  • Function tests. You begin with a list of controller functions you can test on the PaaS. You will find out if the controller can withstand the stress due to an upsurge in user demand. You can prevent a hacker from bringing malware to the controller.
  • Bottleneck tests. You look into the controller’s bottlenecks and scalability issues. The bottlenecks, if not fixed, can impact the controller, which may result in network performance issues including an outage. A hacker can take advantage of the bottlenecks and clog virtual networks to bring down the entire network.
  • Configuration tests. You set controller configuration settings in different scenarios to ensure default settings are not inadvertently used. You configure where to reroute the traffic in the network when virtual network devices begin to show performance issues. If your organization has two networks, you can connect them via the controller for each network. The configurations for one controller should have different parameters from those for the second controller.
  • Data plane tests. You compare different scenarios of how well the data plane forwards the traffic as the traffic scales up. You make configuration changes to the controller to include a scalability parameter. If the test shows that a parameter value results in mediocre traffic scalability, you change the value in an attempt to improve traffic scalability. Repeat the tests until you find an optimal value (e.g., the traffic would scale well).
  • Big data tests. You find there are no bottlenecks or other network performance issues when the SDN controller is properly configured. You test on the PaaS if the controller can cost effectively speed up big data files by rerouting them to better performing network devices. If the test results show little or no improvement, you need to reconfigure the controller.
  • Security tests. You test if the controller can reject unapproved applications that make malicious changes to network configurations. A properly configured controller can reject users who don’t have proper security credentials to use the approved applications.

Summary

If you want to save time testing whether the SDN controller has been properly optimized, you should consider using a proprietary or open source PaaS as the testbed.