Season 1, Episode 6: "How did they adopt SD-WAN so fast?" with Anshuman Awasthi, Director of Infrastructure, Engineering @ Leading Retailer

Anshu: Right now, I think we are kind of moving towards disintegration.

Speaker 2: How have you enabled your infrastructure fundamental change over the last five years at partnering with a business this critical? The tools exist on the cloud change at the rate necessary, secure by design, inaudible

Andrew: Hey, it's Andrew, and welcome to Network Disrupted where IT leaders talk about navigating the disruption in our industry. In this episode, we talk about a leading retailer's journey to adopting SD- WAN before it gained the market traction we see today. My guest today is Anshu Ashwathi, Director of Infrastructure and Engineering at a publicly traded leading retailer based in California, whose legal team won't really let me say their name. Here is a hint. They sell very nice furniture. Anshu's company was an early adopter of SD- WAN before its value was well- defined. We talked about how and why they did that. Let me know your thoughts on this episode. You can tweet me @ networkdisrupted, leave a review on Spotify or Apple podcast, or email me at andrewatnetworkdisrupted. com. Anshu, as we were talking, you you've gone through a bit of a journey over the last couple of years in terms of changing the basic WAN architecture. I know I believe a lot of that was driven by some of the changing requirements at retail stores. Maybe we could start by just give me like a little bit of a synopsis of what's actually changing.

Anshu: Well, I think first of all, the requirement at the stores is changing in terms of driving the business. I mean, the reliability aspect is changing. It used to be that, okay, if the online connection is up, we can do this work; but if it is offline, then I guess all the stores have certain measures to even work offline. But right now, first of all, being online is a necessity. I mean, it's not the luxury anymore. If you are offline, you cannot transact at all. The second app aspect is the requirement of bandwidth. Earlier, it used to be that," Okay, I have some sort of connection. That's okay." But right now I need the whatever largest bandwidth is available because I'm going to download some rich media content for the same transaction. I have to interact with different entities, all of them located across different regions, maybe continent. I'm not going to a single destination anymore. I'm going to multiple destinations to do the same transaction.

Andrew: Right. I would imagine your traditional WAN or what you've moved off of was sort of focused on back call to data center as opposed to direct internet access?

Anshu: Exactly, right. I mean, I think there was an era when everything was focused on integration. You integrate everything because that's in one site, you have your infrastructure where you can have your security, your compute and storage, and you think that you can control the access in a certain way. That kind of worked well in that scenario. As I said, at that time, there was not a huge requirement of the bandwidth or the performance. Everybody was just happy that it's online with the internet boom. But I think slowly as we intend to rely more and more on that, then I guess the performance came in a big way." Hey, I want to go online, but speed is a concern for me. I want to download more and more content and customer is here with me. I want to do it faster." The whole idea of back hauling is kind of slowly fading away and especially the industry movement towards the cloud, made it almost impossible to drive on that back haul hub- and- spoke architecture. Right now I think we are kind of moving towards disintegration. The more disintegrated you are, then you can say that" I don't have any single point of failures. I have multiple hops to go out, I have multiple hops to come in. If I have an outage on one side, the other sides are completely operating. They are independent." I think disintegration is the key right now.

Andrew: Right. With disintegration, I think the other side of that, which is what vendors have been out there trying to solve for is if I have the more complicated the configuration is at any branch or any retail store, for instance, then the more expertise I need or the more management needs to go into ensuring that those branches are connected. I think part of what your transformation was also to go to SD- WAN type deployment architecture so that you could have ease of deployment and ease of management, which wouldn't have existed years ago. Is that correct?

Anshu: That is absolutely right. I think you are right on that topic. One advantage of the integration was that, okay, you are focused on one side and you are going to have hiring team members who are focused on one side, in one location, they have just one problem to solve. Now you are disintegrated, how you're going to solve the network of one site versus a hundred sites? How you're going to control the configuration management, the security policies, maybe DNS and DSCB policies? The more disintegrated you are, there are chances that you have one sort of management control on a few sides, another sort of management on the other side. I think it opens up a sort of door for a whole lot of more complexities so the idea of going toward SD- WAN or going towards controlled access is, I think, the templatization right. I think that kind of started with, I say, a leading technologies who are controlling wireless infrastructure. You don't have to have a wireless controller inside your network. It can be on the cloud and you can templatize it. I think that's where it gets started and I think that's when people started getting the idea of where you can basically control your network even from the cloud, I think. That's when, I think, the start of the development of controlling your networks from outside your network. That idea got started and you can templatize it saying that you just need one connection, you connect to a controller which is located outside, it downloads the configuration. No matter you have 10 sites, 20 sites, it's going to have the same configuration and you can make a change by just one click because the controller will push the change and all the sites will have the same policies, same configuration, and you can have the similar control. You can feel that I just make one change, but it kind of started a chain and all 40 sites are adopted to change.

Andrew: Yeah, for sure. Personally, I've seen it and had many discussions on more and more adoption, especially in places that are outside of the core data center for cloud- managed services. I've been investing in it for quite some time and think it's obviously not a fad. The the network is being extended to the cloud. The difference between the networks running in the cloud or on premises is dissolving to the point where it's not that different anymore where the controller is. In fact, maybe one day people would say, why would you have a local controller in a data center to configure the networks on the cloud? One day it will shift, I think. Back to the actual decision and implementation in that process, was this one of the cases where the existing WAN topology wasn't meeting the requirements to the point where the business was demanding something different, or was this a strategy sort of led by IT in terms there's a better way to do this, let's make a proposal to the business? How did the momentum start for making such a big change?

Anshu: As I'm associated with the retail industry, there are different sort of retail business. One is there a lot of cash and carry and a lot of transactions versus the size of the transaction in terms of the package. Then, there are certain sort of business where bandwidth is an important concern and also a number of transactions are. I think we are in a space where bandwidth is a concern for us because the way we do the businesses, we are heavily dependent on the bandwidth availability at the site, and also the reliability. We were seeing trends on the old technology as we were on the traditional MPLS network that it is reliable. But it is definitely not solving the need of the capacity. Also, if you want to upgrade, you got to invest a lot of money and multiply that to all of the sites that you have to get that bandwidth. We were always looking for new technologies that are available in the market, and we were one of the earlier adapters the SD- WAN.

Andrew: Got it. As an early adopter, did you know what you were looking for? In other words, did you know how to evaluate the market and know what requirements were critical to the business? This is just something from personal experience. I always note that oftentimes as a vendor, we might get like a RFP and the RFP represents what the prospects thinks their requirements are, and in many cases, how they think they want to solve it. Sometimes it leaves out the ability to compete around that because their requirements might be predefined. I think when things are new, like what's happened with SD- WAN over the last several years, you see this acceleration and what the different vendors are bringing to market. I'm just curious how you thought of the process to evaluate what you needed.

Anshu: I think at that point you are right. Especially right now, there are a lot of documents that are available on how to evaluate your SD- WAN, how to go step by step. I mean, do's and don'ts. But at that time, it was fairly new. There were only three or four players in the market so we didn't have a handbook to go by. But we definitely knew what we want. We can test the outcomes of the technology. We don't have a grasp of how it's working, but we know what we want in terms of the output. We prepared a list of a nice- to- have features and must have features. As I said in my earlier answer that you need to provide good performance on the same connection. As you say that in a traditional network, if you, let's say, if you have a 10 megabit circuit, and if you compare the performance, you may get 50% out of it, depending on where your hub and spoke is. You lost that that performance by the sheer physical distance between your hub and spoke. When we test SD-WAN at the same location, you know that if you're not getting a hundred percent, at least you get the 90% because you are a wide back calling. Based on that, we prepared a list of our must have features like performance, then some nice to have things like, okay, can it provide me some data when the link goes down? I mean, how intelligently it can switch to the other links? How much time does it take? Based on our problems that we were facing in the previous architecture, we prepared a list of must have that what are our possible solutions, then where this technology stand. We kind of evaluated on that. At the same time, I think we worked with a partner because there were a lot of partners available in the market. They were looking for some customers like that. Hey, what do you need so that they can make a change and make their product better. I think it was a good partnership at that point and both of us got the benefit.

Andrew: Yeah, right. I think you're dead on. I mean, that's a positive about adopting early, as you can help influence where a vendor is going with something based on your feedback specifically. How did you think about... One of the other things I discuss a lot is just some things work really well in the lab, that doesn't mean you tie this to your whole fleet of retail stores and it works at scale. How do you think in terms of like a proof of concept? How do you determine if something's going to in the lab and now it's going to work at scale? Or like I like to say, when you use it in anger, is it really going to meet your requirements?

Anshu: All right. I think in this case, what I would say is, a lot of time as a technology partner doesn't involve the business or other support functions. I think with some assumptions that," Hey, they don't understand the technology." I think that's where we should learn to involve our partners in the, at least in the final evaluation. I think in the beginning stage, we did a POC in a very controlled environment and, as I said, prepared a list of must have, nice to have, evaluated that, evaluated and recorded some time, requested the partner to make the change. But slowly, once we are getting to a place where we want to put it in a production site, we involve our partners. Like, let's say, I'm from an engineering team. We involve our support center team and someone from the store operations. That," Here, what's your feedback and what are the problems you have seen. Here I have a lab environment, what is the point let's say, I am missing? I mean, they will provide a completely different view of the situation that you're just not thinking. I think it's important to involve your partners, your business in that. Get their opinion before you kind of sign off on a POC.

Andrew: Yeah, no, for sure. Part of that, and you just talked about the different teams that are stakeholders and whether that's operations, whether it's operations on the corporate side or the retail side, obviously another stakeholder is the security team. And one thing for sure, when we switch WAN architectures and start breaking out directly to the internet for more and more sites, things aren't back hauling to the data center. That means they're probably not going through the data center's security architecture. You've got to figure out what to do with that. I would imagine the security team was quite a stakeholder in the process. I'm curious how you thought about securing the traffic without this back haul. What were your approaches or how did you sort of evaluate what the requirements were?

Anshu: Yeah, sure. You're absolutely right. That's one of the, I will say, a loophole in disintegrating is that right now you're relying on your partner or your security team to give you some points on what changes you've got to make in order to adapt to SD- WAN. At that time, I think even the vendors were kind of coming up or they were struggling with how to bring in the security in their device. At that time, we suggested our vendors to include some sort of ACL's, which eventually turned out to be a zone- based firewall in a lot of the devices. Obviously our retail locations need to have secure zone. They need to have a secure zone to do their transaction in the business. It was a must to have a feature in the technology before we even go live with it. We adapted a zone- based restriction in the device itself. We are in a one secure zone, cannot talk to the other secure zone. Also, some side of white listing with our CDN partner so that only trusted IPs are allowed to communicate. Also, you can run some scans, you can involve a third party to scan their device, to ensure there are no vulnerabilities. All sort of these measures were adopted. I think right now, the whole SD- WAN technology are moving in the right direction. Right now, security on the cloud is available. A lot of consumers are adopting to that wherein your whole security stack is not in your premises, whereas it is just disintegrated.

Andrew: Yeah, I know. Gartner calls it this idea the SASE. The secure access service edge which is basically the SD- WAN vendors in the cloud security network, security vendors, each growing into the other space and combining these functions. I always wonder if that's a good thing. On paper, for sure, like you just said. I want to provide a faster, cheaper, more reliable, direct internet access because I depend on the internet, and I want it to be secure. Now, I can go to one vendor and get all of that. But you're also, there's a lot of eggs going to that one vendor's basket. You might be disintegrated, but you're buying a highly- integrated stack from a single vendor. I don't know. Is that something that enters your mind when you're through these decision- making processes? Like having sometimes more than one vendor good, because one, they're competing for each other space, but two, it's best to breed versus one- stop shopping.

Anshu: Yeah, definitely, it comes to our mind when we sort of choose the partner. I think the beauty of the cloud is you can have two technologies. There is no sort of big commitment that you have to make like three years, four years. When you have bought something on premises, you are making a commitment for three, four years, not for the cloud. You can have two different vendors. With one, you can have 30% of the traffic; the other one, maybe doing 70% based on the confidence that you have. With SD-WAN, you can maneuver what is coming up slowly, the API integration, where I'm not dependent on a vendor or the technology that I want to choose. The same vendor have API integrations with different vendors. I can choose one vendor. If I'm not happy with it in the same contract timeline, I can choose the other vendor. But I think there is a lot of flexibility, definitely, with SD- WAN and cloud architecture is coming up.

Andrew: I guess that's exactly my point because, I mean, one of the beauties of an SD- WAN topology is you've given yourself a platform where you can make rapid changes across a complicated WAN and steer traffic to provider A, provider B, whatever the case might be. A large integrated solution where all of that comes together, maybe you lose some of the beauty of this at the core with a software- defined WAN. Because you're now tying into these other things so you maybe have less capability to switch between different things. I think that's critical to keep. Maybe it's just the way I think because I love the part of the SD- WAN router that really speaks to me is I now have something where I'm not locked in. I might be locked into a specific vendor's router, fine, but I'm given myself the ability to make the other dependency changes much faster, which is a good thing. I'm curious to see how that whole idea of this SASE cloud is going to play out because I think it might be too big. I'm curious, was there a benefit that you got from deploying that you weren't expecting? Were there some great surprises in the success of this project that weren't necessarily part of the plan? Or did you just sort of get what you paid for?

Anshu: I think I will say ease of management is definitely a surprise. We were not thinking about it, that it will help us that much. I mean, because as you were the earlier adopters, we were kind of more doing it to improve the performance of the galleries. We were not looking at how easy it will be to manage it. That definitely came a big surprise. When we were looking at it, we were more concerned about the technology and the performance aspect of it. But when we put that into the network, I think we don't invest a lot of time in making changes in the configuration daily. I mean, it has streamlined it so much that once when the change comes in, let's say, a new application, we have to adapt and you have to test it, which is not related to SD-WAN, but a change in the business.

Andrew: That great. Then, I guess I'll ask the other question. Was there something that you didn't plan for?

Anshu: Yeah, absolutely. I think even when will adapt to it or, let's say, an organization who has a big investment on the traditional network, and now you're adapting SD- WAN, you're not going to do it in one shot. That all of your network is right now in SD-WAN. You're going to do it slowly and somewhere your traditional network and the SD- WAN got to meet together. They need to exchange their hours. They need to exchange their configuration so that one network is going to talk to the other. I think that's where a lot of folks will have a challenge. Where do they meet? What sort of configuration changes they need to make. And let's say if one of the side goes down in a traditional lab work, can it talk to the SD-WAN side or it cannot? There are some unknowns in that area, unless you move completely on the SD- WAN. I think that's where the partnership will come in handy and the experience from your SD-WAN partner release out the process.

Andrew: It's funny that you bring up that example because I was talking to one of our customers recently, and that was exactly the example she brought up in terms of an area that sort of failed to think about and plan for. It's just moving away from... well, not moving away from, because I think a lot of this is coming back as these platforms mature, but exchanging routes wasn't a problem anymore. Now, all of a sudden, it became a problem again. So this went live a couple of years ago. Imagine you're in the midst of a bunch of other projects. What's exciting to you now? What's the project du jour? What are you out there disrupting?

Anshu: I think, as I said, we are in process of adapting to the firewall on the cloud, changing the way we connect internally. When I say internally is, I think, software defined WAN was one thing. Now, thing that's becoming popular is the software defined access. We are evaluating that internally. Kind of making everyone's life more efficient so that network is not a concern to anyone, and making possible for everyone to do their business efficiently.

Andrew: Right, great. It's interesting because this whole obviously notion of SDN in general has been around for quite some time. I don't know where there's been more of a impact in SDN approaches than SD-WAN. Of course, it's coming, we're trying to drive it inside the core network as well and not just the WAN boundaries. I always think that the reason it was more adoptable to WAN was you're not... we always have this greenfield brownfield problem internally where, okay, that seems great if I didn't already have an internal network. I think it's easier. There's less dependencies to switch out a WAN topology than there is to switch out all of my switches internally, or I'm going to segment networks differently, or there's things in flow and more of the existing infrastructure impacts what I want to change to. We do these large migrations with our customers and you get to areas inside of a network where nobody really quite knows why things were configured that way because it was configured that way for so many years. And so it becomes more complicated to change. I don't know if that's something you're experiencing. There's a lot of lessons learned there and I think a lot of your peers, well, I know a lot of your peers are going through similar decision making processes, trying to figure out what are the core set of must haves and how should we evaluate vendors and how do we move forward with something that's to meet our business needs. Thank you very much for spending the time.

Anshu: Thank you for having me. Thank you.

Andrew: Thank you for listening. I'd love to know what you thought of this episode and I'm all ears if you have a guest recommendation, you can tweet @ networkdisrupted, leave a review on Spotify or Apple podcasts, or e-mail me at andrew @ networkdisrupted. com.