Yash Bajpai System Engineer Leader at CloudGenix on How CloudGenix Differs from Other Products
Hi. I'm Max Clark. And today, I'm with Yash Baspaj with Cloudgenix. And we're about to do a pretty deep dive into the technical deployment and, what Cloudgenix is and does. Yash, thank you very much.
Yash:Thank you, Max. I'm super excited to be here with you.
Max:So, Yash, when I think of SD WAN, I have a really crude buckets I put SD WAN into. And, you know, starting at the beginning, we see Internet aggregation and quality of service or optimization as a category. I think MPLS replacement or augmentation as a category. And then I think of WAN acceleration or traffic dedu deduplication as a category. And and people kind of flow up and down these stacks and and and cross over a little bit.
Max:But but how would you classify Cloudgenix? What is the problem that you're solving? What is the use case that you're built around?
Yash:Yeah. Thanks for that question, Max. So it's very natural, a very human tendency to relate to what you know and say, okay. This is similar to what I did in the nineties. In fact, some of the SD WAN solution out there, they're basically taking the problem of 20 years ago and then applying a software defined orchestration layer on top of it and calling it SD WAN, whether it's modifying a routing protocol, whether it's taking their WAN acceleration IP and then calling that SD WAN.
Yash:Cloudgenix is a pure play SD WAN. So what we've done is where everyone else have taken a bottom up approach, meaning they've on the OSI layer stack, they've taken the network layer up and solved the SD WAN problem. We've taken the user and the application layer as our unit of operation. So we are looking at not packets, but we're looking at sessions, and we're looking at flows, and we're looking at the user experience using those applications. And then we've built our SD WAN solution.
Max:Let's let's dig into this and talk about this in in terms of, like, human words. Right? So when we we look at SD WAN options, you know, some vendors are taking and looking at network performance or latency or ping times on circuit a versus circuit b versus circuit c. And they're making a decision on, you know, this is our preferred path, and it has the lowest latency to whatever we're testing against, so use that path. Or this circuit just went down, so don't so don't use that path.
Max:Or we wanna have a a really good user experience, so duplicate traffic and send traffic down multiple paths at the same time. And then whichever whichever way it gets there fastest, discard everything else. And what I've heard from Cloudgenix and what I'm hearing you say right now is that you guys are are really different in that regard. So how are you different, and what does it actually mean for somebody when they're looking at, you know, a Cloudgenix and evaluating your product?
Yash:Yeah. So first of all, I do want to say that and this is I'm not trying to say that we don't do what the other guys do. I'm saying we do something that the other guys don't. So let me talk about that. So, for example, the link layer latency jitter and packet loss, everyone else tracks that and acts on it.
Yash:We also do that. We also track on latency, jitter, and packet loss and are able to track that and act on it. However, that is where everyone else's story stops, and that is where our story just begins. So, for example, if your application let's say we are using Zoom as an application. And if that application user is saying, I'm not able to connect, or I was logged in to Zoom and I got disconnected, and this has nothing to do with link layer latency, jitter, and packet loss, This is application initialization failures or transaction failures.
Yash:Nobody in the industry can actually, do something tangible with it. There are some solutions that with some bolted on solution can probably give you some of that. But with us, we are tracking the emit failures, transaction failures, the round trip time from the user to the server, and then not just tracking it, but then taking tangible actions. Oh, transaction failures on path 1. No failures on path 2.
Yash:So then the application is now automatically going to gravitate on path 2, just that application. So these are the things which go beyond which transcends the link layer latency digital packet loss, the first mile problem that people solve with packet loss or WAN acceleration. We are able to have this end to end visibility and tangible, actionable analytics, as we call it.
Max:So, I mean, as a network engineer, you know, we've you know, I've never heard in my life, like, the the network's the problem, the server's fine. Like, that's never happened to me. I I mean, so if you think about it from a network engineer or, you know, your your troubleshooting path is usually like, oh, can I ping the remote site? What does the latency? What's the trace rate look like?
Max:Am I seeing asymmetric jitter? You know, can I do an iperf? You know, there's, like, a usual toolkit that people are walking through to troubleshoot these things. And often, that last piece is never really tested. Oh, you know, can you telnet into port 80?
Max:And does a server respond to you? Or, you know, what is what is the actual thing? So it's really interesting that Cloudgenics is taking and actually looking at if we send a SYN, how long does it take for that SYN ACK to come back on this path? And, you know, is it a path issue, or is it a application server issue? And can we make decisions and do things about it?
Max:I don't think you guys really talk about this enough. Or maybe it's that your people aren't hearing what you're saying because this is a very I mean, again, as a network engineer, this is a very interesting thing to me of why why wouldn't you want this? Like, this of course, I want this. You know? It's, it's it's a very cool feature.
Yash:Yes. And and we lovingly call this, you would have heard this from us before, the Mean Time to Innocence Chart. Right? And what we what we give our customers are the tools beyond the ping and trace and TCP pings and packet captures by the way, we we support that on every single port of Cloudgenix. But beyond that, if the problem today, when a SaaS application has a problem, no longer can a network engineer go and ping.
Yash:What is he pinging? Because a SaaS application is brought together by many, many different widgets, many, many different servers that form this dashboard on the UI on the on the on the browser. So what exactly, is he supposed to ping? The network engineer typically has no clue, neither does the Sysadmin in most cases for cloud app, applications. So we are able to automagically not just track that, but give you a very clear picture on this path.
Yash:This application is having a brownout. An application brownout only this application, and then we are able to steer traffic for that affected application around that path to another path which is allowed by policy.
Max:So, really, we're talking about Cloudgenics as SD WAN as it relates to application performance and application access. And right now, a lot of organizations are in this transition. Right? We see some applications still internally hosted, some applications in a data center, some applications have transitioned into a cloud or SaaS model, whether or not it's the enterprise's infrastructure in a cloud or if it's a, you know, like a Salesforce or an Office 365. So does the approach change at all within the the Cloudgenics stack of where the application is on the remote side?
Max:Does it matter if it's at a corporate HQ or at a at a colocation facility or at a at a at a cloud, at a hyperscale environment, or is it completely agnostic to that?
Yash:So we are agnostic to it. We support any model the customer may have. A lot of our financial customers, for example, a lot of our banks are still on the traditional model where most of the enterprise applications are in their physical data centers. And we also have very large set of Fortune 1,000 customers who have rapidly moved to the cloud. So from a Cloudgenix perspective, just to break it down a bit, we have the branch devices.
Yash:So we have a couple of hardware models, and these hardware are nothing but x86, based platforms. So it's just a server with a Cloudgenix, sticker on top. And so you can put that in the branch. At the data center, we have a data center grade appliance with redundant power supply fan trays and such. And then we also have deployment on all the major public clouds.
Yash:And one more thing, we also have, the, Equinix has a marketplace. So Cloudgenix is there in the Equinix colocation as well. So whether it's a private cloud, public cloud, physical data center, or a branch, it's very easy to deploy Cloudgenix. And I'll make one last point there, Max, is that the and this is tying back to the the approach that we have. A majority of the application are are now being delivered in a SaaS model.
Yash:In this model, we are the only solution that doesn't require a bookend. So it doesn't matter if the if there is a Cloudgenix at the branch, but there is nothing on the other end because the destination is neither in the physical data center nor is it in Equinix nor is it in AWS, Azure, or GCP. It is somewhere. It is SharePoint. It is Office 365.
Yash:Whatever it may be, a single ended cloud genix device can still enforce prioritization, can still enforce the app performance thresholds like round trip time and transaction successes failures, and give customers the best path. Again, nobody else can do that because we are application defined. We are the only SD WAN solution that can do that.
Max:Let's talk about deployment for a little bit. And we'll start with the branch, and we'll work our way up from there. What does a branch deployment look like with Cloudgenix?
Yash:So we have 2 models on the branch. We have a seamless insertion, what is typically known as a bump in the wire deployment. In that model, when the customer says for for historic reasons, legacy reasons, their MPLS router must stay, and they are running some proprietary VoIP stuff, maybe it's a non Ethernet handoff. We can go seamlessly as a bump in the wire. We say to the customer, you don't even have to change the IP address.
Yash:You don't have to change the routing protocol. We'll go as a bump in the wire, and then we will terminate all the new Internet connections in addition to the existing MPLS connection where we are a bump in the wire at. And now we are able to use all the paths actively, build the VPNs automatically to all the hubs, And and we are now doing, everything what an SD WAN is supposed to do, active active padding, steering traffic to the best path, everything else. At the branch, that is our deployment. If the customer, wants to, deploy a firewall at the branch, which many of our customers do still deploy a physical firewall, typically, the firewall or the WAN acceleration device will go south of Cloudgenix.
Yash:So we will be the we will have the steering wheel for all the wide area networks for the WAN patch, and the other devices, like a firewall or other VAN acceleration, will go south of us. And I should also mention the 2nd deployment. I talked about the bump in the wire deployment. The 2nd deployment, which is, majority of our deployment, is a typical layer 3 deployment where we become the default gateway for all north south traffic. So people can either dynamically or statically route traffic to Cloudgenix.
Yash:And now we are a layer 3 hop. And now we do the same steering across all WAN paths actively and smartly.
Max:Okay. Let's let's get really we're gonna we're gonna geek out here for a minute. So when we look at these things and we talk about physical insertion models, and we talk about that the firewall is south of the device. Right? When I hear that and you say bump in the path, you have an insertion model.
Max:Right? So seamless insertion model. What I'm hearing in my head is that you are taking and, effectively bridging a primary circuit IP addresses through the Cloudgenix and then landing other circuits on Cloudgenix and providing either a double NAT or a proxy NAT or something along those lines. So that way, you can say, you know, we're still using the designated primary circuit and the IP addresses persist, or we need to use a secondary circuit and the IP addresses you know, obviously can't persist because it's not the right path. You know, it's not the it's on network path.
Max:So is that an accurate assumption on my part?
Yash:Yeah. So let's talk about that. So the bump in the wire typically goes for your private LAN circuit. So when you go as a bump in the wire, the closest analogy I can think of is Palo Alto Networks for the longest time had, virtual firewall where you could be you could be a bump in the bump in the wire firewall there. So just like that, it's not truly a switch.
Yash:We are able to intercept the traffic. And based on policy, we don't have to bridge it. We can route it. We can encapsulate it, and we can send it along. But the bump in the wire typically gives customers 2 big advantages.
Yash:1 is their deployment becomes simple without rocking the boat too much because they'll be like, oh, well, I have an MPLS router managed by the provider. I can't really change the IP or change the routing protocol. So that makes it super simple for us to get deployed without making any changes. That's number 1. But the even bigger advantage, which I suppose the business leaders will appreciate, is without an Now I'll I'll talk about the if the question comes to that.
Yash:But even without the in a bump in the wire mode, we give customers a fault tolerance in the sense that if the MPLS router north of us fails, we will automagically take over the IP address and start and and the MAC address of the MPLS router so that now without any changes on the LAN side, maybe there is a legacy printer that doesn't that hates it when the MAC address changes. Like, we all must have seen that in our past networking life. None of that problem happens. And with the same MAC and the same IP, Cloudgenix becomes the default gateway when the router fails. And what happens if the Cloudgenix device fails?
Yash:Even if somebody powers off the Cloudgenix device, the the bump in the wire, it fails to wire. So now the circuit closes, and the branch still stays up on the MPLS. Now granted if the CloudGenix fails, there is no Internet, there is no VPN because you didn't have but the branch is still up. So even with a single device, there is fault tolerance. If the router fails, we got your back.
Yash:If we fail, we still fail in a way that the branch is still up on MPLS. So this is unprecedented, and customer loves us for this fail to wire technology that we have at the branch.
Max:So because we're not sitting in front of a whiteboard, I'm gonna try to keep these scenarios somewhat simple. Right? If we talk about a north south architecture with a firewall behind Cloudgenics, right, that would become the ideal deployment or, you know, Cloudgenics box, the circuits landing on Cloudgenics and then firewall behind Cloudgenics. So primary circuit IP addresses are passed through Cloudgenics to firewall. And then you can take and determine which network link you're sending traffic to.
Max:In that scenario, let's talk about high availability. Right? Because a lot of this comes into, you know, how do you fail over between circuits we've kinda talked about. But now you've got a physical appliance. There's another failure point.
Max:What are your high availability options, and what do people have to consider or think about?
Yash:Yeah. So for this, and and just to keep in line with keeping it simple, what I will say is majority of the customer deploy us in the layer 3 mode and not as a bump in the wire. And that might be simpler for our audience to follow also. So everything everything is the same. Everything what you described was the same.
Yash:Let's assume it's a at Cloudgenix deployed as a layer 3 as a layer 3 hop, not as a bump in the wire. The story becomes easier when it's a bump in the wire, in some sense. But I but the majority of our deployment is layer 3, so I don't want to ignore that use case. The advantage is the fail to wire that I speak of gives the customer something which they're not used to, and I'll tell you what that is. So, traditionally, when you have 2 devices, 2 routers or 2 SD WAN appliances, and let's say you have 2 physical handoffs.
Yash:You have, MPLS cable, CAT 6 cable, drop, and then you have, broadband Ethernet dropper. Now you typically will connect one connection to one appliance, the other connection to the other appliance. And if any one of those appliance fails, a non Cloudgenix router or an SD WAN appliance fails, that means the end of that band circuit that band circuit is gonna go down because that appliance went down. But remember, with Cloudgenix, we have the fail to wire. So what that means is in this deployment, if a Cloudgenix SD WAN appliance fails, even if somebody powers it off or there is a software catastrophic failure, at that point, that device is going to fail to wire the WAN circuit to the other appliance, which means that when a node failure happens, the branch has full forwarding WAN capacity.
Yash:So Cloudgenix gives our customers the advantage that nobody else gives, which is that even when the appliance fails, the customer has no loss in bandwidth. They get the full MPLS and full Internet or or dual Internet or whatever the WAN circuits might be. Everything is available for them.
Max:The only places I really see infrastructure deploying fail to wire in this manner is, like, transparent network taps where, you know, you don't wanna insert a tap in your network and have the tap go down and take your network with you. And so they have, you know, this this this, you know, capacity built into it. And so I was very surprised when I heard that Cloudgenix was doing this because I don't know of anybody else in this space that offers this, you know, as a feature.
Yash:That's right. So that is a unique point. Absolutely correct.
Max:I mean, you know, when I when I look at this, we're talking a little bit about, like, bumping the road and different insertion models and layer 3 versus not. A lot of these decisions come into how do you insert a Cloudgenix appliance into an existing network infrastructure? I mean, if you're dealing with, you know, 100 of sites and, you know, n plus some some permutation, you know, of circuits at those sites and, you know, different amount of technical resources at different locations, desperately, you know, Maybe it's just across the country or across multiple continents. Being able to roll a new network architecture out, you know, as painless as a way as possible, I mean, that becomes a real consideration. So, I mean, are you actually looking at this and going through deployment with your customers saying, you know, this is what you currently have here.
Max:And, you know, in the ideal state, maybe you'd wanna do this architecture. But given what you have and how we're gonna have to roll this thing out, maybe we're gonna do this other model instead because it's gonna re you know, result in less energy, less work, faster time to market. You know, what what does that conversation look like?
Yash:Yeah. And when we talk to our customers, I'm gonna use a very oft quoted acronym, which is ZTP. Right? So and and that that in itself may not be, other SD WAN, may also tell the same thing. Okay.
Yash:We have ZTP, and and so that may not sound like a big differentiating factor when I say that. Zero touch provisioning basically changes the game. I remember this one Pac Northwest customer. They are fully deployed. They are a bank based in the Pac Northwest.
Yash:The main network architect, she would tell me that she hates pizza parties. And I said, what is that? And she said, these are the deployment weekends where we would take in the incumbent routers, and we would hand code all the routers that needs to be shipped to their 348 locations. And then the ATM would get a smaller incumbent router, and then they would have to configure them. And and the all their weekends would go there.
Yash:And now when you compare that with Cloudgenix, we shipped all the devices to their warehouses. Now we could have shipped it directly to their end location, but they preferred that they asset tag it. So we shipped it to their warehouse. They asset tagged it. They shipped it to the branch.
Yash:The branch manager, without a CCIE or any other networking engineering team there, the branch manager plugged the devices in. The device was part of the network. So the deployment becomes pretty pretty simple when you compare it with the routed model. But at this point, I would also say that this is no different from the other SD WAN solution. Other SD WAN is also, to a large extent, plug and play.
Yash:The re the the way we the place where we shine more than anyone else, when it comes to deployment is our automation story. So the so the customer who are going on a DevOps or a NetOps journey, they would love the fact that Cloudgenix has a fully exposed Python SDK. We also have c sharp, JavaScript, and Node. Js, but most customers' de facto standard for DevOps is Python. So they use the Python SDKs.
Yash:We have fully exposed REST APIs as well if they directly want to work with REST. What that means is now the customer can have a full stack on their SD WAN, meaning not just the deployment, but if they want to now make a massive change. They wanna change the DNS. They wanna change the Syslog server. Try try doing that on a massive wide area network on a router based network.
Yash:It is not it is not super hard, but it is not trivial also. With Cloudgenics, it is super, super trivial for us to make these ad move changes to handle automays. I mean, the customers would say that every time a router would fail, they would have to now configure it from their archived config, the latest config, and then snapshot that and paste it and then send it to remote hands. With us, the device just ships directly from factory to this failed device where the branch is, and they would just plug it in. And because the config is stored in the cloud, they would just follow a 3 click automated wizard, and all the config would get pushed to this new device.
Yash:And voila. It's part of the network again with the same config. So it's super simple operationally also to handle these things.
Max:So you're talking about, like, using Napalm with Ansible or SaltStack as an option to be able to configure and manage CloudGenix deployments as at a long you know, at a large scale?
Yash:So so so we don't have a religion there. So whether it's napalm so we do have many customers who use Ansible. But whether it's napalm, whether it's GitHub repository, whether it's some CICD pipeline, what I'm saying is customers have choice, and and we have many, sample scripts that enable customers. We also have, like I said, full SDKs. So if they don't want to use our scripts, they can use our SDKs and do whatever they want with it and whatever platform or DevOps model framework of choice they may have.
Max:Cloudgenix has a lot of financial services and banking customers. Why is that? What is it about Cloudgenix that has resulted in that for you guys?
Yash:In large parts, it is of a security posture. So, so I can't name this customer, but, one of the largest, global bank that is fully well, they are they are deployed on 4,000 locations now. They had a 14 month security cycle. Their GIS, their global infosec team, did a 14 month trial on us and another SD WAN vendor. And we passed, and the the amount of amount of scrutiny that we had at the device level, at the controller level, at the overall solution security level, we are the only vendor that passed all their pen testing, ethical hacking, all their audits, and everything else.
Yash:So so case in point, I'll give you a few simple examples. This was just, neither here nor there. Right? So I'll give you a few things. So for example, I'll start with the VPN.
Yash:The IPsec VPNs that, Cloudgenix builds, they are, by default, banking grade AES 256 bit encrypted. But not only that, the crypto ciphers that we use between the VPNs, they rotate every hour. So, there there are some solutions out there which default to a 128 bit encryption, iC phase 1, iC1, for phase 1. And so compare that with what we do on the VPN side. That's just the data plane side of it.
Yash:There are many other things. For example, we don't have a gateway model. So we don't send our traffic to this unknown black box, which is another attack vector because the the customer doesn't really have this shared gateway model with Cloudgenics. So their traffic always stays in their network, which is true for many banking customers. They don't want their traffic to go to any other third party devices.
Yash:There are a lot more that I can say, but I'm gonna pause here and see if there are any questions.
Max:No. No. No. I mean, so you you mentioned shared gateway models. Right?
Max:So the shared gateway, in a lot of cases, is a technique to allow you to pin traffic to a central location to, you know, to to deal with, you know, like, for instance, UCaaS for voice. Right? You know, you want you don't wanna drop sessions if you drop a network path. And, you know, shared gateway gives you the ability to actually have that traffic transit a specific location so your VoIP traffic doesn't drop and come back up. You know, if you've got an office with a couple hundred phones and you lose a circuit, you don't want every single phone basically rebooting on yourself.
Max:Right? So with Cloudgenix, because you don't have a shared gateway, how do you how do you handle and approach those things where you have, you know, more sensitive SaaS applications that don't like the IP address to change?
Yash:Yeah. No. That's a fair question. And and the the problem there that you speak of is the change in the NAT boundary. When a customer has 2 disparate circuits and if we try to steer the traffic to another circuit, NAT boundary changes, the source IP changes, and the phone reboots, resets.
Yash:That is true for a lot of the voice applications, but that is changing also. So I'll first talk about the application enhancements, which has nothing to do with Cloudgenics. I can't take credit for that. But, an application like Zoom, for example, when you have that on 2 different internets, and it's going on the primary Internet and and if you pull the cable out on the primary Internet, Zoom session stays up. So they figure it out to not break the session, and they are able to keep the session up.
Yash:But there are many other applications that will break. And customers, to your point, they don't want all the phones resetting when that happens. So now when we have a requirement like this, we offer customer, a 2 very simple solution. And it's really the solution doesn't change the overall architecture. We the solution is to solve for the problem at hand, and the problem at hand is just voice traffic.
Yash:So we say, look. Lucky for you, mister customer, we are completely app routing. We are app defined. So we can selectively take those apps which you want to preserve, and and preserve against a NAT boundary change. We can take these voice calls and SIP signaling or whatever, whatever it might be, and we can do one of 2 things.
Yash:We can steer them to your data center through your data center. So if the branch has dual internets and on this dual internets, they have, let's say, 2 2 VPNs to the data center. I'm taking a simple scenario here. So now instead of sending the traffic directly out of the Internet, it goes to a data center. Now the customer may say, well, but my data center is too far away.
Yash:I don't really this is it makes sense to me what you're saying, but I I wish if there was a closer place where I could pin the traffic. If that's the use case, then we can basically figure out the nearest public cloud or an Equinix location, whatever the customer fancies. And then we can spin up a virtual Cloudgenix. Like I said, we are available in all, major public clouds and Equinix. So we are able to now host or or spin up a small instance of Cloudgenics.
Yash:And the only job of this is to have the VPNs for this particular branch and steer the voice traffic off this branch. So just the voice traffic gets goes to this, nearby gateway. So this this gateway is not Cloudgenix gateway, mind you. This is completely managed and controlled by the customer. So my point about us giving customer complete control still applies here because whether it's their data center or their public cloud gateway, it's always the customer who's who's in control.
Yash:It's not a black box, a vendor black box, which the customer has no idea what's happening and who's sharing what resources.
Max:You know, we talk about, like, preserving MPLS or or firewalls at the branch. Do they have to maintain a firewall at the branch? Could they get rid of the firewall and just run Cloudgenix?
Yash:They, we are seeing a lot of that. So, yes. Absolutely. Yes, Max. What the trend that we are seeing in the industry is people want to reduce the hardware footprint at the edges.
Yash:They don't want because the more hardware footprint you have, it's more more opex, and every time there's a problem, you need a bunch of engineers going there. So they want to reduce the hardware footprint at the edges. So, we give customers, basically, the choice and where where the industry is moving towards is the SASE model, where the security services are also cloud delivered. So we have a very tight integration with a lot of, these SASE vendors. And I'll I'll pick on Prisma, for example.
Yash:So we have a one click integration with Palo Alto Prisma. And what that allows our customers to do is instead of having a physical firewall at each of their, you know, 20 or 200 or 2000 locations, now they have the ability to scrub that traffic against threat prevention, malware, URL filtering, what have you. They can do the whole NextGen firewalling in the cloud with, with the likes of Prisma. And that is a trend that we're seeing more and more. And we have a beautiful story there with our Cloud Blades feature.
Max:You know, I'm really excited about this model. And, I I mean, for me, the idea is anytime you can take out a physical box from a location, you're just you've won. You know? Nothing makes me smile more than taking a physical box out of a, you know, deployment. And also just, you know, manageability.
Max:I mean, this is I just don't understand why, you know, more enterprises haven't shifted to this already. I mean, I understand why, but, I mean, I I really do see that this is this is gonna be the only way things are deployed. And as I understand it, when you're talking about a, you know, a Prisma, you know, if you have a branch where everything is not being pinned to to Prisma, you know, you're really just talking about traffic that needs to transit to the Internet. So application traffic, data center traffic, branch to branch traffic, east west traffic, all these different models would stay within the Cloudgenix infrastructure and not touch Prisma. But things that were going to and from the Internet would then transit and touch Prisma.
Max:I mean, that that am I am I stating that correctly?
Yash:You are. But, again, with us, with Cloudgenix, we give customer that choice. So we have some customer that say every single traffic coming out of that branch needs to hit a firewall. And so every traffic goes to, Prisma Cloud, for example. There are many customers who say that, you know what?
Yash:I don't want to send my iTunes traffic and, and my Google, traffic or my real time traffic to to Prisma. So we have and I didn't say this, and maybe this is the time to say it. We have a full app defined zone based firewalling. So right on the edge with a single pane of glass with the Cloudgenix orchestration, you can have security policies that can filter out applications that you don't want. So you so that those are blacklisted applications.
Yash:We can whitelist application and say, you know, these applications, I trust. And these applications, I don't see the need or value to send to a scrubbing engine in the cloud. So send it directly out on the Internet. And then these other applications, this is what you were saying, Max. These other applications, they live in my data center.
Yash:So now I want to use the Cloudgenix VPNs, or AppFabric, as we call it, and send that traffic either branch to branch or branch to data center, send that directly out. And now what remains is a grayless traffic, which is all the user accessing the Internet at that branch. And that user to Internet applications, which are not whitelisted, they are called gray less traffic, and that gray less traffic can go to a SaaSy model to get scrubbed in the cloud. So we support all of that model. It can be all or none.
Yash:It can be, a combin any combination thereof.
Max:So with the date with the cloud with the public cloud, right, you spin up an instance, the public cloud is providing connectivity, you know, you've got resources, you're you're you're fine. Right? So when you start talking about, you know, legacy data centers, And a legacy data center is gonna be connected typically with, you know, point to point circuits or MPLS circuits plus Internet. Right? You know, so this is let's let's just say that as a deployment model.
Max:How does Cloudgenix insert into the data center? Where do you sit in the data center? How do you aggregate massive amounts of branches? I mean, you're talking about, you know, if you have a, you know, here, financial services customer that's got, you know, 4,000 plus branches. I mean, that is a lot of capacity coming back to a relatively, you know, small amount of centralized locations.
Max:You know, how do you what does your scale out model look like in there?
Yash:Yeah. And and it becomes actually more exaggerated for these financial customers who are backhauling all the traffic even today. I say that because for a lot of the customers, a lot of the high-tech customers, and we have a lot of wins there also, a lot of the who's who in the high-tech industry are fully deployed in Cloudgenix, they have bigger, fatter pipes, at the branches. And the aggregation of all of that at the data center, you would think that, oh, it is impossible for any VPN device to aggregate that much bandwidth. But the fact is a lot of these customers are sending traffic directly out on the Internet, so it never really comes to the data center.
Yash:But let me answer the question of where are we deployed at the data center and how do we scale at the data center. So at the data center, our deployment is off path deployment off path. What what that means is we sit, we don't have a whiteboard, so I'm gonna say this as simply as I can. We sit on the side peering with BGP with the data center core and, optionally, if the customer has MPLS edge, then with an MPLS edge. So think of it like a triangle where CloudGenics is one point and the Cloudgenix has a peering relationship with the Van Edge and a peering relationship with the data center core.
Yash:Now and I'm gonna talk about scale and in a bit. But in this triangle relationship, because we are sitting off path Now think about this. In a lot of the other custom a lot of the other SD WAN use cases, when their data center SD WAN goes down, it takes down all the branches that are on that on that solution, on that SD WAN. With Cloudgenix, because we are an off path model, if the single Cloudgenix so let's say there is no if the single Cloudgenix at the data center dies, while all the branches will still have their existing MPLS connection because the Vantage is still there, the data center core is still there, so they can still communicate. The business is still up.
Yash:So our architects have given a lot of thought on how do we deploy at the branch and give customers resiliency, which we talked about. And now we are talking about how do we get deployed at the data center. When we were a startup and we well, we still are a startup. But when we were brand new 4 years ago and we would go to a customer and say, hello. We are Cloudgenics.
Yash:Do you want to install this appliance in your data center? They will say, get lost. We don't want you to be in the center of our universe. But when we offered them a model, which is where we sit on the side and we showed, we proved to them that even if you fail the device, your branches will still stay up on the legacy MPLS. That's where they're like, nobody does that.
Yash:This is great. Now the scale part of it, each device at the data center can do about 5 and a half gigs of encryption. That may or may not be impressive depending on the customer who's listening to this right now, but we have a horizontally scalable model. So the customers who do have a lot of throughput requirement, they have 20 gig, 40 gig, whatever, just like a web farm, you can have stacks of these data center deploy deployed in parallel. So it's like a web farm where you can, horizontally scale to the throughput, that you need.
Max:And what's what's managing that horizontal scale? Are you doing e, you know, ECMP on the BGP peering, or are you actually seeing this within the orchestration layer? These are endpoints, and the branch devices become aware of multiple endpoints, and they're managing themselves of of what to connect to and how to scale out.
Yash:Yeah. No. That's a great question. So we are not doing ECMP. It's pretty smart, and I'll try to explain this simply, without the whiteboard again.
Yash:Let's say that you had 100 branches and you had 2 data center appliances in that one data center. Hundred branches aggregating to 2 data center, devices at the data center. The way our works, the active active works, is, statistically, roughly 50 branches would be active on one device, and the other 50 would be active on the second device. Now each of the 100 branches would have a VPN to both the data center device. So it's not when I say active, what I mean specifically is which device is going to be advertising the BGP to the data center.
Yash:So for 50 branches, only one device advertises the BGP route. And for other 50, the second one advertises the BGP route. So we're not relying on BGP, ECMP. From a BGP standpoint, there is only one source of truth. There's only one place they should be going.
Yash:Because if we did ECMP, we would have all sorts of asymmetry, and a whole bunch of other, problems based on the hashing that the vendor uses on ECMP. And so so, no, we don't use that. We use the model that I described.
Max:So for an enterprise, it's taken and acquired a few cabinets of of data center space to host, critical applications. Right? Maybe that's their ERP, you know, Yardi installation, you know, county, whatever it actually is. Right? You know, maybe this or, you know, if an organization is not, you know, does not have expertise around BGP, will Cloudgenix actually help them configure this?
Max:I mean, how deep will you go into the customer's gear to get this stuff working?
Yash:We give our customers a white glove service. So we we absolutely support, our customers with their deployment, and and and, we have a deployment team as well. So right from the presales to the actual deployment, we are lock and step along with our customers shoulder to shoulder during the the deployment and the planning phase of it?
Max:Deployment timeline. I mean, when you get engaged, obviously, there's a pretty big variety of what the customer's gonna look like, you know, how many branches they have, how dispersed they are, you know, existing MPLS, etcetera. Right? I mean, those all impact decisions. But, you know, if you're talking about a relatively simple look you know, simple deployment, let's say it's it's 20 sites, you know, we're just we're just looking at Internet based optimization and aggregation.
Max:What should somebody expect or kind of anticipate in terms of a project, you know, plan? What does that cycle look like? What's the engagement? What should they be prepared for? Can you walk me through that?
Yash:So realistically, the first branch, the first, maybe the first two branches are usually the slowest because a customer is still getting used to the UI. Our UI is one of the simplest. I don't know if you had the, I should say, the pleasure of, looking at the product demo. But our UI customer raves how simple it is, but it is still different. It is still different than whatever else they may have been used to in the past.
Yash:So the first one or two sites may take a bunch of hours. It can be 2 hours. It can be 4 hours. But once the customer gets used to it I talked about the white glove deployment. So I lead an SE team here, and I always ask my SEs to be on the with the customer when they deploy.
Yash:After the 2 or 2 sites, maybe 3, the customer doesn't even bother calling us. And they're like, oh, yeah. By the way, I deployed these 3 sites over the weekend, and it's like, they don't even have to be there. So device is plugged in, and and in a few minutes, the device is online. So there is definitely a curve, a ramp a a technical curve initially because it's so different.
Yash:It's so new. But it is all said and done, operationally, one of the intangible savings we have in terms of the ROI is how much time it reduces, or or how much time our customers get back when they deploy a solution like ours. So one figure one fact and figure I'll give you is, one of the retail store based in Pac Northwest, our, our one of the earliest customer we have, it used to take them 3 days, so whatever that comes out, to 50 plus hours to do a retail deployment, a full stack retail deployment, which included the wireless, the firewall, the routers for SD WAN, all of that. With Cloudgenix and, of course, their own automation, because it's not just Cloudgenix they're automating, So kudos to their automation team as well. They've now reduced that to less than 4 hours.
Yash:So less than 4 hours, the entire retail store, the entire IT stack comes up. So they call it store in a box, and they are able to roll that out in 4 hour windows. And they have multiple deployment teams that are able to spin up multiple dozens of retail stores. Or if they're upgrading or changing hardware, they can do that multiple dozens a night. So that, is the amount of or that is the kind of benefit that our customers can expect.
Max:I mean, it's hard to quantify that in terms of of, you know, efficiency and flexibility for an organization to make that kind of change. I mean, it's it's it's it's mind boggling when you actually see it in practice of of what you can actually accomplish. There's one more thing that we didn't we didn't talk about and we should we should get into. So, you know, for the enterprise, it has still, you know, an HQ q model with centrally hosted resources at an h q and, you know, some number of remote locations. And I I think manufacturing pretty, you know, comes to mind right away.
Max:Right? So there's not a data center in play, but they're hosting, you know, ERP or manufacturing automation controls or there's an ETL process or something like that, you know, for for orders for their warehouses coming in and out. Now you have things that have to be publicly surfaced from the HQ, not necessarily just to the branches, but to customers and to partners. And there's a requirement for, you know, high availability in that world. If they're deploying Cloudgenics and using Cloudgenics for their HQ and for their branches and for their different locations, you know, what should they expect in terms of, you know, those public resources that are actually being served and hosted to the Internet?
Yash:Yeah. So I'll talk about the most important feature, for this question, which is NAT. But before I do that, every CloudGenix device, when you configure a port to be an Internet port, it's a completely locked down port. So, I mean, I'm stating the obvious here, but I do want to make the point that by default, nothing gets in on the Internet. You can't even ping the interface the Internet interface.
Yash:So everything is blocked. But then you often have these situations like you described where you have a service inside the LAN that needs to be exposed. It could be this manufacturing service. It could be a very common use case is remote access, GP. And now they need to expose the GP service because remember I said the firewall sits south of us, on a branch deployment.
Yash:So we support a very flexible NAT. So NAT is the underpinning of this, the technology that that will allow this to happen. So the flexible NAT that we have, anything that you can do on a modern firewall when it comes to NAT ing, which is, NAT on the ingress, NAT on the egress, source NAT, d NAT, no NAT, a static NAT, all of this is fully supported on Cloudgenix with a very simple, flexible policy. So, again, it's not a device by device config. You now are able to create a policy, and you can say, you know what?
Yash:All my manufacturing sites have this service exposed, and all of this has this local. So we sup obviously, we support local ACLs. So these local local prefix lists are only relevant to these local branches. I don't know how much detail we wanna go into, but this but this is a what you're asking is a very common ask in in some set of our customers, and we are able to deliver that with our flexible NAT policy.
Max:So, you know, multiple circuits, different IP addresses on each circuit, are you defining a NAT policy for each, you know, circuit for each IP address is coming in, you know, facing whatever service you want to publish to the Internet? And then the enterprise is using DNS based traffic distribution with health check, you know, and and something saying, you know, prefer this IP address. And if it goes down, failover here. I mean, is that is that the deployment model?
Yash:It it is. It is. And and to be fair, that that failover is triggered by DNS or by the user agent. Right? If it's a GP, then their GP client then automatically connects to the 2nd IP.
Yash:So that but but, yes, that is not controlled by us because we have, no control on, what is acceptable and what is not. From a service standpoint, we give you the plumbing. We give you the access. We do the the, what's the right word? We we we we open the right pinholes with the security measures for the service to be exposed over the disparate Internet circuits.
Yash:Going from one path to another is controlled more by the application than the agents.
Max:Do you guys ever see models where people are deploying small cloud you know, Cloudgenix appliances at, you know, remote workers, distributed workforce? You know? So like myself, I would sit at my house and and have a box at my house and use that to then, you know, aggregate and connect back?
Yash:So now in this unique situation that we are in with the pandemic, we are seeing that. So this is not unprecedented for us in the in the I mean, the pandemic is, but but the, but the, ask for a home office device in fact, we're just closing a big deal in Phoenix, and their ask is mainly they have these agents who take your travel reservations. And these agents, they tried the softphone and soft agent and and for the business, they hated it. So now they're basically going to go with a Cloudgenix, small device a small fanless device. The agent just plugs in the port.
Yash:All the VPN comes up. And the business says that they also now have ability to put an SLA on the application, on the network uptime. They're able to do get all that with the Cloudgenics orchestration with the UI. So this is an increasing we haven't seen a lot of that, but this is definitely a use case that is on the rise recently.
Max:Now, I mean, you lose a lot of things because I think the the assumption would be a home user does not have more than 1 Internet circuit and is probably a broadband circuit, but they're not failing over between different carriers. So it's you know, you're not you're not necessarily routing around carrier issues, but you are getting manage a bit and recording and prioritization and these sorts of things out of it in a very easy to deploy manner. Right? Where it's you're not trying to configure, you know, software, you know, VPN. It just plug this box in and the box does its thing.
Yash:Exactly. Exactly right. So it's not about, active active or anything like that. It's more about everything what you said, prioritization, classification, visibility. Sometimes, even if you have one path, you have one broadband path, and this might be interesting to you on the technical side, one path and you would think, well, what what can an SD WAN solution do?
Yash:It's only one path at the end of the day. Well, what if this particular customer has 2 data centers, 1 on the East Coast, 1 on the West Coast? And this has happened with many of our enterprise customer. But what if this agent is using their corporate email as I'm just gonna pick on Google for now. Let's say it's Gmail.
Yash:That's the corporate email. Gmail is having a problem. It's having an app brownout on the local Internet this agent has. So she's trying her best to to be effective, to be productive, but her email doesn't work because her local broadband provider has a peering problem with Google. That's an application brownout.
Yash:No SD WAN can do anything about it. We are going to detect that that's happening. We're going to then backhaul just Google Gmail traffic over to the VPN to either the East Coast or the West Coast based on wherever she is, wherever is the active data center or primary data center for her. And we will then be able to backhaul just Gmail traffic over to the data center. Data center's Internet, would not be having this Google Brownout situation.
Yash:Problem resolved. So this is that again. I'm tying it back to the app Brownout, the app health, that so even on a single path, you have multiple logical paths, underlay path and do overlay paths. And we are still able to do path selection, on this single path.
Max:That's awesome. So really, what you're saying is the network team would have to configure this within Cloudgenix. This isn't just an automated thing. But you would say, you know, for Gmail, you can connect directly or, you know, here's our data center paths or here's our, you know, Cloud hosted appliance paths. Appliance isn't the right word.
Max:Cloud hosted instance paths. And, you know, if Gmail gets wonky on a direct path, send it somewhere else.
Yash:You're right. But it's not that much also. Meaning that by default, our policies, you can say something like, you know what? All SaaS traffic, I want to go directly out on the Internet. But as a backup, just as a backup, if things go south on you, use the VPNs.
Yash:That's all you have to so you have to provide the intent, and the intent doesn't have to be per app. You can make it per app. You can make it as granular granular and say, you know what? Google Docs is not allowed to be backhauled, but, Gmail is. So you can go that granular, but you don't have to.
Yash:So our customers can do as much work or as little work in terms of configuration as they desire.
Max:And this is something you guys are gonna do with the customer as you're doing deployment. You know, help them deploy these rules and figure out the defaults and say, hey. You know, this is we really think you should do these sorts of things. Like, you know, save yourself some aggravation down the road.
Yash:Which is why also the first one or 2 sites take, a a few hours, like I said, because these are the things we discover, and we we give them feedback, and they ask us questions, and we say, okay. Here's why. And so yep. Exactly right. We do help them out with, with all this.
Max:Yash, thank you very much. I'll leave the last question to you. Is there anything that we haven't touched on that you think we should we should hit before we wrap?
Yash:What I would ask for the audience, if if they are interested in what they heard so far, and some of them might even be in disbelief. Ah, this is this is not this certainly cannot be true. What I would ask or even challenge is to take a peek at our solution, request a demo because I can say whatever I want here, Max. The reality is unless the customer sees it live, either in a demo or in their own environment, that's when they are a believer. Right?
Yash:That's why we have 27% of the Fortune 1,000 customers that are fully deployed on Cloudgenix. So we are very, very proud of our logos and our customer wins.
Max:Awesome. Thank you very much.
Yash:Thank you, Max.
