Friday, April 1, 2016

Network based APM

We've all been hearing quite a lot about Big Data and what the possibilities are associated with it.  Ultimately, the discussion comes down to, how to get data and how is it made relevant.

Software Defined Networking is making it possible to separate the control plane from the data plane.  The control plane information really isn't all that interesting, unless you're debugging an issue.  But the data plane quite literally contains all of the relevant data associated not only with the application, but how it operates.  

Assuming that the applications relevant data is also stored somewhere, Big Data would be able to produce interesting information from the stored data.  But what about the operation of the application?  User experience?  SLA?

The scenario for elevating the value of the more transient aspects of network communications related specifically to an application have been around in networking for quite some time.  At the most base level, packet counters exist on a host-by-host reading from within the connecting switch.  Sflow and Netflow are more recent additions to look at the communications on the network.  For about as long, and significantly more granular and expensive, SPAN or tap to a more granular and extensive analytics engine produce Application Performance information.

Consider this, with the addition of container based technologies, it could be possible to create a standardized mechanism for collection of developer based application awareness from within software defined networks.

Similarly, with sufficiently advanced and capable CPUs, it may also be possible to run the analytics from within the switching platform.  We can table this for now, but the possibility is there.

The model could utilize a particular aspect of the developer's framework.  Java or .Net that, from within the application, makes a call to a switch to start an analytics process. 

With the application making calls specifically to the network infrastructure, it could possibly request the switch spin up a collector in a container on the switch.  It could also make a call to the switch to determine which VNI is being used to transport it's data and tell the collector to extract the associated TCP information or deeper packet information from the application transport.

Once you have TCP or deeper packet data from the application, analytics could be applied to develop specific awareness of the application that could, potentially, become the basis for application performance.  With the ensuing granularity of deeper inspection, both User Experience and SLA could potentially be derived from the mechanism.  Not to mention, the possibility of extremely specific dev based tests on the application to determine things like fitness.

APM in an SDN network
Assuming the network was already established, in the simplest of these methods, the application would:
  • make an API call to the switch to determine which VNI it is associated with
  • make an API call to the Switch to spin up a collector
  • issue a TEST case for the collector to capture from within that VNI
  • send the captured data to an analytics engine to process for value
In more general testing, and assuming applicable path information, bandwidth and CPU capacity, the application would make a similar request to the control plane to issue the test case against its entire path.  It could create capture on deeper packet information.  Perform continuous Application Performance Management.  Ultimately leading to extensive SLA level information about the application.




No comments:

Post a Comment