The primary difference would be that, unlike today, network visibility will no longer be a separate part of the network but would be a service on top of the network infrastructure. This transition process will need a while because this service approach only works on programmable networks (SDN) and the existing legacy networks do not support this approach.
The challenge for visibility in Cloud environment:
Multiple 10.000 physical servers, multiple 100.000 virtual servers and multiple 1.000.000 instances require entirely different switching concepts and also different visibility approach. In such a network environment, the routing is done on tenant id, client id or in application layer and only ip is not usable because the instances are moving between virtual/physical servers.
The routing is not between physical servers but between applications. Due to the large number of servers and endpoints, physical tapping is not a realistic approach. This involves enormous cost and lot of management effort. Another issue is the massive amount of data, and legal issues will not allow a full capture approach.
The solution is smart filtering/routing to feed the traffic to the relevant analytics tools. This must be done inside the network infrastructure because only there the dynamic filtering/routing information is available in real time. Currently, there is no switch hardware available to perform such task. This application is possible only with programmable switches, hardware or pure software based.
As part of our future development, Cubro will offer the EXA32100 platform in combination with Sonic NOS such a solution. And this confirms that visibility as a service will not be only software based. Software is needed to control the visibility service but, we will require powerful hardware, and security wise a trusted platform to handle the massive amount of traffic (See host controller image).
The visibility management will be a part of the network orchestration or will have access to it to get routing information in real time. The other part of this visibility approach is the hardware related part which performs the data filtering and packet forwarding in real time. The challenge is that this application must share the resources with the existing switching/routing without interfering. In order to make this possible, there needs to be hardware resource to the switch, and the visibility application needs to have access to the traffic on a deeper layer than the switching application. This requires an excellent designed NOS.
This is the reason that Cubro is currently porting the Sonic API to all new G5 units. This feature helps to integrate the units in existing networks and use them also as visibility platforms. Sonic invented, my Microsoft has some brilliant mechanism which allow this approach. The visibility application runs in the layer below the typical switch application and the hardware layer. This gives full access to every packet. In addition, user gets realtime information from the switch application to do realtime smart filtering.
Due to this reason, Cubro is investing in new advanced platforms which can do much more than regular L4 silicon. We see our products in the future as a part of the network infrastructure, which do switching / steering as part of the programmable network and offer advanced, up to L7, functions for the visibility service. The idea is to integrate visibility features in programmable switches. This is not a span port - this is a real application with advanced filter and modification feature.