What To Ask Your Vendor on Enterprise SD-WAN Capabilities
What are the absolute essential requirements in an SD-WAN solution? Although Gartner has defined the four key requirements for SD-WAN (see below), there are some more critical features required to meet the enterprise-grade capabilities. For example, network segmentation for different kinds of applications is a widely deployed feature across all major industries, primarily to isolate critical applications and to reduce the attack surface during vulnerabilities.
This webinar will more broadly cover the essential enterprise SD-WAN features and how they translate to common deployment scenarios in different industries. These features include:
- Overlay capability over MPLS, Broadband and LTE
- Unified and centralized management of all WAN infrastructure
- Network segmentation with per-segment topologies
- Predictable Application SLA with centralized policies and real-time traffic steering
- Mature routing capabilities with BGP, OSPF, VRRP, and IGMP
- Unified and centralized management of all WAN infrastructure
- Robust-zero trust WAN security including authentication, encryptions, segmentation and service chaining
As a background, here are Gartner’s four key requirements for SD-WAN:
- SD-WAN solutions provide a lightweight replacement for traditional WAN routers, and are agnostic to WAN transport technologies (that is, they support MPLS, Internet, Long Term Evolution [LTE], etc.).
- Based on business and/or application policies, SD-WAN solutions allow for load sharing of traffic across multiple WAN connections in an efficient and dynamic fashion.
- SD-WAN solutions dramatically simplify the complexity associated with management, configuration and orchestration of WANs.
- SD-WAN solutions must provide secure VPNs, and have the ability to integrate additional network services and offload Internet-destined traffic closer to the edge of the network.
Ramesh Prabagaran has a track record of bringing disruptive and innovative networking products to market focused on carriers and enterprises. Most recently at Juniper Networks, he was a senior product line manager establishing the product vision for enterprise and datacenter routing products (M and MX Series), and WAN-focused solutions for Fortune 100 companies.
What To Ask Your Vendor on Enterprise SD-WAN Capabilities
Lloyd: Hello, everybody. Thank you so much for joining this FutureWAN session. The topic today is what to ask your SDWAN vendor and the presenter is Ramesh Prabagaran who is the VP of Product Management at Viptela. Before we start I just want to go through a few housekeeping items – the presentation that you’re seeing today is available for download. Just go to the attachment and links sections and download it.
In addition to that on the same download page you have a peer insight survey. This is a survey that the networking and users are filling out. I encourage you to fill out that survey, as a result of which you’ll be able to see the results of all your peers on the issues they are facing on the WAN.
The other important item is the conversation around enterprise SDWAN. We want you to ask your questions in the Q&A box but feel free to also get on Twitter and start a conversation asking your questions and the other people on these sessions, both the presenters and attendees will get on it and answer your questions. So with that I want to turn it over Ramesh Prabagaran; Ramesh?
Ramesh: Thank you, Lloyd, and thank you everyone for joining today. SDWAN has certainly been on a tear. Lots of inbound requests and customer activity, actual deployments, and it’s naturally as a result at the peak of expectations from a Gartner standpoint. I want to do a couple of things today. One, talk about why is it that a vendor is talking about what questions to ask a vendor. I’m sure that’s a top-of-mind question for all of you so let’s talk a little bit about that. Then I want to walk through a framework for how you should evaluate SDWAN, an enterprise class SDWAN in particular. So with that let’s get right into the meat of the session.
So the motivation here is really around three aspects – one is around what is it that’s being told out there by various vendors, ie. marketing, and then what is the reality. Now, having gone through multiple hundreds of deployments and a few tens of thousands of sites deployed out there we can tell you that it’s not as rosy as it seems. More specifically, it’s not that you can stand in a golf course and operationalize your entire infrastructure from Day-0, right from there. It’s not about taking a couple of devices, shipping them out to a location, plugging them in and your entire network is up and running. There is a certain amount of due diligence that needs to happen before you do that and we’ll just walk through what that looks like, and then the end result could be essentially you in a golf course trying to operationalize your entire infrastructure, so that’s number one.
The second one is it’s a very noisy market. I think the last count from Gartner was roughly about 20 vendors in this particular space. Certainly, as the market has matured so have the vendors, and it’s consolidated down to maybe two or three vendors that have real life deployments and real world use cases as well, so we’ll talk about what – again, how should you weed out the noise, what should you be looking for across the spectrum as well.
And then finally an area that’s probably near and dear to your hearts around how do you balance out innovation versus risk. This is probably one of the top questions that we hear from prospects and customers – how do I keep the lights on versus how do I focus on innovation? And once again we’ll walk through a framework for how you should think about it and how should you operationalize this infrastructure as well.
So with that let me talk a little bit about the framework itself. So we’ve broken this down into six or seven different components for what you should look at from an enterprise class SDWAN standpoint. First and foremost, as boring as it sounds, you need to think about a transport strategy. The fundamental shift that’s happening as a result of SDWAN is a move from what used to be an all-private infrastructure into a hybrid environment.
With hybrid comes a private connection, public infrastructure like broadband and internet and also LTE, so you need to be wary of a few things around that, especially as it relates to provider relationships, what that means for connectivity and so forth. We’ll double click on each of these topics.
The second big piece is around application assurance. Ultimately, at the end of the day, your CIO cares about how do I connect users to applications and what kind of an experience can you provide to those users and to those applications? And so the network needs to be fundamentally application-aware and there are a few things you need to be aware of in order to make that happen.
Talking about, again, trends and applications – cloud is a pretty big thing. Not a single hour goes by where a customer doesn’t reach out and say, “Hey, you know what? I’m going through this transformation either from my on-premise data centers into a SaaS-based platform, “because Office 365 is way better than a hosted exchange or it could be, “Hey, I’m moving my applications from on-prem data centers into an AWS or an Azure-type infrastructure as well, so what are the considerations? How should I take care of connectivity? How do I make sure my network is cloud-ready?” and we need to be really, really focused on it’s not about how do you consume this technology, ie. cloud-delivered, but rather how do I make my network cloud-ready as well.
A few other things around operations – interoperability, Day-0, Day-2 operations – we’ll talk about some of the questions that you can ask there, and importantly, the consumption model. Can I do this in-house, ie. do it yourself or do I need to get this through another service provider? It could be an integrator, it could be a managed service provider, what are the questions I should ask and how should I think about this as well? So those are kind of the main themes that we’ll be walking through today and we’ll take each one of these themes and talk about them in a good amount of detail as well.
So we’ll take the first one which is really around transport strategy. It’s interesting – it’s one of those areas where there’s quite a bit of marketing hype as well around, hey, the world is moving over to internet and internet is unreliable, and so you need to worry about optimization techniques and so forth. There is an element of reality to that but it’s far from what I would call as truth.
The second one is really around availability. Enterprises historically have built networks with three 9s or five 9s of availability end to end and what we are seeing is a shift towards kind of best of breed. I want some portions of my infrastructure to be five 9s available, I want some of them to be really high bandwidth – I don’t care as much about availability there – I just want to make sure that I can shove bits on one end and it reaches the other end, and so you need to be conscious of some of those trends.
How do you deal with the provider landscape and specifically on LTE? How should I think about it? This is an area that freaks a lot of our customers out, especially as you start to talk about LTE as a backup circuit or a tertiary circuit. How do I take care of usage? What kind of a contract should I have and so forth?
So now let’s double click on what are some of these questions, and as you can see since the nature of the session is what should you be asking your SDWAN vendor, the content that you see on the slide is inherently going to be a little text-oriented and so let’s just walk through – within the context of transport strategy what are the things that you should be worried about?
The first thing is really around can I mix and match MPLS broadband LTE, and naturally every vendor out there will come out and say, yes, but the real question to ask is can I have some sites on just pure MPLS, some on hybrid, some on just maybe pure LTE, and if so what does the fabric kind of look like? What does the wide area infrastructure look like and who is responsible for connecting the dots and gluing everything together?
Does the technology inherently provide you with those capabilities or should you look at adding policies here and there in order to make this happen? A rather key theme that we see multiple customers of ours kind of ask right up front, and it’s a very important question to go through as well.
The second element is really around your choice of providers. With this whole notion of SDWAN you have the ability now to break a global provider landscape into some parts of regional providers. So you can say, “Hey, I want to have best of breed providers and I want to build the equivalent of a backbone that connects everything together.” All of these are inherent in the technology so you don’t need to build a backbone, per se, but it’s just how you think about your provider landscape.
Do I need to go with one or do I need to go with many, and if I need to go with many then can I still have the ability of getting a single bill – all of those things kind of come into the picture. I’m intentionally avoiding answering the question and making this a Viptela marketing session. I’m just going to leave this as, here are the questions that you should be asking and kind of walk through what that means for your specific infrastructure.
The other set of questions that we hear time and again are really around the equipment itself that’s going to sit on site. First off is it going to be physical, is it going to be virtual, and if it is going to be physical then what other equipment do I need? If I’m going to terminate an MPLS connection, a couple of broadband circuits and 4G LTE, then do I need the equivalent of a modem or a CPE or an NTE demarcation point for each one of them? In which case my CPE is now going to be connecting into four different other devices. If so then who is going to manage them and so forth, and so that’s an important question to ask.
There are capabilities – there are technologies available out there so that you can fundamentally integrate those natively into a single platform so that you can consume this in a very simple way. And some customers are okay having that line of delineation whereby a transporter could get terminated at one location and then you naturally extend the infrastructure all the way up to the CPE, so it’s a question that you need to be aware of as well.
On the topic of LTE in particular you need to be wary of usage, and we all use mobile phones and so we are quite aware of this, but in an enterprise world, especially as you start to talk about the circuit of last resort or keeping LTE circuit on but in a dormant state, you need to be really, really aware of the usage. Most of the SDWAN providers do some kind of probing mechanism but they do not distinguish between fixed versus wireless, in which case the frequency at which you send those probes may really eat into your global pool of bandwidth and usage, and so you need to be aware of how do I reduce that? Can I really trim it down so that the overhead is less than 1 percent of my overall infrastructure usage, and so again, a discussion that you want to absolutely double click on?
Very closely associated with that is what do I need to do for single attached circuits versus multi-attached? We’ve seen across the deployment more than – I would say 98, 99 percent of the cases – there are a couple of circuits which means they’re inherently multi-attached and so many of the transport optimization capabilities that vendors would throw at you may not be as apparent and as relevant as well, and so you need to be aware of, “Hey, do I need these capabilities if I have multiple circuits? If so should I be able to choose the best path based on the available circuits, or if I have a single attached circuit then is that when I need to be able to fix a few things in the underlying transport?”
And so once again, just from a transport strategy as you can see, there are a few things to worry about all the way from choice of providers to what is it that you need to look for in terms of connecting sites, global versus regional and also LTE as well. So those are again some of the things to be aware of.
The second big piece – and this is a piece that we spend quite a bit of time with our customers on – is around application assurance. And closely associated with that is compliance. So we’ve kind of broken that down into four main buckets. First is around visibility. Many of the customers want to know what is happening inside of their infrastructure. Can I get visibility into what’s happening at the macro level and then on an application basis? Then at a site level and then maybe at the regional level and so forth, and so you need to be able to kind of zoom in and zoom out based on what kind of applications you are really using.
And then once you know what is really happening in your underlying network then you need to be able to extrapolate. Can I kind of trend these applications? Am I going to hit a wall in three to six months if the application kind of grows in usage as it has in the last few weeks, and so you need to be able to do some trending analysis and the infrastructure should be able to provide you with some information on what that looks like as well.
Many of our customers have asked, can you give us a before and after picture for application assurance? More specifically, what did it look like before my policies were implemented and before I had dual circuits and so forth to what does it look like after? It’s really key because that kind of also helps you make a case if you want the providers up your management chain as well.
We have seen many customers use this very effectively. Some have outrightly called out, “Hey, I can get a 4X improvement in my application performance,” some actually have gone up to like 12X as well. And so your answer could be largely dependent on the kind of circuits you use, what kind of policies you have and what kind of applications you have, but being able to quantify that is going to be extremely important and the guts of that needs to be provided by the underlying technology and the solution as well.
Another one is really around SLAs and we have seen a wide variety of these across the vendor landscape. Some have just very simply classified this into a gold, silver, bronze or a high, medium, low and just bucketing various applications into them. That may be useful for a really simplified SMB-type use case but most of the enterprise customers – in fact every enterprise customer that we have wants to be able to fine tune that because I have regions that are geographically separate and distant from where the applications reside, and so I cannot have a simple policy that says I need to have this application as gold because gold could mean different things in APAC versus EMEA, and I need the ability to kind of regionalize them, and at the same time set thresholds as well.
So it could be that WebEx, as an example, could be tolerant up to 200 milliseconds of latency in some regions, while if I’m going over a really poor underlying circuit then that may not be the case, and so you need to be able to fine tune the application SLA based on your specific requirements. And we have seen customers use this in a very effective way towards their deployment as well.
A few things around compliance – as we all know you start with a clean piece of paper, put networking devices and circuits there and it all looks very clean. The minute you layer four to seven appliances, especially firewalls and WAN optimization devices and whatnot, you have to deal with asymmetric routing, you have to deal with – there’s a whole host of networking complexity.
So the short answer is how can that be simplified? You don’t want to compromise on the need for compliance because that would be a big nono for your CISO. Can I do some kind of service training? Can I make sure that I segment my applications? We have seen customers segment their applications for a variety of reasons. To reduce the fault domain, in some cases it’s to reduce the blast radius, in some cases it’s just purely for compliance. I need to be able to segment our credit card transactions from guest Wi-Fi because the requirements are very different. Ultimately, you need to be aware of the way these applications, the compliance requirements of each, and then be able to operationalize that infrastructure.
Now, with respect to operations we have seen customers kind of use this in a very interesting way. The Mean-Time-To-Innocence – how long before I can make sure that fingers don’t point at the networking guy; it can point at the application guy, so that’s kind of – so the Mean-Time-To-Innocence capability that you need for your applications as well. So once again, application assurance and compliance, very critical that you need to be thinking about how much control do you want to have over that.
The next piece of it is around cloud readiness and we’ve seen a lot of the CIOs kind of use this as the reason for why they want to go towards SDWAN, and cloud is not a single cloud. Cloud means different things to different people so we have kind of segmented that into two parts. One is can you have your infrastructure be cloud-ready, and the second piece is can I consume the SDWAN technology in a cloud-delivered fashion?
So if you look at making sure your network is cloud-ready you need to be thinking about infrastructure as a service or PaaS, different from SaaS. Office 365 works very differently than AWS. In one case you can have a presence inside. Your application is sitting deep inside the infrastructure. In the other case it’s actually your application isn’t pointing to a URL and you don’t know where any of those things reside.
And so you need to be cognizant of where are the applications, how do I access it? If I’m using a hybrid network to access the applications where should be my cloud exit point and how do I make sure that the telemetry, all the way from the device to the application is factored in irrespective of where you sit in the network, right, and so those are all fundamental things to worry about. And we see a transition to O365, transition to AWS, kind of drive a bulk of the conversations around the need for SDWAN as well.
The other piece is how you avoid the traffic tromboning and the reason I mention it is many of the customers going in, or when they start a conversation, they think of the PaaS or IaaS platform as an extension of the data center. When we talk to them about, hey, you can make this part of your wide area so that you get direct access from let’s say your branch or your store or your retail all the way into the cloud, it kind of blows their mind away. It’s like, “Oh, I don’t need to now hairpin everything to my data center?” That would solve a lot of the suboptimality and the user experience problems, and so it is a topic that you want to absolutely be cognizant of and drive a network architecture blueprint based on that as well.
Now switching gears a slight bit to how can you consume this technology? There are a wide variety of flavors, even for cloud-delivered. Many of them have a management platform in the cloud and give you URLs. For that you can have a single pane of glass, but underneath the covers it’s nothing more than a single pane of glass. The guts of the solution still don’t provide all the capabilities required for an enterprise-class SDWAN.
Some of them provide you with a management infrastructure, a control infrastructure and an orchestration layer as well, so depending on the level sophistication you need in your enterprise, you want to be asking all the right questions around is this just a pure management platform? Is it a management platform plus a little bit of control? What tools do I have for orchestration, for zero touch provisioning, all of those, so those again are key question to ask from a cloud-delivered standpoint.
And closely associated with that is how do I make sure that I work with my cloud ops guys? Your cloud ops guys are going to be responsible for spinning up infrastructures and so forth, how do I make sure that this can co-exist with that so that you have very clear boundaries on this is a SaaS platform or service that I need to use to operationalize my network. It’s not really an infrastructure service, so again, we’ve seen this kind of come in the way of deployments usually causing delays and whatnot and so you need to be able to have those discussions up front.
The next important topic is really around interoperability and it’s one where we’ve seen many customers that are not as quickly prepared and struggle through. Again, a few hundred of these customers and so we can confidently say that you need to be able to dot the I’s and cross the T’s before you get to this stage. Everything works fine in five site pilot. That’s what vendors optimize for. That’s kind of what is tested in the lab environment and so forth.
It’s really when you start to do the migration from five sites to ten sites to a few hundred sites to – if your infrastructure has a few thousands sites, that’s really when the rubber meets the road and so you need to be able to think about, “okay I have, through the course of a transition which could exist for a few months in some cases, I’m going to have an SDWANized portion of the network and I’m going to have a traditional network. And I’m going to take some sites from the traditional network and then move that into the SDWAN infrastructure.”
Through that process what am I going to lose? Am I going to lose the site-to-site connectivity that I enjoyed with MPLS or do I need to designate a few points in my network as gateways, and if so what is the impact of those gateways? Who is going to own those gateways? So all of those are important considerations to look at from a transition standpoint, and at the same time as you start to talk about layering, layer four to seven appliances, things like firewalls, load balancers, WAN optimizers, you need to think about do I need to have them on a stick? Do I need to keep them in line? Do I centralize them so that I can service change through them? Again, all of these are considerations that you need to have in the infrastructure.
Closely associated with this are all the availability pieces – once again, in a lab environment with five sites emulated you don’t run into a whole bunch of issues. The vagaries of the wide area for any of those that have operated wide area networks now can be wide-ranging from really simple problems to the most complicated.
And so you need to be aware of all possible catastrophic failures, especially around if the controllers go down or are unreachable, what does that mean for my local site survivability? All of those things kind of need to be factored in. Some customers outrightly come and ask, “Hey, when I go from a traditional network to an SDWAN network do I need to keep two networks operating in parallel just in case I need to have a fallback?”
The short answer to that is, no – there are fail safe mechanism you can have so that even if all failures happen you have something to get your bits out, and so again, it becomes an architectural discussion that you need to have with your customers.
And there’s also an organizational challenge here. The whole notion of SDWAN is I have REST APIs I can use to program my infrastructure or I can consume these things in a really turnkey fashion using the management platform provided by the solution provider. And so what kind of scale or expertise do I need? Do I need to have some people inhouse who can do programming so that I can operationalize the workflows and make them really, really easy or should I look at integrators of sorts in order to have this mechanism, so all of those again are pretty key elements that you need to be aware of as well.
Now, switching gears again to a slightly different topic on the consumption model. This is one, again, where we spend a bit of time mainly because there’s a transition that’s happening. Customers that were do-it-yourself in some cases have burnt their fingers with traditional infrastructure and are looking to consume this technology using managed services, in the managed services fashion.
There are some that have operationalized their network entirely using integrators and providers and are looking to in-source that and become a do-it-yourself shop. So fundamentally that’s kind of the first order question that you need to answer – do you want to have operational staff in-house to manage or do you want to consume this as a service and essentially pay a provider or an integrator in order to consume this technology, so that’s one piece of it.
The second piece of it is essentially what does this mean in terms of billing and commercial sense of worth. I’m sure all of you have procurement teams that specialize in this and go through that exercise, but it’s also a level of flexibility that needs to be offered and very closely tied to the consumption model. Most of the other service platforms tend to be essentially billed on either a monthly or an annual basis, and so you kind of want to be conscious of that. You can still have term-based contracts, whatnot, but just work through the “as a service”-type models. Not many vendors are encouraging a pure capex model because the world is moving towards a more consumption-based economy and so just have to be aware of some of the intricacies there as well.
The other piece of it is really around hardware CPEs versus virtualized. What we have seen is if you go down the path of do-it-yourself and you want to virtualize the infrastructure it’s not just about taking an x86 platform and running a few what the industry call VNFs on top – one for SDWAN, one for maybe a firewall and so forth – there is a whole lot more around orchestration, around hardening the infrastructure and lifecycle management.
And what we have seen is, except for the uber large enterprises, most others do not have the operational expertise in-house in order to manage this and so the natural question back to your vendor is what kind of tools can you provide? And very simply the answer could be, hey, just consume this as a service for all the control and management infrastructure and use a physical form factor device.
Get familiar with the technology because you’re taking a jump from traditional networks to this SDWAN network, get familiar with how this works, and once you are sold on both the value and the operational aspect of it then you can start to move into a more virtualized fashion, so you can essentially take our customers through the journey. We provide the flexibility but at the same time you want to make sure that you have that flexibility as you go through the whole process. So that’s one piece of it – how do you take care of hardware versus just pure virtualized environments?
The other piece of it is what does my ecosystem look like for SDWAN? In the traditional world I used to have CPEs, I used to have some kind of an SNMP manager of sorts that used to monitor that infrastructure. I used to have a C flow D environment that gathered flows, did some forensics on it, and then I had some workflows that I automated.
Now in this brave new world of SDWAN many of those capabilities come standard in the product itself. The management platform that’s provided gives you all of the capabilities so what is it that I need to do? Do I need to consume this as a turnkey solution or can I take this one level up and kind of tie this back into my ticketing system? So things like can I tie this back to a service or infrastructure so that all of the workflow management for incidents and whatnot are handled seamlessly.
The same thing for things like an APM – I have an application performance monitoring system, can I tie this back to SDWAN so that I get end-to-end visibility? Not just to the network piece of it but how do I tie this back to the application. So once again, that’s kind of the problem that you need to kind of think through – what does the infrastructure look like?
At the same time, if you go down the path of circuit aggregators in order to have all the ISPs kind of bundled together but you have a single bill, then you need to think of who those circuit aggregators are and how do you consume that as well. So once again, a set of questions to ask your SDWAN vendor on – what are the best practices, do you have a blueprint, do you have references in a certain vertical that I belong in, and can you prove to me that this model actually works. Force the vendor to show their hand.
The next big one is really around operations, and as much as architecture and the value prop of SDWAN is around flexibility and so forth, the real value that you get as an operational staff is how quickly can I do things? And so you want to be able to split this into two parts, what we call a Day-0, which is all the planning and all of the constructs that you need to think of before you get to deployment, which could be, hey, how do I create a templatized version so that I can roll this across, say, a few thousands of sites?
How do I kind of create an automation framework on top of this? What kind of tools can I use natively provided by the vendor? What do I need to develop on top of it? Those are, again, a few things that you need to think of, and zero touch as well. Zero touch unfortunately, in the industry, is kind of an abused word. It could mean even folks that log into that device in order to put a few lines of config in there and call it zero touch, so you want to be conscious of, hey, can I really just take a box of cling wrap, connect it to power and Ethernet and power it on and kind of just get fully operational? Can I automate it all the way up to that point. So different degrees of zero touch, and you want to be able to understand what that looks like as well.
Then comes Day-2. This is where the fun begins. All the way from how do I implement change control? If I have maybe one customer that has a few thousands of sites and for them to implement one small change in the previous world with traditional infrastructure, it used to take months of downtime – maintenance windows and scheduling upgrades and whatnot.
In this brave new world of SDWAN it’s really a single click. You put one change in one place and you push that to a few thousands of devices. You need to have failsafe mechanisms in place so that if there is a problem, not across all thousands, but even across a few hundred or even across a few tens of those, can I roll it back to the last known good configuration so that I am not left in a state where I have to go and scramble, but at the same time I know I have a failsafe mechanism. And so those are again some of the things that you need to be aware of with respect to change control, and the same thing naturally extends to upgrades as well.
How do I make sure that software upgrades, and especially for any new technology software upgrades happen a lot more frequently? It could be once a quarter, once every six months and so forth, and so how do I make sure that I don’t take a big downtime in my maintenance windows in order to operationalize this? And so once again a few things that you need to be wary of, and at the same time troubleshooting.
There is a nice pane of glass that all of these guys provide. Can I troubleshoot my entire infrastructure using that? Do I have failsafe mechanisms so that if, for some reason, the infrastructure is not available how else can I troubleshoot the network, so again questions that you need to ask your vendor.
And future proofing – so this is a fundamentally important element and I’m sure your CTO, your strategy teams and also your network architecture teams would be very interested. We talk about IoT as though it’s in the distant future. We have had engagements with large banks and manufacturing elements and also healthcare that has said, “Hey, I have devices already in my infrastructure that want to monitor the temperature inside and want to talk to the network.”
Guess what? That is an IoT device. How do you make sure that those devices are secure? How do you make sure that those devices can be compartmentalized and how do you give them access to wherever they want to go because the last thing that the IoT guys are really thinking about is security, and so how do I make my network future-proof and secure enough so that I can actually bring these types of devices on demand and essentially look like a hero in front of the line of business that wants to build something or a cool new application.
The same thing extends into the LAN side. Wi-Fi is changing dramatically, so is the LAN. There are a variety of vendors that are innovating heavily in this space – how does that intersect the wide area? If you look to the right how does that intersect with applications moving into the cloud, into data center virtualization, into infrastructure as a service or PaaS platforms as well?
So once again it is worthy to have a discussion with your favorite vendor and walk them through, hey, here is kind of how I see my landscape changing. Are you going to be there, let’s say not today, but a year from now, three years from now? When my infrastructure changes dramatically will the promise of SDWAN still hold? So those are again some of the questions that you need to be aware of and be conscious of as well.
So with that I’m going to wrap this up – there are a few things that we provide right off the bat to help our customers through this journey, so you can reach out to email@example.com. We have a sample RFI and RFP that we can walk through to understand. Again, these are the elements, kind of baseline capabilities across multiple different vendors in your evaluation process.
The second one is we provide a really sophisticated proof of concept test plan, which is essentially all the questions that a whole lot of customers have asked and test cases and used cases that we’ll walk them though, so we have kind of dumped all that into a proof of concept test plan and have that in a structured way, so we’ll be happy to share that with you. You can pick pieces of it that are relevant to you and kind of discuss the rest as well, and then finally validated architectures and designs as well.
The other few elements are really around the Future WAN itself, so over the course of the week we have had multiple customers talk about it, and Lloyd will cover some of the elements as well, and then we’ll walk through some of the questions.
Lloyd: Thank you, Ramesh. So the customers that spoke at FutureWAN are First American and Kindred Healthcare. I highly encourage you to go and look at their transformation. Also another good session to watch is a live demo, so anything that you want to know about SDWAN, you want to see how it is executed, you can see a live demo by David Klebanov.
I want to move to the questions right now, so we have a bunch of questions coming in. The first one is are you seeing deployments happening more on the managed service side or standalone, Ramesh?
Ramesh: Yeah, it’s a great question. The answer largely depends on a few things. One is culture – different geographies have different cultures in how they want to consume this technology. US kind of have been split in the middle with a do-it-yourself versus managed services. Europe and APAC tend to be kind of managed services-heavy, so the first piece of it is which region are you in and that would kind of dictate what the dominant force there is.
The second piece of it is the technology is so easy to consume – can I consume this myself? The answer could be yes. The answer could be no, depending on the level of sophistication that you need in the infrastructure. The scene, if you have one or two people in your operational staff that take care of vendor management, network architecture, network operations, keeping the lights on and so forth, then you may not be adequately prepared to handle a few thousand sites by doing it yourself.
You may want to bring in additional people or you can say, “Hey, I want to take care of the network architecture and the high order bit myself and I want to have a managed service provider kind of implement the policies, the operationalizing of the infrastructure,” and so you can have a hybrid approach there as well. We walk our customers through this journey and ultimately ask a few questions related to how do you want to consume this before you can decide one way or the other.
Lloyd: Thank you. The next question is when I have an MPLS link along with broadband what happens to the MPLS routing when they overlay?
Ramesh: Yeah that’s a great question. So in the end state architecture – and I’ll emphasize on what I mean by end state architecture – if you fast forward to how the network should behave you want to have an overlay over all available transport and the reason for that is simple. You want application visibility, you want telemetry, lost latency, jitter, path MTU, lost load – all of those characteristics and you want to be able to make decisions on those important data points.
And so if you have overlays across your private MPLS and your broadband and let’s say 4G LTE and so forth, then you can make a uniform decision across all of them. And so naturally what that means is the underlying MPLS network now no longer needs to carry the routed infrastructure prefixes. We have seen customers that have established overlays over their MPLS infrastructure. Naturally I don’t need to pass all my LAN site prefixes into my MPLS network and so they pull those out, go into the controller.
So if it’s a managed services provider that providing this they have control over that, and the underlying circuit provider does not get to see any of the infrastructure routes. And so the short answer is you can have a pure overlay network over all of the available transports. We have seen some really, really riskaverse customers. I would kind of bucket them in the 5 percent category that still want to have a failsafe, so they go with a full overlay, but if for some reason the overlay fails or they experience application performance issues they want to be able to fall back to the underlay, which is essentially MPLS routing. And so again, a very important question to ask and you can go through that as well.
Lloyd: Wonderful. The next question is around cloud – how do you guarantee the cloud application performance when using only broadband?
Ramesh: Yeah, that’s again a great question. So again, cloud is a pretty broad term. You want to be able to split that into two parts. One is for SaaS and one is for infrastructure as a service. SaaS, if you see the dominant model – take Office 365 as an example – Microsoft says come over the internet and access the Microsoft network and I will take you into the infrastructure as deep as you want, to where your data resides.
And so naturally there you want to think about can I do a split on a lot of my branches, access Microsoft, and naturally as a result I’ll get the most optimized O365 connection. Now that works if you’re over a reliable broadband circuit – it does not if you’re not. So we have built capabilities into the platform, into the infrastructure so that irrespective of whether you do a split tunnel or you go through a cloud-hosted colo. facility for example or aggregate at your data center, you’ll be able to choose the best path all the way up to where the application resides.
Now, this is important because for SaaS normally it will allow you to spin up an instance of the vendor software inside their platform and so the ability to kind of get the telemetry of the underlying service, all the way up to the application layer, is important and so that’s one piece of it.
For infrastructure as a service you have to make a choice. Do you want to go deep into the IaaS platform, so in the case of AWS that would be do you want to go really deep into the VPCs, in which case you get all of the visibility and control all the way up to the workload, or do you want to sit on the outside and have a link pointing towards AWS?
The choices there are you need to have some level of sophistication to understand how AWS works to spin up instances. If you have that we certainly recommend going as deep as possible into AWS, or if you don’t and you want to kind of confine yourself to the network boundary using physical devices, then you can sit on the outside and have an access into AWS through either a broadband connection or through a direct connect and whatnot. So the answer largely depends on whether it’s a SaaS cloud or an IaaS and with an IaaS whether you have the ability to go deep or not.
Lloyd: Thank you, Ramesh. One more question around security – we’ve been considering to do DIA for a while but there are many people in the organization that are nervous about security. Are you seeing – are there those who DIA?
Ramesh: Yeah, absolutely, and I kind of want to understand the details behind this, but the short answer is we are seeing a tremendous amount of customers moving down the path of DIA. We were skeptical even as a vendor. Even though we provided the capability we were skeptical that it would go down this route, but for SaaS in general, customers are extremely okay going down the path of DIA.
Now the natural question or the question behind the question is, if so, then what kind of infrastructure hardening do I need to have before I do a split tunnel or a DIA? And so the short answer is, again it needs to be provided by the SDWAN platform, some critical element and capabilities need to be provided.
There are also other ways you can solve this problem. You can keep the footprint of the branch or the site really, really simple, have access to a cloud security gateway, like a Zscaler for example, and then access the internet or access a SaaS-based platform through that. So the short answer is you have a few options to work with as with all things that are tradeoffs with respect to performance and security and availability, and as long as you make the right choices you have an option to work with.
Lloyd: And that’s it, Ramesh – those are the questions. If you have any more please send them along; we’ll continue to answer them and join the conversation on #futurewan. Other than that we have all our shows available on demand. There are about 17 sessions. Some of them are – most of them actually are with our partner vendors, including Palo Alto, Zscaler, Computer Associates, Live Action and more, so please check out the sessions and we are here to answer any questions. Thank you so much.
Ramesh: Thank you, everyone, and have a great rest of the day.