Learn NFV Fast and the Easy Way!


Well ! I have done all the efforts and made concepts simple through the Free NFV Mind Map. Get it now before I take it off. Plus get free updates to my blog.

Autonomous SD-WAN by CloudGenix- My Analysis

I attended TechField day event( February 12 to 14th, 2020) in Silicon Valley US as one of the analysts, where we attended some very informative presentations from the participating networking vendors

Among those presentations, the one about CloudGenix’s SD-WAN, particularly, caught my attention, so I thought to write about it. (Please see full disclaimer at the end of the article)

Cloudgenix is a startup in SD-WAN space established in 2013. It is based in San Jose, USA. In their presentation, they talked about their SD-WAN solution that includes AppFabric and CloudBlades

Of late, SD-WAN has become a crowded space, Vendors have been gradually losing competitive advantage owing to commodity offerings.

So let’s see how CloudGenix is doing things differently for its customers.

Among the many features that their product offers, there are two features that I would like to discuss- “Application driven policy” and the “cloudBlades” feature.

Before understanding the Application driven policy, let’s see how traditional vendors deal with the forwarding of the applications which in fact the industry calls “Application-aware routing”

Application-Aware Routing is good, but is it sufficient?

Let’s face it, every SD-WAN vendor supports application-aware-routing in one way or the other. In other words, their SD-WAN edge device ( at customer site) can select a WAN path ( enforce a path policy), based on packet/transport layer metrics like jitter, delay, and packet loss.

This enables forwarding applications (like youtube, Netflix, Google) to the preferred WAN link based on user-defined policy for transport metrics.

In my opinion, this kind of approach is not sufficient for a few reasons:

Firstly, this packet centric approach assumes that transport at layer 2/3 is the only source of issues for the bad performance at the application layer; this notion itself is not always true. On the contrary, transport can be bad, at times, yet application can perform well ( for example netflix may perform well even if latency is high as long as the bandwidth on the link is sufficient). In short, the actual user touchpoint is the application rather than the transport itself.

Secondly, this approach tries to solve the cloud connectivity issues with tools designed for connectivity between a branch office and headquarters. With the majority of applications moving to clouds, the application performance tools require a far more sophisticated approach going beyond the simple tools of metrics designed for point to point links such as branch office to HQ connectivity.

Lastly, given the fact that applications are hosted in the cloud, the packet centric approach would call for inserting a second box ( in addition to the one at customer site) at multiple locations in the clouds to give accurate metrics on transport and hence may be CAPEX intensive approach for small customers.

So, there must be a better way to forward applications on WAN links !

“Applications-driven “rather than “Packet-driven” is preferred and closer to user experience

CloudGenix handles this issue in a different way, yet with a single box at a customer edge site. This may sound counter-intuitive but here is how they do it. This is a shift from the packet paradigm to the application paradigm.

This image has an empty alt attribute; its file name is image-1024x516.png

The edge device runs an intelligent engine that performs analysis on the application layer to see how an application is performing. While they can do the packet layer measurements also, but their differentiation is the rich measurements at the application layer to assess the real application performance. Then the application is routed to specific WAN link on KPIs such as transaction time, server response time, MOS score, CODEC. All this in real-time at the edge.

So this way they can control traffic path at a more granular level and closer to the actual user experience rather than transport-level KPIs such as loss, latency, and Jitter. All this is done automatically at the edge device, that’s why CloudGenix calls it “Autonomous SD-WAN” also.

In other words, if my SAAS application in the cloud is working fine even on a bad transport link, do I really care about latency, packet loss and jitter ?

And before you jump in to tell me that some SD-WAN vendors do offer similar rich analytics at the application layer, the ones I know, need cloud-based controllers or cloud analytics engine, which is not as real-time as that offered by the device itself and additionally make the solution expensive through the add on option. ( if you know of any vendor that does it similar to CloudGenix, please leave a comment down)

Best of Breed through Cloud Blades

The second feature which caught my attention was “cloud blades” which give seamless integration with the best of breed cloud applications.

This image has an empty alt attribute; its file name is image-1-1024x569.png

I can understand that being a small company, CloudGenix has focused on its core strength which is SD-WAN and bring the best of breed solutions for other VAS services in the cloud such as security, unified communication, multi-cloud through its partners like Palo Alto, ZScaler, Zoom, Webex, etc.

This, however, would be in contrast to the all-in-one solution approach where security vendors have started offering SD-WAN and vice versa ( thanks to Gartner SASE). But this approach seems more open and gives flexibility to the customers to choose from the best of the breed.

This is possible through the use of cloud blades which are the integration points ( not a second edge box) in the cloud which helps seamlessly integrate the customer edge box with the cloud VAS services through the use of APIs.

Thanks to these cloud blades the upgrade of the solution is easy and seamless. Once a cloud VAS partner upgrades its application, it just needs to modify/upgrade the integration points without upgrading the customer edge box.

These cloudBlades are the abstraction points between the edge box and the cloud applications. This is quite different, as my understanding is that the traditional SD-WAN edge solutions that directly integrate with Cloud services would dictate upgrading each edge box at the customer site whenever new features in the cloud need to be supported.

Recommendations for CloudGenix

While the path selection policy based on the application awareness is a good strategy and the one which is recommended considering SD-WAN provides connectivity to applications which are hosted in clouds, it what would be nice to have an additional option to use the transport metrics such as packet, jitter, and latency as the policy criterion and give an option to the user to choose from.

A simple use case would be a service provider offering its own MPLS link as a simple backup to existing MPLS link of a customer ( when the link is from another provider). In such cases the provider may offer a very simple way of switching between two points based on transport/packet metrics and do not worry about the application layer metrics.

I don’t see any issue why this feature cannot be implemented easily in the solution considering that the system already can provide packet/transport-level metrics. Upon discussion with the vendor, I learned that such capability is possible through the use of the custom application.

My second recommendation for CloudGenix would be to look into certifying the edge device to be MEF SD-WAN compliant solution as this would open up the opportunity for the product to be deployed in managed service providers that are looking for MEF compliant solutions.

 Disclaimer:

CloudGenix was a presenter during Networking Field Day 22 in Silicon Valley, CA USA among many other presenters organized by Tech Field Day ( 12th to 14th Feb, 2020) As an Analyst in Networking Field Day 22, my travel and lodging expenses were covered by Tech Field Day ( the organizer)  for the duration of the event. Vendors did not ask for nor were they promised any kind of consideration in writing of this post. My conclusions here represent my own thoughts and opinions.

 

1 thought on “Autonomous SD-WAN by CloudGenix- My Analysis”

  1. Pingback: Autonomous SD-WAN by CloudGenix- My Analysis - Tech Field Day

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.