SD-WAN: optimization, security, globalization

Max Clark talks with Aryaka’s CTO and Co-founder, Ashwath Nagaraj about the actual impact of SD enterprises, how their product has evolved to support their customer’s needs, and the so-called “Achilles heel” of SD-WAN.

Episode Transcript:

INTRO: [00:00] Welcome to the Tech Deep Dive podcast, where we let our inner nerd come out and have fun getting into the weeds on all things tech. At Clarksys, we believe tech should make your life better, searching Google is a waste of time, and the right vendor is often one you haven’t heard of before. 

Max: [00.18] Welcome to the Clarksys Tech Deep Dive podcast, I’m Max Clark and today I’m with Ashwath Nagaraj and Syed Ghayur, so Ashwath is the co-founder and CTO of Aryaka Networks, and Syed the VP of Global Engineering for Aryaka Networks. Guys, thank you very much for joining.

Syed: [00.35] Thanks for having us.

Ashwath: [00.35] Thanks for having us.

Max: [00.37] So, Aryaka Networks is a SD-WAN vendor, you fit in the SD-WAN space, as it’s now called in the marketing terminology, but give me a little more detail about that… How do you actually fit, what is the problem you’re approaching, and what was the inception idea for Aryaka?

Ashwath: [00.54] So let me take that… Let me go back to 2009 when we started the company, it’s probably easier to play it out from the beginning, to see how we evolved into it. We entered the market in 2009… We looked at good, high-quality WAN, as deployed by enterprises that had global manufacturing and so on and so forth… They were using MPLS, the best of breed network, they typically had a RiverBed or a SilverPeak box, you know, set of boxes to make that experience of using the global network better. But, they were just about in transition where they looked at it and they said, “We’re now starting to move some applications to the cloud, and we’re trying to move some compute to the cloud, how does this shift?” And that was really where Aryaka was born. We looked at that transition and we said, “SOmeday, there’s going to be a new network, and that network’s going to have everybody connecting to everything seamlessly, but the difference being…” There’s going to be two parts. One is going to be the cost sensitive people, who are going to not worry too much about productivity, and that’s going to be a really low-cost network, and the other extreme are the other set of customers – the enterprise customers – are going to want the same application usage experience around the clock, as they have today, and we have to provide the same thing. So, that’s how we came up with this concept of building a core network, which was a high quality, layer two base, point to point links and so on, between points of presence, and have basically WAN optimization embedded into that – RiverBed again, so coming from RiverBed – and then allow people to access this network through the last mile… And we started seeing that the last mile was getting very fast and very high quality very quick, but global links were not. So essentially we stripped the problem into two parts, we said we’ll build a great, global core, deploy all oru services in these points of presence and service nodes, and allow people to access it over a short last mile, but that last mile can be internet, or it can be layer two, so it makes it flexible. And then, we moved that sort of junction for application control and management into the POPs… Now, how did that evolve? That sort of fit pretty well, but remember at the time it was — there was no concept of SD-WAN and the move towards a software-defined WAN hadn’t yet started. So, it was a little early but it was about four years later that people started coining the term, and so we also got along the same — I say, we were dragged into the same river.

Max: [03.38] What makes Aryaka neat – let’s talk about this. It is so much about your global network and your POPs, and the access to it, so there’s not… Outside of a global carrier with MPLS – it’s transitioning from MPLS to SD-WAN play, there isn’t anything out this in the market still to this day, and it’s more than just your POP architecture, you’re doing a lot of things inside of your POP and your backbone to do network acceleration and optimization for people as well. Can you dig into that a little bit?

Ashwath: [04.12] Yeah, absolutely. I think — when you look at the SD-WAN evolving with MPLS, it’s actually a different architecture, if you will. What they’ll look at is they’ll build two parallel networks, one is over the internet, and one is over the MPLS network from the edge. We sort of took that to a different model, where we make that junction box sit in our POP, and the kind of optimization you can actually achieve when you control both the endpoints of a link is phenomenal, right? For example, we do TCP optimization between our points of presence, and a very simple look ahead into that, you know – why does our optimization work really well between the POPs? Because we know the available bandwidth, and that’s actually the actual bandwidth the customer is subscribed for. So, TCP says, “Hey, you know, I’m going to send a couple of packets, you give me a NAT, okay, four packets, and you know, we’ll figure out where we get to when we see loss.” We don’t have that. We go straight to… You subscribe for twenty megabits per second, not two hundred – every packet of yours, you know, the inter packet gaps, so on and so forth, the data rate is always two hundred megabits per second. So, even if I have a ten kilobyte transfer of a short file, it goes at two hundred kilobytes per second — two hundred megabits per second, whatever your subscription is, right? And so, we modify the TCP stacks, and the stacks are modified so that it stays reliable. It’s still a TCP stack, but the windowing is not about… You know, how much space do you have right now and so on, the other side always has buffering and we make it so that it’s a rigged management stack. The receiver signals what’s the available bit rate to this sending site, and so that allows us to make a very, very smooth, high performance experience for the end user, because the WAN optimization proxy in the POP basically decouples the last mile, so think about it like this… You get on and onramp onto the freeway, and then the freeway, you just get sling shotted across to the other end, and then come off an offramp, right? So, that onramp and offramp be either the internet or layer two, typically it’s internet, and you’ll be surprised that at ten, fifteen, twenty-five millisecond latency, you can do a lot of cool things, even with pretty heavy loss, because the recovery is within ten milliseconds. We can do a lot of other things, like… Okay, you have two ISPs, four ISPs, whatever. You take the ISPs, we can do load balancing across them, you can do error correcting across them and so on. And so, you clean up that last mile, and then you’re now sort of in hyperspace when you get in between the points of presence, right? And then you really get  basically sling shotted across. That’s one part, and of course data deduplication which we can talk about a little later. But, all of that technology, you can’t put it on a little box at the end, because you need big, heavy metal for a lot of this, especially for the data duplication, deduplication technology… So, what you do is you split the problem up, you say, “I’ll take care of the small part, that’s the last mile, from a box at the end, to the POP. I’ll take care of the big part on much larger servers so on and so forth.” 

Max: [07.25] So I mean, really what you’re talking about in part is automatically calculating a bandwidth product, so your POP’s optimizing that transmission from POP to POP along your backbone, so Africa to North America, China to Europe; whatever that entry and endpoint is, and if anyone’s gone through and had to manually calculate what a, you know, BDPU is and how do you set your window sizing and, “Oh, I’ve got this ten gig link from LA to New York, why is it slow,” you know? That’s — there’s a lot of value in that, that definitely makes life a lot easier for the end user experience as well as the network engineers that are responsible for maintaining this. And that’s something, by the way, that MPLS lacks – I mean now you’re talking about an MPLS replacement product, but MPLS doesn’t offer you that, that’s something that you have to do by hand.

Ashwath: [08.12] Exactly, and the other part with MPLS is, it is a congested network, in the sense that… Let’s take a datacenter at one end, talking back to a small site at the other end, right? The datacenter has a gig pipe, the branch has a two —

Syed: [08.28] We’re able to make sure that — in the middle mile, first of all, there’s zero loss, right? If there’s any… If the two megabit site is actually signalling back through our stack, saying, “Here, I have two megabits of available bandwidth to use,” to the datacenter, and that’s getting propagated through our stack… So, the proxy, the POP at the datacenter is actually accepting only two megabits for this particular site, while it’s accepting a much higher data range for others. So, that’s something MPLS can never do – there it is, the endpoints send at the rate they can, they figure out my loss, how much they can actually send, right? Here, we know exactly how much we can send.

Max: [09.10] So that’s the first part of it, the second part of it is… Deduplication, and I think the combination of the WAN optimization and the deduplication… I mean, I don’t know of another product that’s doing both or another service that’s doing both of these in one platform, and there’s also, I think this causes some confusion, because when we look at sizing, you know, how Aryaka actually sizes its network and what you do for a subscription… It’s size based on how much bandwidth is going through your POP, but if you’re talking about an application traffic going to a CRM instance, or an ERP or you know, a centralized application, there is a lot of data that doesn’t have to be transmitted every single time. And so, it’s not a one for one, it’s not a, “Hey look, you need ten meg or twenty meg or a hundred meg,” I mean, it’s much smaller than that. So, what is that experience like with your customers, and can you quantify a little bit of that?

Ashwath: [10.01] Yeah, I’d say it’s probably the single biggest selling factor in a product… You know, it changes the user experience. I’ll go back a little bit – so compression has several buckets, and let’s go to GZip as a compression tool, right? It’s pretty good, but it’s pretty good on certain types of data… Data  deduplication is pretty good on a broader spectrum of data, including encrypted files and so on, right? And what data deplucation does, is essentially finds strings that have already been sent before, or sent in a very similar format, so they can be expressed as a small change, and tells the other end, “Hey, I want to send this string to you,” and it’s like a recorder at both ends, and the recorder is just replying at the other end, right? So, a lot of data doesn’t have to be traversing the network as a set. So let’s take an example – and by the way, just rough numbers – we get about two and a half x average compression… That means that, if you bought a ten megabit link, you’re probably getting a twenty five megabit average performance, let’s say twenty megabit for now, two x, right? But actually what’s happening is, that twenty megabits is coming from some of the applications actually getting a ten x increase. So let’s say I’m reading a file, let’s say from a cloud node or a SaaS node… That file is coming through with a compression ratio of eight percent or ninety percent, and when that happens, the person’s actually getting that data rate of fifty or a hundred megabits per second for that file. So, the user experience is far above the average compression; it’s actually made up of several spots of very high compression, which is really something that a person clicking a file, wants to get on with it, if it happens fast – that’s the value, right? I mean, it’s not so much, “Oh, I saved so much bandwidth,” it’s really, “How much time did I save because the transfer happened more quickly?” 

Max: [12.05] So, that’s a really interesting point, because when you think about it, there’s — you talk about global capacity and global networks, and how big is the pipe into South Africa, do you have a contingent into South Africa, or into LAtin America, whatever the endpoint is, right? So, how long is that transfer and do you actually have the capacity. When you look at North America or Europe or even parts of Asia, you have relatively high bandwidth access for the end user, so the end user or the branch, we have the luxury of relatively inexpensive bandwidth at most locations now, you know, in the United States. But there is a big difference though, in terms of instantaneous file access; if you’re clicking through a CRM doing order entry, doing ERP, how long does it take to transmit? I mean, if you’ve got two hundred milliseconds you’re saying you’re going to save, 10 x compression, you don’t have to round trip that entire thing. I mean, that is a big change for the end user, what they’re experiencing. I mean, it must feel like it’s almost on their local node at that point, that they’re actually in the branch interacting with the application?

Ashwath: [13.04] That’s exactly the experience – that’s the nirvana or the eldorado of WAN optimization, right? I mean, you get as close to it as you can.

Max: [13.11] A lot of SD-WAN is positioned as… “MPLS is expensive and you should come to SD-WAN because it’s cheaper,” I look at SD-WAN – for a lot of places – as SD-WAN is more about control. Maybe you didn’t want to have an entire global network under one logo, and not be able to go out and achieve or bid and gain access to different local loops. We see a lot of places now where local loops from an on net provider in a building are very inexpensive, almost – you know, I mean it’s getting silly in how cheap these local loops can be, but if you’re on an MPLS vendor, with a global network, you don’t have the option to say, “Okay, instead of paying x-thousand dollars for this node, we’re only going to pay a couple hundred dollars.” So, I think SD-WANs value proposition is shifting for some people, but then you start talking about these other issues: how do you optimize it, how do you secure it, how do you bring it across globally and what’s your security profile look like? And how do enterprises deal with that, and how do you help people accomplish that shift from, “We know we have a private network because it’s MPLS and now it’s something a little different, what does that mean for us from a security posture?”

Ashwath: [14.17] You know, I think you’ve sort of hit on the Achilles heel of SD-WAN if you will, I mean almost every customer who’s come off of MPLS has had a pretty good, stable network – stability, stability, stability, that’s it, right? And suddenly they’re exposed to the internet. Go to every branch, put a little firewall, bad things start to happen. Bad things in a sense — things you never thought of: somebody’s oversubscribed a link, and the internet starts choking and your performance drops, right? So, you’ve got to take care of a lot of those things. Then the security issues, right? Every place is now a honey pot. I mean, there’s no honey pot in the datacenter, no honey pot in the cloud – everywhere is now a honey pot, right? Number three is that it’s not that easy to actually convert from MPLS to internet, because if you have five hundred sites around the globe, you probably have five hundred ISPs, maybe four hundred ISPs, right? And, you want a redundant connection at every site? That’s eight hundred ISPs. Okay, so – that’s a lot of ISPs, right? How do you get there? It’s almost a nightmare unless the person you’re working with understands that transformation – it’s literally a transformation, right? So, I mean you get plenty of bandwidth cheap, but you’ve got to take care of so much other stuff, it’s planning, logistics, security… At Aryaka, we’ve taken a different path from a lot of people; I think there’s multiple ways of skinning this cat, right? One is, you’re cost sensitive. The second one is the security sensitive, and the performance sensitive. So, all of these, a large enterprise cannot afford to say, “Look, I’m just going to use whatever security is available at the branch and split my edge and allow anything and everything to get in.” So they’re really going to be more of a best of breed perimeter, they’re going to say, “My perimeter is going to be a PaloAlto, it’s going to be a Cisco, a brand name of some kind, ZScaler,” right? And then there’s those who will say, “Look, I’ll just take internet security as a checkbox for me. I’m probably busted anyway, so I’m not going to worry too much about it,” right? So, we cater generally to the former, and in that situation it’s a little bit more of a natural transition, and you have to accomplish this transition from MPLS… MPLS networks have — they’ve evolved over time. If you take a look at the configurations and the BGP, the rule set that has been put up, so on and so forth – you’ve got to understand it, right? It’s not as simple as saying, “Hey, I’m going to plonk this box in here, throw that box out, and we’re done,” it never happens that way, right? So, strangely enough, we focus a lot on making our BGP very strong, so the ability for us to say, “I could put fifty thousand routes on a little box,” that’s what we strive for. How do we do it? Of course, we don’t have to do it the way that everybody else does, we can do it in the POP, right? We only have to lead the routes that are required at the site. You see, when you’re doing a transition, it’s really hard to sit and resummarize all the subnets, right? I mean, this is well before you come back and say, “Oh, I’ve got to get my application to be split across this.” First you’ve got to transition the network, then you split the applications, right? That sequence is something people don’t let themselves, and shouldn’t let themselves into thinking it’s going to be easy.

Max: [17.30] So, let’s talk about this for a little bit. What does a transition from MPLS into Aryaka look like? I mean, from a planning and deployment standpoint, or from a cohabitation? If we’re going to keep — MPLS needs to stay for however much time, because it’s contracts or you want to overlay or because you’ve got hundreds of nodes you need to put it in place and bring across, you know, enterprises – how do they approach this?

Ashwath: [17.55] We look at two different kinds of customers – customers are solving a single pain point: I’ve got a problem in China, I’ve got a problem in San Diego, I’ve got a problem in Brazil, can you connect them into my network? Great. In that situation, MPLS stays exactly as it is for the rest of the places, right? Or they use the internet in the US… Now, the broader customer we’re talking about — the people who are really doing a WAN transformation; they typically see – for a five hundred site network, let’s take a rough number of five hundred – keep in mind the MPLS guys, they started out with always full mesh. They put constraints on you, so you have to scale the five hundred sites before you can start — otherwise it’s a nightmare trying to do the routing over and over. So, we just allow it to go straight to five hundred sites from each site, right? Now… The first thing that a person thinks of is, what’s my security posture? Oh, am I going to have split tunneling at all the site’s split edge? If I do, what’s my firewall policy going to look like? Then, my MPLS contracts, they expire — you know, as with anything else, they’ve got renewed, they’ve got changed, and so on and so forth. So, the endpoints don’t actually coincide at all, right? So usually, you start off with maybe a thirty, forty site, and then once you’ve procured the internet you make a plan that says over the — say the next eighteen months for a five hundred site network is a reasonable amount… I mean, we’ve done it in three months, because a person had a completely constant MPLS contract removal, as well as they already had internet; those are the two things that are — the long pole is typically internet availability, the logistics of getting setup… Now, and typically what you do is you say, “Look, I’ve got these two networks, one is an Aryaka network, the other is an MPLS network,” and there are many ways of doing this work, right? And then, you start migrating sites from the Aryaka — from the MPLS network into the Aryaka network, as and when a contract expires, and these two networks peer at, right, maybe a half dozen big datacenters, and MPLS remains on the other side, until all of the sites are migrated across. And you know, sometimes what happens is, there are going to be some datacenters that retain their MPLS forever – there’s no need to change something when you have eight datacenters in the space of four hundred miles, why do you want to go around ripping that up and putting internet between that? It doesn’t make sense, right?

Syed: [20.15] Just to add – the way the migration happens is we identify locations, the hub locations, we have both Aryaka network and MPLS network co-exist, and then you start migrating the sites totally from MPLS to Aryaka, and then the connectivity which they have to the other MPLS sites are through those hub sites, until the full migration has happened and sometimes there are locations which would be — the MPLS won’t be migrated, as well.

Max: [20.46] Let me talk you through a couple of different architectures, just so I can understand this better in my own mind. When you think about an MPLS network with the internet at the edge, so at a branch… There’s usually one or multiple internet providers coming into usually a firewall device, which is then connecting into some sort of internal network equipment, some sort of switch infrastructure or whatever, and then attached to that is whatever the WAN router is for the MPLS circuit, right? And then it comes into the IP address propagation, so what’s actually routing, what’s the routing protocol, how do you actually advertise IPs across this network, but ultimately something knows that if I’m inside the firewall at this branch and I want to talk to this corporate resource, here’s how I traverse the MPLS network. When we look at SD-WAN from an internet optimization standpoint, the SD-WAN is installing outside of the firewall, so that way the internet circuits can plug into it and it can do path selection, take path A, take path B, you know whatever those decision points are for that SD-WAN, but it sits outside the firewall. With Aryaka being MPLS augmentation, alternative replacement… That terminology kind of gets a little fuzzy quickly. How do you do both internet optimization and selection across internet circuits, but as well sit behind the firewall and let corporate traffic traverse where it needs to traverse and not egress across the firewall?

Ashwath: [22.08] So, in a typical network you’re going to see the Aryaka appliance – the ANAP as we call it – having one leg towards MPLS, one leg towards the firewall, one arm — because… and at the back-end, it’s talking to the large L3 switch or the, let’s say a transit router of some kind, right? And we’re doing BGP towards the router, and we’re doing BGP towards MPLS, and we’re doing application data selection between the MPLS and the internet paths, right? That junction box will be – you can configure policy in it to say that these applications take the following – that’s one form of integration. Another is to just say – at least until a point in time where MPLS itself is… I mean, if it’s a transition or if it’s coexistence, what I said works, but if it’s something where you’re going to transition completely out of MPLS, then the fastest way to do it is — the ANAP actually does BGP into one network, and our own routing towards the internet and our POP network, and so – like what we said earlier, you can be doing it slightly differently, where the LAN traffic is going to different sites based on routing itself, not so much as an application policy. That’s the fastest way to integrate, right? Later you add the application policy and say, what part do I select which is better for this application? But you don’t want to — you know, have two moving parts at the same time, because all the other sites on MPLS, which are still MPLS only, don’t understand the application, right? So you could do it both ways, but I’d say the simplest way is to use routing to a point in time where we have enough sites which are actually connected together by both parts, and then you use application on those parts, and then routing elsewhere.

Max: [23.54] So a lot of the analysts are predicting massive reductions in revenue globally on MPLS backbones. So, the carriers have been pushing into their own flavor of SD-WAN for a while to maintain, I would say, the stickiness with the customer, as well as not cannibalize their own revenue too much with own providers. As the space has gotten more crowded, how have you dealt with that? I mean, what’s been the response with Aryaka? There’s lots of other now just box vendors with some kind of orchestration coming off a web page, right? So there’s cloud SD-WAN appliances pushing into market that really don’t have a lot of – I mean actually they don’t have — basically any of the Aryaka flavor and sophistication to it, so what’s that cycle like when you’re talking to customers and people are getting a bit deeper into this?

Ashwath: [24.45] Very good point, I think it is one of the most confusing aspects — SD-WAN has become anything and everything to everybody, right? You know, we have to focus on a couple of things, one is we are a managed service; we rack that end to end service as a managed service, right? You can take a lot of good examples, customers who are happy… You’re going to find that it’s about production of complexity, and having – I mean SD-WAN in a lot of ways makes things much more complicated at the edge, right, because now you’ve got — your IT person has to understand applications, which applications are important? I don’t know. Every application is important to some extent, right? You can’t say it’s not, right? So, we try to put a wrapper around that whole complexity portion and say, “Look, your cost… At the end, why do you have multiple networks? You have redundancy and the flexibility to cloud and all that stuff,” you get all of that. Cost is an important aspect; the balance between high quality and low cost, right? It’s something your application makes this indeterminate… I think you asked a question about how much bandwidth do you need – I don’t know! The world is changing, right? So, a lot of that is — it’s easy to get there, you have some good tools to make some estimates, but we have to be flexible. I think that’s our story, right? And the other thing is, for us it doesn’t make a whole lot of sense for the customer to learn a lot of new technology to adopt it.

Syed: [26.10] The other piece to it, like how we have evolved, and how we have started offering internet-only paths as the option for some customers who were able to just consume it and it doesn’t really necessarily have long distances, and going across the globe… So essentially, they don’t need the POP itself to connect to and then have that level of optimization, but that goes back to the value of the managed service. They can consume that service right away, and whether they are presenced globally, or they are essentially in a regional place; so we can have both the flavors available to them.

Max: [26.50] So let’s actually dig into the internet only, because this is a relatively recent announcement from Aryaka. So, core service connection from the ANAP, the appliance on the edge and the branch, to a local POP, accelerated across the backbone, wherever the egress point is to application, right? So if that egress point is to another branch of a datacenter that the enterprise controls, or if it’s to a cloud provider, you know, a point… Everything between A and Z is your network. So as an internet-only path, you’re removing the POP from that selection, you’re just talking about internet optimization only, is that correct?

Ashwath: [27.27] So UNINTELLIGIBLE 27.28 I mean, I think let’s go back a little bit, right? The POPs remain in the network, right? The POP is still the controller, and we really don’t have an internet-only option as in managing and configuring the ANAPs. It’s still configured centrally, it’s still managed by us, right? The internet is a path, and it’s a question of are you putting a hundred percent of your traffic on an internet path between the ANAPs or are you putting ten percent, or zero percent, right? That control is what our controller and policy management takes care of. Syed, do you want to…? 

Syed: [28.01] The value, like if you want to differentiate us against anybody else providing the similar solution, the value is that we have the POP architecture available to us, right? Okay, when we want to have some of the applications, if needs be, can go over the accelerated path, which is our own Aryaka core path. At the same time, there could be some applications – data applications or something like that, which essentially do not, may not require the accelerated path. So, that’s how — when we really have to differentiate on top of being a managed service offering a consumption model, you still have your strength as your… The core architecture, which you can offer to the customer, versus any other box vendor which purely relies on internet.

MID-ROLL: [28.54] Hi I’m Max Clark and you’re listening to the Tech Deep Dive podcast. At Clarksys we believe tech should make your life better, searching Google is a waste of time, and the right vendor is often one you haven’t heard of before. With thousands of negotiated contracts, Clarksys has helped hundreds of businesses source and implement the right tech at the right price. If you’re looking for a new vendor and want to have peace of mind knowing you’ve made the right decision, visit us at Clarksys.com to schedule an intro call. 

Max: [29.20] So long term impact to business from COVID is still… I mean, we’re still in the guessing phase, it’s going to be a little while before we really know, but what we see right now is this rapid acceleration of digital transformation and digital workflows. You know, where do the applications sit? If  they’re still sitting in the branch, are they sitting in the datacenter, are they being moved into a cloud platform, how quickly is that being done? And then we get into this idea behind — is it a distributed or work from home workforce, are they going back into branches — so there’s a big question as to what that actually means, with lots of people making predictions… I won’t make any but as you look at this transition from an on-premise application to a cloud-hosted application, I mean… That’s everything. The entire world is going in that direction, it’s just how quickly people get there? And that changes some of the equation when you talk about MPLS and how I would imagine Aryaka is looking at the future for supporting application, application performance for end users. I mean, what’s your sense around this, what are you guys expecting and where are you heading in this area?

Ashwath: [30.24] So, very interesting. I think that sort of goes right back to our roots, if you will. The idea was to allow a customer to add, let’s say an AWS node, through a direct connect, into their own network. And in fact, experiment on what compute — which of their applications moved up there. It’s not that easy for a person to say, “Hey, I’m going to take this application and run it on AWS,” and make a prediction as to how much it’s actually going to cost them, or how much money it’s going to save them, it’s actually — And I’ll tell you that we’ve had customers who tried both Azure and AWS — because we’re a multi-cloud, we have connections into both, they bring up both and say, “We want to run a six month trial where we might take these applications to both of them concurrently, and try them out in both places.” And actually, one customer said, “Hey, at my scale, I find that my datacenter is actually cheaper, so I’ll move it all right back.” So it’s not just about moving it, it’s about the ability to move it to one node, to a different node, or back, and I think that, if you will, is us, right? And it all relies on the fact that it takes us about twenty-four hours. If you give us your subscription on Azure, in twenty-four hours that subscription, that node, that Vnet is in your network and accessible, right? That makes it pretty — you know, within twenty-four hours you’re up there, and then you can start migrating your application and see how it behaves, you start by migrating a few users usually, right? So of course on the SaaS side it’s a little bit different, that is a little bit more… It’s happening all the time and the movement is — because you want to manage the application. You’re going to move to Concur, you’re going to move to Salesforce, that’s a given, and it’s happening, it’s happening faster. You’re going to move to Zoom, you’re going to move to the application you’re using, which is absolutely fabulous, but… 

Syed: [32.11] Squadcast. 

Max: [32.12] They —

Syed: [32.13] So at the end of the day, I’ll just add, the flexibility which is available in our architecture, where we already have direct connect to AWS, express route to Azure, fast connect to Oracle… So, the connectivity was always there, and the flexibility that the customer sees, they can go ahead and give it a pilot, okay? They can start with a pilot ,they’re going to go ahead and put some applications go straight into the cloud, but having a private connectivity to their network, via their network. So, they’re not using their internet to consume that particular application, so that flexibility is what we provide.

Max: [32.53] You touched on something, which is… There’s a misconception I believe that the cloud is cheap, and in many cases cloud is way more expensive than traditional infrastructure. Cloud is flexible, cloud is global, cloud is, you know, it changes your operational overhead and management points of what you actually have to focus on and what you’re touching. You know, are you in a hardened refresh cycle, are you managing generators in a datacenter facility, you know these sorts of things change pretty significantly with cloud and the ability to scale changes significantly with cloud. I think it’s interesting because that has a similar parallel when you talk about MPLS versus not, right? Traditional B2B sales is, “Hey, we have a service, it’s better than the other thing, but it’s also cheaper,” and that becomes an entry point — but the problem a lot of times when you start looking at cheaper, the cheaper as a value proposition doesn’t mean it’s better. It doesn’t mean it’s more performance and you’re not going to have an issue with productivity. I’ve seen plenty of environments personally, where changes are made because they were quote, better and cheaper, but productivity suffered and it actually cost the company a significant amount of money. And I’ve never heard a conversation with Aryaka that’s been around, “We’re cheaper than MPLS,” it’s, “We’re better than MPLS, and you’re going to get a lot of performance benefits out of this,” and I think it’s an excellent positioning for you to be in, and to really focus on. It’s not a story a lot of people are talking about.

Ashwath: [34.19] Thanks a lot, yeah. You know, I think you put it into a nutshell really well: it’s all about — the real true cost to the customer… TCO is an overused term, I shouldn’t be using it, but at the end there’s a lot of – as you said – the bill may be lower, but the number of people running around to make the damn thing work shouldn’t be so much that it’s a headache, you have downtime… Yeah, your WAN bill went up, but — we’ve had customers who have actually migrated from MPLS into an internet-only based solution, and then — a public company, well known public company, and they really hit a wall because productivity went down, they were using a large company’s multipoint VPN solution, and then they actually had to abandon that and they were trying to get MPLS back and it was going to take them six to twelve months to get MPLS back on all the sites. Guess what? They tried us for a few of the critical sites, now they’re a customer on all of their sites, and the CIO is a person who comes in and tells us everything, he says, “Hey, you really saved my butt because at the end, we were really at a point where we had to make financial disclosure, saying – I’m sorry I made a mistake, my network being down caused financial impact,” right? At that point, you’ve got to realize it’s not an experiment. The cost is… It’s easy to say it’s cheaper, but is it really going to be cheaper to the company, or it’s cheaper to the WAN bill, right? You’ve reduced your WAN bill, kill the company, that’s alright.

Max: [35.47] So I mean, Aryaka pricing component. The biggest piece of this boils down to how much traffic is accelerated across your private network – across your POPs. And when you look at that from a conversation, you say, “Okay, enterprise, you have five hundred locations, and these are your applications that you’re running, and this are the geographic spreads that you have on them, but how much bandwidth are you using for application A that you care about, and application B…” How do you help people understand that and then size that and make decisions about… This is what’s going to traverse our network, and this is what’s going to be optimized across our network, and this is what your expected price to use this service would be.

Ashwath: [36.28] A couple of things… Life’s full of surprises, right? So yes, we do a fairly good job of analyzing what a site is doing, and with people who can look at it and come back and say, this is what we recommend, right? But what people have to realize is the reason they’re moving out of that MPLS network in the first place, is because they were planning some other transition completely. And that transition is… “I’m moving to Office 365”. Guess what? Office 365 is no longer going to be on that network, alright? In fact, it’s going to go through our network directly to your Office 365 nodes. So, I think you can size it well, but it’s only a first path. You have to be flexible, so you can change your sizing and say look – you’re still consuming fifty megabits at this site, but it’s no longer going to your datacenter, it’s now going to an Azure node, it’s now going to your Office 365 edge node, okay? So, change is the biggest part of SD-WAN. That clears up everything, right? We convey one thing, that you know, we’re working with the customer and we’re not out there to overcharge them, we’re also not there to give you a false estimate in saying it’s going to be free, right?

Max: [37.38] I mean it’s hard to compare costs, you know, and make that one to one, but people don’t like uncertainty when they’re buying or budgeting, right? That becomes this — I mean, it’s a pretty big leap of faith, right? The closest parallel I can make to that is somebody looking at ninety-fifth percentile billing in a datacenter for the first time. You know, if you haven’t had experience with understanding what ninety-fifth percentile actually  is and how does it bill and how does it structure and like, “By the way, it probably is very good for you,” but if you just look at this saying, “I’m going to have a variable bill and I have no idea what to tell my finance approvals,” that can be scary to walk into that situation if you have no history with it. I actually love the point that you made there before, Syed, about there’s another transition underfoot, and so there already is a ton of uncertainty, and I don’t think people talk about that a lot, you guys don’t highlight that a lot in these planning — in this initial integration or the initial contact conversations.

Ashwath: [38.33] That’s actually the hard part. 

Syed: [38.34] Yeah, so the banquet sizing perspective definitely is going to be an estimate, and we typically, the way that we look at it, we look at what your current WAN is… Are you using MPLS, are you on internet with MPLS, are you having any optimization going on, what is your current usage overall? And then looking at the applications, and as Ashwath said, if there is any strategy around migrations, right? Are they going into adopting any new applications, and what will that usage look like? So, considering the number of users, the type of applications, and what’s – how the existing networks look like. These combinations, we will go ahead and put an estimation on how much bandwidth they’re going to use per site. 

Max: [39.24] Something we touched on briefly was this idea that customers that have a big MPLS network already, but they may have a problem site: Santiago, Cape Town, Shanghai, you know – you pick these markets where it’s notoriously poor performance for a global network. And so, a company comes and says, we have a very specific problem and they want to solve it, and we’ve identified that you can solve it for us, but we’re going to leave everything else alone. I would imagine that once they’re on your network, that that conversation shifts pretty quickly. How does that look for you know, on the average… I mean, is it frustrating that that’s how people view you as a company, as like, “Oh, we’re going to solve this esoteric, weird, difficult to reach geography, but that’s all we’re really thinking about.” How do you want people to think about Aryaka and what should be the impression that we leave?

Ashwath: [40.15] First of,more than fifty percent of our net new bookings every quarter comes from existing customers. So, what that tells us is that our customers are pretty happy with that service and they want to buy more, right? So when you said somebody wants to lead with a customer of point sites and they say, “Hey you know, that’s all we’re interested in.” That’s fine, because the easiest time to talk to a customer about doing a bigger transition, especially a sensitive customer, is after they’ve experienced the problem being solved and the support that they get. Until they have that, for a large customer to make a big decision it’s almost impossible. It’s going to be… Do nothing, because it could get worse, right? So, foot in the door, if the customer is happy six months down the line, the next MPLS node that comes up for renewal, we’re up there. The difference is, they’ve experienced what we do, both in terms of application performance and in terms of you know, finally… CIOs worry about problems; a problem occurs, how fast can you fix it? Downtime, all that stuff, right? How much are we willing to step onto the table and not say, “Hey, you’re not my problem, it’s somebody else’s problem.” I think all of those, when they experience our support, it’s… It’s my problem, until we can find who can solve it for you, as opposed to… Go away.

Max: [41.36] How much of this is managed by you and how much of this is managed by the customer? I mean, are you giving the customer a portal and saying, here you go have it and go configure things like crazy or are you saying we’re going to configure this for you and if you want to make changes, talk to us. I mean, where does the line start and end?

Ashwath: [41.52] It’s a sort of combination of the two. We do support all the configurations we want, but by and large most of our customers say, “I’m pretty happy if you configure everything and manage it. Tell me if there’s some big changes, let me have the ability to see the changes that are done, see the effect of the changes, the application visibility and so on, and should I need to make a change, and I want to add some of this change routing and this node and change it back, I should be able to do it, right?” So we support all of it, and I would say that the uptake of self management is probably five to ten percent.

Syed: [42.29] In most of the cases, customers are happy how we do the default configurations and they will identify the applications that are important to them, and then based on that we’ll go and configure it, but in some five to ten percent cases, customer would like to go ahead and identify and have some level of control, which we have provided in our portal, in the management portal which we offer. And we are adding those features, enhancements, as customers are asking for more control. We are adding those on a regular basis, and that also gives the fact that if you look at other managed service providers versus how we offer the solution, we own our technology. So, our feature velocity against customer requests is much faster, and we can respond to customer needs much quicker and that’s the  value which I see when it comes to Aryaka providing managed SD-WAN services.

Max: [43.27] So there’s been some merger and acquisition activity recently, and we’re probably going to see a lot more, you know, this is going to accelerate with big names buying other big names for big dollars. But a part of this is creating and further fuzzing the line, so you talk about… You know, we talk about SD-WAN as a marketing buzzword. There’s this constant line of new marketing buzzwords that become Gartner categories, and then become tracked, and then everyone has to claim that they can do that buzzwords and that they can hit that checkbox when corporate buyers are out looking and procurement departments are shopping. Are you expecting to see that transition as well? Are you guys going to expand out with this? I’ll be more specific, I mean the lines between what was the SD-WAN and what was the firewall are starting to become blurry. There’s now this concept of the SD-WAN appliance on the edge connecting to a cloud based or federated firewall is starting to become more prevalent in industry and blur. Where do you view this thing evolving and are you going to… Do you think you’re going to follow that line, or are you going to stay where you’re at?

Ashwath: [44.29] That’s probably the most challenging of the day, the rest of it was technical, now it’s really the crystal ball, right? So, our customers tend to be very security-conscious. So, we’ve been focusing on customers who feel they have a lot of intellectual property, they lead with… What’s my security policy? What’s my posture? And for those people, change and security is a lot slower. They’re not going to say, “I’m going to try this new firewall, it’s available federated in the cloud and let’s hope for the best,” right? So, I think the change is going to be slower, we’ve taken two tacts in this: we do have our own perimeter firewall and so on inside of the device. We don’t market that because frankly most of our customers are going to be using a best of breed brand name firewall of some kind, right? We do work pretty well with Zscaler and everybody else who is in the cloud. We are sort of more of a… The customer makes their security choice, right? And as you said, we are also concerned… Everybody says, “I’ve got it all integrated just come to me,” right? So far we haven’t seen our customers being highly excited about that. They’re looking at that more with some fear, saying that I’m not going to put my crown jewels there and have them stolen. So, how will a player — it’s a concern for me every morning, I don’t know. I would say that we are adding functionality, we are working pretty closely with other security vendors to see at what point we can actually make a better job of integrating the function so that they’re better manageable, right? The point is, you can have the best firewall, in a couple of locations in which your policy is incorrectly configured – you only need one place to get into the network, right? I think that it will converge, and come out over maybe the three to five year timeframe. I think something like this COVID shutdown and so on and so forth is actually going to slow the transition down… It will speed up one thing. It will speed up the need for a managed service model, because IT people want to have the control on the concept – the architecture of the network. But they’re not necessarily going to be physically present everything, and so that’s also changing; they want to be able to do everything remotely, so I think there’s going to be a trend towards more of a software defined network, less of CLI, less of physical control of devices and so on, but in terms of security and I think convergence, we see that happening, but it’s a little further out, and I think that the mass market might move more quickly, but the larger enterprise and mid to large enterprise are going to take their time with all that, until the security brands actually mature in those spaces.

Max: [47.12] I think what makes me concerned every time I see an acquisition is… There’s not very many companies that do very good jobs with acquisitions, or end up with an end product where the sum is better than the parts. And it’s always kind of curious to watch and wait, you have to hold your breath and pray that everything works out perfectly, because you know, obviously the company buying the other company bought them because they were doing something good for a reason, and you just hold on and hope that it’s going to stay good when it’s finished. You know, COVID’s going to be really interesting; the transition, the speed-up… We see — historically the negative term was, we talk about IT staff and admins and engineers as being box huggers, right? I understand that, like I loved routers, it was fun getting on some big iron and configuring a big box. There was always something exciting about… You have to use a forklift — I mean, literally on some kind of pallet lift with a device in, it was awesome. After you do that for a little while, you realize you don’t care anymore. It’s still cool, but I feel the organizations have matured to the point where the company wants productivity to be up, and application accessibility and availability, and these are the conversations that you end up in. Why is the application down, why is the network down? Not, are you pushing the buttons, but does it actually work? That transitions into a conversation I have with people a lot which is, are you taking vacations? When was your last vacation? Do you want to take vacations? I think that shift has come… I definitely feel it. I don’t feel like people are taking vacations as much as they should be, but the desire to take vacations is definitely there for sure, for most of the IT staff in traditional ways now. Closing thought for you really – we’ve talked about this in a couple of different ways, but let’s ask the question distinctly: how do you want people to think of Aryaka? If you’re going to say, “This is the problem that we solve, this is how we make your life better, this is where we fit in this puzzle to make your life better.” How would you want people imprinting that in their mind? 

Ashwath: [49.18] I think if you want a high quality network with application performance like you’re sitting on the LAN, and you want that experience that the transition to that network, a smooth one where somebody is making sure that — they’ve been there, done it, so they’re able to help you make that transition smoothly and get you to the other side… I think we’re the people for that. Try to leave the technology out of it, because trying to talk about why technology solves somebody problems, sort of makes that person have to really understand the value of that technology, right? Some of them will, but a lot are simply going to say… “Just make sure I can sleep at night. I don’t want to be called.” And actually, one of the CIOs that we work with, who told us that exactly, he said, “Look, ever since I’ve put Aryaka in, I sleep at night.” Another CIO told us just recently, he’s quotable, he said that with this whole COVID situation they were able to transition to a hundred percent work from home force in no time, smoothly, no problem. Why? Because they were with Aryaka. We were already doing the remote hands and managing the — keeping the network up. And they’re a powerful company – so the business has not suffered a lot, it’s actually done well – it’s actually gone up, but they were able to make the transition fairly smoothly. So I’d say that’s another thing – we’re flexible, we’re already ready for a lot of these problems. Syed, did you want to have a –

Syed: [50.45] Yeah, definitely. One of the CIOs who told me — and I took that, okay, that’s really the way we should be perceived – is that we are not just another vendor, we are more of a partner, and we are an extended IT team. We can worry about your WAN network, versus like, you’re taking care of the WAN. So, you can think beyond WAN and start to think about your application, how you’re modernizing your business applications, while we take care of your network, and we make sure we enable that under the hood.

Max: [51.23] Awesome. Any closing thoughts that we haven’t touched on that we should get in here?

Syed: [51.28] I think merger and acquisitions… I think we didn’t touch on that. That’s another value which we offer. When customers are acquiring businesses and how we merge that network seamlessly, because the network is already available, right? For us, these are additional sites, and even if we have some companies disintegrate, as well. They have to divide themselves into two different business units or whatever, and we have done those successfully as well, and it’s the beauty of software defined, essentially. Everybody is going to get our core network, and we just have to make them multi-tenant – instead of a single tenant, we can make them multi-tenant, and as two different tenants, we can merge them into a single tenant, and that’s all the beauty of this architecture. 

Max: [52.16] I think that’s a great explanation for the – what I view as the real value out of SD-WAN – it’s control and flexibility. So when we talk about SD-WAN and what you really want to get out of it, it’s control and flexibility, and so what you’re talking about in terms of you know, I make your life better pillars, don’t worry about your WAN, we’ll take care of it, don’t worry about your application performance, we’ll make it better, including the crazy, far off locations that are always going to be a nightmare for you, you know? Good luck with this network in Shanghai, but we’re going to make your life better there, or in South America or in South Africa or wherever it is. As your business evolves and changes, we’re going to make these changes easy for you to accomplish as well. That sounds like a really powerful statement and conversation to have with somebody of being like, “We can help you actually manage your business and not worry about these things.”

Ashwath: [53.05] Yeah, thankfully we should snap that up and rig the deck! That sounds –

Syed: [53.14] You’ve summarized it pretty well, yeah.

Max: [53.16] Awesome. Look guys, thank you very much for your time, it’s been a pleasure.

Ashwath: [53.20] Thanks a lot, Max –

Syed: [53.21] Thank you.

Ashwath: [53.22] – and we’ll hope to have a deeper dive in the next conversation on some more technical stuff, I know you’re waiting to jump into a few of those, right? That’s on the data deduplication stuff! But thanks a lot.

Max: [53.34] I’ll take you up on that for sure.  

OUTRO: [53.36] Thanks for joining the Tech Deep Dive podcast. At Clarksys we believe tech should make your life better, searching Google is a waste of time, and the right vendor is often one you haven’t heard of before. We can help you buy the right tech for your business, visit us at Clarksys.com to schedule an intro call.