>>thank you everyone for joining. I'm here today to talk about English controllers. AP Gateways and service mention communities three very hot topics that are also frequently confusing. So I'm Richard Lee, founder CEO of Ambassador Labs, formerly known as Data Wire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including telepresence and Ambassador, which is a kubernetes native AP gateway. And most of what I'm going to talk about today is related to our work around ambassador. Uh huh. So I want to start by talking about application architecture, er and workflow on kubernetes and how applications that are being built on kubernetes really differ from how they used to be built. So when you're building applications on kubernetes, the traditional architectures is the very famous monolith, and the monolith is a central piece of software. It's one giant thing that you build, deployed run, and the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly, is the architecture er is really reflecting that workflow. So with the monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular pieces offering. Everyone works towards that release train, and you have specialized teams. You have a development team which has all your developers. You have a Q A team. You have a release team, you have an operations team, so that's your typical development organization and workflow with a monolithic application. As organization shift to micro >>services, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of the application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship a soon as they're ready. And so we call this full cycle development because that team is >>really responsible, not just for the coding of that micro service, but also the testing and the release and operations of that service. Um, >>so this is a huge change, particularly with workflow. And there's a lot of implications for this, s o. I have a diagram here that just try to visualize a little bit more the difference in organization >>with the monolith. You have everyone who works on this monolith with micro services. You have the yellow folks work on the Yellow Micro Service, and the purple folks work on the Purple Micro Service and maybe just one person work on the Orange Micro Service and so forth. >>So there's a lot more diversity around your teams and your micro services, and it lets you really adjust the granularity of your development to your specific business need. So how do users actually access your micro services? Well, with the monolith, it's pretty straightforward. You have one big thing. So you just tell the Internet while I have this one big thing on the Internet, make sure you send all your travel to the big thing. But when you have micro services and you have a bunch of different micro services, how do users actually access these micro services? So the solution is an AP gateway, so the gateway consolidates all access to your micro services, so requests come from the Internet. They go to your AP gateway. The AP Gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate micro service. And because the AP gateway is centralizing thing access to all the micro services, it also really helps you simplify authentication, observe ability, routing all these different crosscutting concerns. Because instead of implementing authentication in each >>of your micro services, which would be a maintenance nightmare and a security nightmare, you put all your authentication in your AP gateway. So if you look at this world of micro services, AP gateways are really important part of your infrastructure, which are really necessary and pre micro services. Pre kubernetes Unhappy Gateway Well valuable was much more optional. So that's one of the really big things around. Recognizing with the micro services architecture er, you >>really need to start thinking much more about maybe a gateway. The other consideration within a P A gateway is around your management workflow because, as I mentioned, each team is actually response for their own micro service, which also means each team needs to be able to independently manage the gateway. So Team A working on that micro service needs to be able to tell the AP at Gateway. This this is >>how I want you to write. Request to my micro service, and the Purple team needs to be able to say something different for how purple requests get right into the Purple Micro Service. So that's also really important consideration as you think about AP gateways and how it fits in your architecture. Because it's not just about your architecture. It's also about your workflow. So let me talk about a PR gateways on kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the Internet to services inside the cluster kubernetes. From an architectural perspective, it actually has a requirement that all the different pods in a kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own I p address. So this makes things very, very simple for inter pod communication. Cooper in any is, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you routed around the cluster and it's very opinionated about how this works but getting traffic into the cluster. There's a lot of different options on there's multiple strategies pot i p. There's ingress. There's low bounce of resource is there's no port. >>I'm not gonna go into exhaustive detail on all these different options on. I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be >>ah, Harvard load balancer. It could be a virtual machine. It could be a cloud load balancer. But the key requirement for an external load balancer >>is to be able to attack to stable I people he address so that you can actually map a domain name and DNS to that particular external load balancer and that external load balancer, usually but not always well, then route traffic and pass that traffic straight through to your ingress controller, and then your English controller takes that traffic and then routes it internally inside >>kubernetes to the various pods that are running your micro services. There are >>other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really required each of your micro services to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about in English controller. What exactly is an English controller? So in English controller is an application that can process rules according to the kubernetes English specifications. Strangely, Kubernetes is not actually ship with a built in English controller. Um, I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement. And it is. It turns out that this is complex enough that there's no one size fits all English controller. And so there is a set of ingress >>rules that are part of the kubernetes English specifications at specified how traffic gets route into the cluster >>and then you need a proxy that can actually route this traffic to these different pods. And so an increase controller really translates between the kubernetes configuration and the >>proxy configuration and common proxies for ingress. Controllers include H a proxy envoy Proxy or Engine X. So >>let me talk a little bit more about these common proxies. So all these proxies and there >>are many other proxies I'm just highlighting what I consider to be probably the most three most well established proxies. Uh, h a proxy, uh, Engine X and envoy proxies. So H a proxy is managed by a plastic technology start in 2000 and one, um, the H a proxy organization actually creates an ingress controller. And before they kept created ingress controller, there was an open source project called Voyager, which built in ingress Controller on >>H a proxy engine X managed by engine. Xing, subsequently acquired by F five Also open source started a little bit later. The proxy in 2004. And there's the engine Xing breast, which is a community project. Um, that's the most popular a zwelling the engine Next Inc Kubernetes English project which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the ingress engine X ingress controller, and it's not clear if they're using this commercially supported version or the open source version, and they actually, although they have very similar names, uh, they actually have different functionality. Finally. Envoy Proxy, the newest entrant to the proxy market originally developed by engineers that lift the ride sharing company. They subsequently donated it to the cloud. Native Computing Foundation Envoy has become probably the most popular cloud native proxy. It's used by Ambassador uh, the A P a. Gateway. It's using the SDO service mash. It's using VM Ware Contour. It's been used by Amazon and at mesh. It's probably the most common proxy in the cloud native world. So, as I mentioned, there's a lot of different options for ingress. Controller is the most common. Is the engine X ingress controller, not the one maintained by Engine X Inc but the one that's part of the Cooper Nannies project? Um, ambassador is the most popular envoy based option. Another common option is the SDO Gateway, which is directly integrated with the SDO mesh, and that's >>actually part of Dr Enterprise. So with all these choices around English controller. How do you actually decide? Well, the reality is the ingress specifications very limited. >>And the reason for this is that getting traffic into the cluster there's a lot of nuance into how you want to do that. And it turns out it's very challenging to create a generic one size fits all specifications because of the vast diversity of implementations and choices that are available to end users. And so you don't see English specifying anything around resilience. So if >>you want to specify a time out or rate limiting, it's not possible in dresses really limited to support for http. So if you're using GSPC or Web sockets, you can't use the ingress specifications, um, different ways of routing >>authentication. The list goes on and on. And so what happens is that different English controllers extend the core ingress specifications to support these use cases in different ways. Yeah, so engine X ingress they actually use a combination of config maps and the English Resource is plus custom annotations that extend the ingress to really let you configure a lot of additional extensions. Um, that is exposing the engineers ingress with Ambassador. We actually use custom resource definitions different CRTs that extend kubernetes itself to configure ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by kubernetes. So when you do a coup control apply of an ambassador CRD coop Control can immediately validate and tell >>you if you're actually applying a valid schema in format for your ambassador configuration on As I previously mentioned, ambassadors built on envoy proxy, >>it's the Gateway also uses C R D s they can to use a necks tension of the service match CRD s as opposed to dedicated Gateway C R D s on again sdo Gateway is built on envoy privacy. So I've been talking a lot about English controllers. But the title of my talk was really about AP gateways and English controllers and service smashed. So what's the difference between an English controller and an AP gateway? So to recap, an immigrant controller processes kubernetes English routing rules and a P I. G. Wave is a central point for managing all your traffic to community services. It typically has additional functionality such as authentication, observe, ability, a >>developer portal and so forth. So what you find Is that not all Ap gateways or English controllers? Because some MP gateways don't support kubernetes at all. S o eso you can't make the can't be ingress controllers and not all ingrates. Controllers support the functionality such as authentication, observe, ability, developer portal >>that you would typically associate with an AP gateway. So, generally speaking, um, AP gateways that run on kubernetes should be considered a super set oven ingress controller. But if the A p a gateway doesn't run on kubernetes, then it's an AP gateway and not an increase controller. Yeah, so what's the difference between a service Machin and AP Gateway? So an AP gateway is really >>focused on traffic into and out of a cluster, so the political term for this is North South traffic. A service mesh is focused on traffic between services in a cluster East West traffic. All service meshes need >>an AP gateway, so it's Theo includes a basic ingress or a P a gateway called the SDO gateway, because a service mention needs traffic from the Internet to be routed into the mesh >>before it can actually do anything Omelet. Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Dr. Enterprise provides an envoy based solution out of the box. >>Uh, SDO Gateway. The reason Dr does this is because, as I mentioned, kubernetes doesn't come package with an ingress. Uh, it makes sense for Dr Enterprise to provide something that's easy to get going. No extra steps required because with Dr Enterprise, you can deploy it and get going. Get exposed on the Internet without any additional software. Dr. Enterprise can also be easily upgraded to ambassador because they're both built on envoy and interest. Consistent routing. Semantics. It also with Ambassador. You get >>greater security for for single sign on. There's a lot of security by default that's configured directly into Ambassador Better control over TLS. Things like that. Um And then finally, there's commercial support that's actually available for Ambassador. SDO is an open source project that has a has a very broad community but no commercial support options. So to recap, ingress controllers and AP gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. >>And I think a lot of times organizations don't think critically enough about the AP gateway until they're much further down the Cuban and a journey. Considerations around how to choose that a p a gateway include functionality such as How does it do with traffic management and >>observe ability? Doesn't support the protocols that you need also nonfunctional requirements such as Does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this on a P? A. Gateway is focused on north south traffic, so traffic into and out of your kubernetes cluster. A service match is focused on East West traffic, so traffic between different services inside the same cluster. Dr. Enterprise includes SDO Gateway out of the box easy to use but can also be extended with ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between a P gateways, English controllers and service meshes and how you should be thinking about that on your kubernetes deployment

>>Ply from Barcelona, Spain. It's the cube covering Cisco live 20 fly from Barcelona, Spain. It's the cube covering Cisco live 2020 brought to you by Cisco and its ecosystem partners >>come back to the live coverage of Q four days here in Barcelona, Spain. I'm John for a stupid cube coverage at Cisco live 2020 in Europe. Our next guest, Michael Beasley CTO of the Cisco service provider business unit. Michael, great to see you. Thanks for coming on. Thank you for having me. It's great to see you guys again. You came on at the Cisco live show last year, 2019 in the U S obviously as a CTO of the service provider group, you're in the middle of all these really big conversations because the service providers, I've been really trying to push the envelope for generations into getting better performance, but the diversity of services that they have to start bolting onto their infrastructure. Now with all the pressure of the cloud providers, everybody's streaming these days, so all these new competition, so service parts still have a huge footprint, huge infrastructure. >>That's the story. What's going on with a service provider. They obviously do, I mean more and more service providers are deploying and running critical infrastructure for their consumer customers, their enterprise customers, and obviously as as the economy, as nations, as industries continued to digitize, that infrastructure's critical for governments, for countries and for whole economic environments. And the reality of course is that the bandwidth keeps growing more and more bandwidth is coming onto the network. We see tremendous innovation and advancements in the access layers, whether it be on the DOCSIS for cable, wifi, six obviously for wifi and for five G with regard to mobility. So the amount of bandwidth that can come on to the network keeps rising, rising exponentially. So the service providers, you know, obviously that poses a set of challenges, but also a set of opportunities as they rethink their architectures and their infrastructure to be able to deliver that bandwidth cost-effectively. >>I know cost is a huge concern for these guys because they do spend a lot of money. Stu and I were just reminiscing about how much we've been following Cisco growing up in the computer industry at our rate and we're there when Cisco was born and watch it progress over the years and now as it's on the next generation or the next gen cloud, next gen, everything. It's interesting you have the service providers say, but the one that you're in, and I would say maybe financial services have always been like the hardcore Cisco customer pushing the envelope on the gear, pushing the envelope on the technology because they have low latency requirements. You move and pack us around. Right now you're starting to add more payload with more bandwidth coming. It really kind of the fit of the bellwether. What are the big trends that they're driving now because again, they have to maintain those table stakes and still pioneer new ground. >>What are some of the things that they're doing that you see or tell signs for the future? >> I think the things that I see is first of all, a drive towards rearchitecting the network such that it's much more simple, easier to operate, more cost effective and more reliable to operate with w with new next generation technology up and down the SAC, the stack from the Silicon through the actual systems, the embedded software, the optical modules, all of the physical ingredients that go into building a next generation software defined transport network. That's really what I see our major customers aim towards. Obviously it takes time. There's an amount of challenges given that some of these customers have been running networks for century. That said the desire and the efforts to partner with us to get to that future state such that the bandwidth can be offered cost-effectively and very reliably as we're building out this, these critical infrastructures. >>I would add. The other aspect is that as these networks are getting more powerful delivering more services, there is more of a consideration for the integrity, the trustworthiness and the security of the actual networks and the actual infrastructure from the hardware through the software in Silicon that actually make the make up these networks in having technologies that can measure the trustworthiness and the fidelity both from a hardware but also from a software perspective and be able to report off of the infrastructure without the station records to verify and to drive analytics with regard to the cleanliness and the trustworthiness of this infrastructure. >>Yeah. Michael, I remember leading up to the announcement that this is gladness. December, it was, Oh here's the next gender issues generation in the internet and in my mind I was like, Oh, sounds like it's time for the next generation of routers. But what I found really interesting is, you know, what are those next generation applications that are going to drive things? You know John talks about from a history lesson, I remember going back, you know, okay, what's going to drive 10 gig? Oh, we're going from a lot of North South to the East. West virtualization wave was really kicking off inside data centers these days. You know, it's multicloud, it's cloud native application 5g of course as a drum beat in the background. Talked a little bit about some of those applications, the business impact that the surface fighters need to be able to enable in this rollout of this new technology. >>Yeah, it's a very interesting area. I've been in the industry for 30 something years, just about 30 years and I think I've never found the industry more exciting than it is today. Obviously there's that set of challenges, but there's an incredible set of opportunities as well. We have all of the applications that we know and love today are continuing to grow at exponential rates and get bigger, you know, further and further adoption. If you think you know the fact that less just slightly less than all humans on the planet are on the internet with more coming in the future at an accelerated rate and bringing more devices with them, we think that the average device per user will go for about two up to about three and a half over the next few years. So you have the current set of applications, whether it be social media, video, video streaming, they continue to grow. >>And then there is a whole new set of applications that we'll see. There's a long list. We will see which ones actually transpire. It's hard to predict, but everything from advances in gaming, artificial intelligence, AR, VR services, telemedicine, the continued digitalization of industry in particular, manufacturing, transportation, oil and gas. All of these industries opened up at the prospect for new applications that will run on top of these infrastructure that will drive exponential growth in bandwidth and also will, will require much, much better latency from the actual network infrastructure. So there are areas that we're focused on and delivering the innovation and the core building blocks to allow our customers to build these networks to offer these services. >>Well, one of the other challenges, and you've talked about these, these transitions in this step function that networking tends to do is the cost involved when you go from one generation to the next. Cisco of course, has a large optics business know major player in the industry. Talk to us a little bit about what 400 gig means today and have people should be thinking about the cost of these types of solutions. >>Yeah, it's interesting. Certainly as we've, as we've seen from each generation as the interface speeds have changed, the actual bomb, the bill of materials for the solution has changed significantly with regard to which piece account for what dollars it used to be. If you go back to the 10 gig generation, the actual networking equipment itself was the majority of the cost. That was the majority of the bomb optic modules that plugged in were a minority. Maybe the optic optic modules were 10 or 15% and the rest was actually the system. As we look to the 400 gig generation that is actually reversed the, we now have network Silicon that is so dense and so fast that eight can power a full 36 ports, a 400 gig on an actual line card. So you're plugging in 36 optical modules to bring that bandwidth to the, to the networking Silicon. >>So as a percentage of the bomb, the optical module is not much higher from a bomb perspective. It also becomes more critical technology with regard to the reliability and the cost of the whole solution. And this is why Cisco is taking a big focus on the optical module space. We've obviously continued our own organic development and we've also been quite active on the M and a front with regard to ensuring that we have the technology and the right R and D programs to be able to deliver very reliable, cost-effective optics at 400 gig and beyond. So you brought up Silicon, so I got to ask the Silicon one question we were covering at the launch in San Francisco, Chuck Robin was there, David Geckler, you had all the top dogs. They're kind of really kind of going off on the future of Silicon, but of course Silicon angle's interested in covering that because that's in our name. >>But the trend is about cloud scale and operational efficiency. And one of the things that's coming out of the cloud trend is an operating model in public cloud and on premise that is proven. That's what people are going through. That's hybrid. How were the SP service providers implementing that? Do you guys see the Silicon one being that opportunity where they can have an end to end software life cycle having operating model? Is that some of the value? So then what's the real story for us writers? So, I mean that's, that's a core aspect of our architecture and our strategy is to have a solution, a full solution that our service provider customers can consume that embodies all of those learnings and all of those operational realities that have built up in the, in the public cloud space. Certainly Silicon one is a key aspect of that with regard to being the fundamental building block from a network processing point of view being the fundamental building block that actually switches traffic that switches pockets and actually routes the traffic through the, through the infrastructure and through the transport network. >>Along with Silicon one we have our embedded software XR seven which is the control plane for that Silicon and it embodies the routing protocols, the management interfaces, analytics, traffic management, QoS services and so forth. But more and more we're augmenting that embedded software with a set of cloud services that are delivered as a SaaS to our customers. That AIDS in operations reduces their deployment efforts, their deployment costs, and also increases reliability of the whole solution. As the SaaS services are augmenting the physical infrastructure, there's less room for human error. There's less room for integration problems with between the layers in the stack. So it's a key aspect of our savagery. Okay. So let me ask you about the user experience or the application experience. So if I'm developing apps on Silicon one, is it multiple stacks? What's the stack look like? What's the, what's the developer environment look like? >>If I'm a telco or I'm a service provider, what's going on? >> So it depends on the, on the use case, what we announced last month was not only the Silicon and our own products, the Cisco 8,000 that uses that Silicon, but we also announced the offerings of Silicon one through a merchant Silicon program where you know, third parties and OEM, a large customer could actually transact with us on the Silicon alone where we're selling them the actual Silicon. In that context, the Silicon comes with a full featured software development kit that sits on top of that Silicon. You can consider that a device driver if you like an abstraction layer that then allows that third party to either use open source or to build their own network services stack on top of that SDK that can then leverage all of the power in the innovation that is in the Silicon one engine. >>Before I get to my video question because I, cause we're doing video, we care about facts but we love more bandwidth. We love more video action. How do you talk to customers that you meet with? Because we hear a lot from the community and our expert network on the cube alumni that in certain there's a lot of pretender products out there, you bolt on a Nick offload. Where is it okay to have kind of like performance enhancements, performance enhancing hardware. That sounds kind of, that didn't sound right, but performance hardware when when the system is more important. So which customer profiles want more of the Silicon one or Cisco 8,000 versus a either an enhancement product and how does the customer determine what's a fit form one may be look good on paper, low price, high performance. How do you go in and say that's pretending that's a player? >>It's interesting. I think that the fundamental root of the answer to that question is you have to look at the application stack that you're trying to deliver. If it's a homogeneous stack where the applications are infrastructure to deliver services to a third party, then what matters simply is that application and all the infrastructure underneath it. How can you deliver that most cost effectively both in terms of capital costs but also operational cost in terms of power and human operational costs with regard to running the infrastructure. If you, if you think about a heterogeneous situation, public cloud is a good example of that where the public cloud provider is responsible and bears the cost of the infrastructure layer and the customer, the customer themselves are bringing the application workloads to run on top of that infrastructure. In that heterogeneous model. Indeed there might be, you know, some valid business security and operational reasons for actually separating the infrastructure out and having a part in the infrastructure dedicated to run the application on a part of the infrastructure dedicated to the overhead of that application, whether it be virtual networking, security functions, analytics and so forth. >>So it's interesting generally with our customers, what they're looking for more than anything else is bottom line. What is the most efficient way to deliver the end result, regardless of how it's architected, regardless of how the processing is separated into different layers of compute and dedicated hardware, what's the most effective way to deliver the outcome, both in terms of capital cost and more and more operational costs. And as everything gets faster, the power draw is more and more a very dominating function with regard to the ongoing operational costs of these networks. I want to get your thoughts on a couple of trends. One is the comeback. A voice. Stu was riffing about his days were going to voice over IP. Now voice, Hey Alexa, you know there's a small, it's not a real deep bandwidth heavy application, so get great voices coming back that fits a service providers. >>But video is growing really fast. So video is putting a lot of pressure on service providers. What's the state of the art there? Can you make a comment on how you see that evolving? What are they doing and what are some best practices and what are people doing? Yeah, I mean you're exactly right. Video in particular over the top video streaming video, but broadly video at all forms continues to grow at exponential levels. Our analysis, if you look at the Cisco VNI study by 2022 we predict that more than 80% of all internet traffic is actually going to be video. And along with its growth, unfortunately the value per bit goes down because especially as you get higher definition videos in particular, the value per bid to the service provider to the, to the entity bearing the transport cost of the video is actually going down. >>So what that drives our customers to do is first of all provision very high bandwidth networks but also optimize the most cost effective way to deliver that video at very high quality to their end users. I would say there's a few things that are top of mind in achieving that. The first is distributing out the network in particular, distributing out, peering into the Metro areas of the network and no longer having Piering dedicated only at the far side of the backbone when peering is done in the Metro. That traffic is literally on the network for less kilometers. So that helps. I would also say the deployment of edge compute caching and CDN services in the Metro really helps in delivering video. We just got a great tutorial on video architecture in the major highways of the pipes Metro appearing. So changing the dynamics of peering relationships, traffic routes, but ultimately making an efficient. >>Exactly. Well Michael, great to have you on. I know you've got mobile world Congress coming up in February. I always a big show, um, spill some of the announcements for us. I'd love to, but I thought I would be not popular with my bosses by now. Just just teasing you. I know you've got some good stuff on. We're waiting to hear them. We haven't heard anything, but we're getting some rumblings as always. Big announcements for you guys. Congratulations. Thanks for coming on. Thank you so much. I look forward to it. Great insights here on the cube, on the service provider market, the needs, what's going on in the network, and really ultimately video's changing and also the architecture is changing and this is putting more pressure. Again, more bandwidth, more things are happening. This is the Cisco powered cube here in Barcelona. I'm Gianforte Stu Miniman. Thanks for watching.

>> From Las Vegas, it's theCUBE. Covering Open Systems. The future is crystal clear with security in SD-WAN. Brought to you by Open Systems. >> Welcome back to Las Vegas everybody, my name is Dave Valanti and you're watching theCUBE, the leader in live tech coverage. We go out to the events, we extract the signal from the noise. We are covering the Open Systems networking event. They're here as part of the two Gartner events here this week. On the heels of AWS Reinvent, a lot of action going on in Las Vegas. Steve Garson is here, he's the president and founder of SD-WAN experts consultancy in this space. Steve, thanks so much for coming on theCUBE. >> Glad to be here. >> So tell us a little bit more about your background. >> Okay. I've been in the networking space since about 2007. Initially, my company was called MPLS Experts, when companies were migrating to MPLS and not understanding, well, what carriers should I use. I helped companies re-engineer their WAN back then. As that developed, the WAN optimization came into the scene and I helped companies evaluate the right WAN optimization solution. Then I had the foresight to see the potential of SD-WAN. I pivoted the business, called it SD-WAN Experts and started writing for network world and blogging on my own sites and with a number of other websites. I've been helping enterprises worldwide re-engineer their network, make a WAN transformation that's secure and supports easy management and save a lot of money. >> So, awesome. So you have a practitioners background, right? >> Exactly. >> That's fair to say. So you know your stuff, let's get into it. So let's talk trends, I mean. At a high level we always talk at theCUBE about the cloud and how that's affecting network traffic. Going from North South to East West has a major impact on security and performance. What are the big trends in the market space that you see, that are relevant? >> Well, we see consolidation obviously. (coughs) Obviously moving to the cloud is a big driver. The WAN has been designed for a data center with an MPLS network. That's a hub and spoke architecture that really doesn't make sense anymore. Companies are moving to Office 365, they're using Salesforce.com, they're using all kinds of softwares and service. That just doesn't work with a data center. So what companies have traditionally done is they have regional secure gateways and they're sending the traffic from an office to a secure gateway and now they're going through the internet. It just is convoluted, the traffic is tromboned and the latency is higher than it has to be. They're spending more money for these expensive circuits that, ultimately, they're going to the internet anyways. >> So, there's a lot of technical debt out there. How does a company go from point A to point B without spending a zillion dollars or bringing in, you know, a huge SI to re-architect everything. Is there a path that you can advise customers, or is it just every situation is a snowflake? >> You could probably define a half-dozen different basic situations that are snowflakes. Essentially you're moving to, you know, if you have an MPLS network companies typically will need more bandwidth and instead of getting more MPLS bandwidth they'll add internet connectivity. Using SD-WAN they'll root traffic over the internet that's supposed to go to the internet. The things that are still required on their MPLS network will stay in play. When those MPLS contracts expire, then there's a question of, do I need MPLS? That's a complicated question to answer. I will not say that you can eliminate MPLS, I'll always say it depends. It depends on the latency between paths on your network. I presented a paper at O-NUG a few weeks ago in New York, in which I analyzed with a lot of empirical data. Latency, packet-loss, and standard deviation of that latency between paths like from Tokyo to New York. You might a have 200 millisecond latency. But your standard deviation over the internet might be 200 milliseconds. So that means, potentially, if you're using only the internet, you might have 400 milliseconds latency. Can your application work appropriately? >> If you need 200 guaranteed, you've got a problem. Right? >> Right, exactly. In a situation like that, you might want to use MPLS or there's a new category of connectivity called SDCore which is an MPLS network in the Cloud that you access through an IPSec VPN to pops that are typically within 20 milliseconds. So you get that stability, but you cut the cost dramatically. >> Now the Edge just confuses us even further, right? IOT, The Edge, I mean certainly a trend everybody's talking about. From your standpoint, how real is it? Is it here today? Is it coming? What is the effect going to be on all these trends? >> You mean, the Edge? >> Yeah, the Edge, IOT. >> I mean it's a complicated thing. I mean the Edge. >> The industrial internet. >> Yeah, I mean, when people talk about the Edge today the Edge used to be their router and SD-WAN devices are supplanting the router. Gartner has indicated that by 2023 nobody is going to be buying routers. Everybody is going to be using an SD-WAN device which will route. >> Amazon, we were at Reinvent last week, they might even look at the data center as the Edge. But, I digress. Let's talk about the horses on the track. Lay out the competitive environment right now. We're here at the Open Systems event. Where do they fit in the market landscape? >> Open Systems is a very unique company where people will say, who's Open Systems competitor. They really don't have a competitor because they're unique. Open Systems is a company that has a secure SD-WAN which means there's a full security stack with SD-WAN. So you have the benefits of SD-WAN, but instead of having to deal with all these different security applications like HASBY, Data-loss Prevention, and IPSIDS, authentication, VPN integration with active directory. They do all of that and it's all managed. It's a very unique offering. >> So the competition is Do-It-Yourself, right? >> The competition is Do-It-Yourself or use a managed service provider who probably doesn't have all the pieces that work together. Open Systems has been doing this for 25 years. They have developed what the customers want. I went to one of their global customer meetings. They called a cap meeting last year. Each year they get input from the customers as far as what kind of enhancements they want to see. They actually take that input and the following year the customers, I was amazed, the customers just are thrilled that the company listens and the company implements what they ask. >> Again, I've mentioned there's a couple of Gartner shows going on this week. Sounds like Open Systems wouldn't really fit cleanly into a magic quadrant. >> They don't. They don't because they're not an Edge device. They're a complete Edge security solution that's managed. >> We talked about this at theCUBE, John Ferrs has brought up several times that the magic quadrants will have to evolve as these managed services, the Cloud certainly affects that. As more and more things get co-opted by the services, you know, economy. But, your thoughts on magic quadrants, how customers are using them. My understanding is, today, you heard a talk from a Gartner analyst that was helping people understand the do's and don'ts of a magic quadrant. Your thoughts? >> Yeah, well what Gartner was talking about today is how many people use the magic quadrant inappropriately. They think this tells us which companies we should look at and really what it's telling you is how that customer's strategy fits in with the market place. But you really have to look at what your requirements are. You can't just say, okay I'm going to look at quote the top three SD-WAN vendors. What are your requirements? That's what my firm does as a consultant is we help companies figure out what their requirements are to find out what's the right solution. A story I love to tell is a company that spent a year evaluating SD-WANs. They were about to make a decision and the CIO basically told the committee after a year of evaluations hey before we sign a contract, let's get an independent sanity check that we've made the right decision. I met with the company, spent a couple weeks assessing their requirements, and I know all of the major technologies and I knew that what they had selected wasn't correct. But you can't tell a client that they've made a mistake. So we set up a meeting with the vendor, which was a carrier, and their technology provider and the committee and I asked the hard questions that the vendor couldn't answer. Which made it really clear to the client that this is the wrong solution. They went a completely different direction. >> Saved them a lot of money. I love those stories. What's your website? >> SD-WAN-experts.com >> Alright, Steve thanks so much for coming on theCUBE. Sharing your knowledge. >> Thank you. >> Awesome stuff. Really appreciate it. >> Pleasure. >> Keep it right there, everybody. We'll be back from Las Vegas Cosmo hotel. Open Systems networking event. You're watching theCUBE. (techno music)