 From Santa Clara, California, in the heart of Silicon Valley, it's theCUBE. Covering Altitude 2020, brought to you by AVatrix. Okay, welcome back to Altitude 2020 for the folks on the live stream. I'm John Furrier, Steve Mulaney with CEO of AVatrix. For our first of two customer panels on cloud, with cloud network architects, we've got Bobby Willoughby, they gone, Luis Castillo, National Instruments, David Shidnick with Fact Set. Guys, welcome to the stage for this digital event. Come on up. Hey, good to see you. Thank you. No, no, no. Okay. Okay, customer panel, this is my favorite part. We get to hear the real scoop. We get the gardener given this industry overview. Certainly, multi-cloud is very relevant in cloud-native networking is the hot trend with the live stream out there on the digital event. So guys, let's get into it. The journey is, you guys are pioneering this journey of multi-cloud and cloud-native networking. And the soon gonna be a lot more coming. So I wanna get into the journey. What's it been like? Is it real? You got a lot of scar tissue? What are some of the learnings? Yeah, absolutely. So multi-cloud is whether or not we accept it as network engineers is a reality. Like Steve said, about two years ago, companies really decided to just bite the bullet and move there. Whether or not we accept that fact, we need to now create a consistent architecture across multiple clouds. And that is challenging without orchestration layers as you start managing different tool sets in different languages across different clouds. So it's really important to start thinking about that. Guys, on the other panelists here, there's different phases of this journey. Some come at it from a networking perspective. Some come at it from a problem troubleshooting. What's your experiences? Yeah, so from a networking perspective, it's been incredibly exciting. It's kind of a once in a generational opportunity to look at how you're building out your network. You can start to embrace things like infrastructure as code that maybe your peers on the systems teams have been doing for years, but it just never really worked on prem. So it's really exciting to look at all the opportunities that we have and then all the interesting challenges that come up that you get to tackle. And it affects that you guys are mostly AWS, right? Right now, though, we are looking at multiple clouds. We have production workloads running in multiple clouds today, but a lot of the initial work has been with Amazon. And you've seen it from a networking perspective. That's where you guys are coming at it from? Yep, yeah. Awesome. Bob, how about you? We evolved more from a customer requirement perspective. Started out primarily as AWS, but as the customer needed more resources from Azure like HPC, Azure AD, things like that. And even recently, Google Analytics, our journey has evolved into more of a multi-cloud environment. Steve, weigh in on the architecture because this is going to be a big conversation and I want you to lead this section. Yeah, so I mean, I think you guys agree, it seems like the journey started a couple of years ago, got real serious. The need for multi-cloud, whether you're there today, of course, it's going to be there in the future. So that's really important. I think the next thing is just architecture. I'd love to hear what you, had some comments about architecture matters. It all starts, I've met every enterprise I've talked to. Maybe talk about architecture and the importance of architecture. Maybe Bobby. So from our architecture perspective, we started a journey five years ago. Wow, okay. And we're just now starting our fourth evolution of our network architecture. And we call it network and security, net sec versus just as network. And that fourth generation architecture would be based primarily upon Palo Alto Networks and Aviatrix. Aviatrix doing the orchestration piece of it. But that journey came because of the need for simplicity, the need for multi-cloud orchestration without us having to go and do reprogramming efforts across every cloud as it comes along. Right. I guess the other question I also had around architecture is also Luis maybe just talk about, I know we've talked a little bit about scripting, right? And some of your thoughts on that. Yeah, absolutely. So for us, we started creating the network constructs with cloud formation. And we've stuck with that for the most part. What's interesting about that is today, on-premise, we have a lot of automation around how we provision networks. But cloud formation has become a little bit like the new manual for us. So we're now having issues with having to automate that component and making it consistent with our on-premise architecture, making it consistent with Azure architecture and Google Cloud. So it's really interesting to see companies now bring that layer of abstraction that SD-WAN brought to the WAN side. Now it's going up into the cloud and working architecture. So on the fourth generation, I'll be you mentioned you're in fourth gen architecture. What have you learned? Is there any lessons, scar tissue, what to avoid, what worked, what was some of the, what was the pattern you took? It's probably the biggest lesson there is that when you think you finally figured it out, you have it, right? Amazon will change something, Azure will change something, you know, transit gateway is a game changer. So, and listening to the business requirements is probably the biggest thing we need to do up front. But I think from a simplicity perspective, like I said, we don't want to do things four times. We want to do things one time. We want to be able to write to an API which Aviatrix has and have them do the orchestration for us so that we don't have to do it four times. How important is architecture in the progression? Is it you guys get thrown in the deep end to solve these problems or are you guys zooming out and looking at it? I mean, how are you guys looking at the architecture? Yeah, I mean, you can't get off the ground if you don't have the network there. So all of those, you know, we've gone through similar evolutions. We're on our fourth or fifth evolution. I think about what we started off with Amazon without a direct connect gateway, without a transit gateway, without a lot of the things that are available today, kind of the 80-20 that Steve was talking about. Just because it wasn't there doesn't mean we didn't need it. So we needed to figure out a way to do it. We couldn't say, oh, you need to come back to the network team in a year and maybe Amazon will have a solution for it, right? We need to do it now and evolve later and maybe optimize or change the way you're doing things in the future, but don't sit around and wait, you can't. I'd love to have you guys each individually answer this question for the live stream because it comes up a lot. A lot of cloud architects out in the community, what should they be thinking about? The folks that are coming into this proactively and or realizing that the business benefits are there, what advice would you guys give them on architecture? What should they be thinking about and what are some guiding principles you could share? So I would start with looking at an architecture model that can spread and give consistency to the different cloud vendors that you will absolutely have to support. Cloud vendors tend to want to pull you into using their native toolset and that's good if only it was realistic to talk about only one cloud, but because it doesn't, it's super important to talk about and have a conversation with the business and with your technology teams about a consistent model. How do I do my day one work so that I'm not spending 80% of my time troubleshooting or managing my network? Because if I'm doing that, then I'm missing out on ways that I can make improvements or embrace new technologies. So it's really important early on to figure out, how do I make this as low maintenance as possible so that I can focus on the things that the team really should be focusing on? Bobby, your advice to the architect. I don't know what else I can add to that. Simplicity of operations is key, right? All right, so the holistic view of day two operations you mentioned, let's jump in. Day one is you're getting stuff set up. Day two is your life after, right? This is kind of what you're getting at, David. So what does that look like? What are you envisioning as you look at that 20-mile stare post-multi-cloud world? What are some of the things that you want in the day two operations? Yeah, infrastructure as code is really important to us. So how do we design it so that we can fit, start making network changes and fitting them into a release pipeline and start looking at it like that rather than somebody logging into a router CLI and troubleshooting things in an ad hoc nature. So moving more towards the DevOps model. You got anything to add on that day two? Yeah, I would love to add something. So in terms of day two operations, you can either sort of ignore the day two operations for a little while where you get your feet wet or you can start approaching it from the beginning. The fact is that the cloud-native tools don't have a lot of maturity in that space and when you run into an issue, you're gonna end up having a bad day going through millions and millions of logs just to try to understand what's going on. So that's something that the industry just now is beginning to realize it's such a big gap. Yeah, I think that's key because for us, we're moving to more of an event-driven operations. In the past, monitoring got the job done. It's impossible to monitor something that's not there when the event happens. So the event-driven application and then detection is important. Yeah, I think Gardner was talking about the cloud-native way of coming into networking. That's gonna be a serious thing. I want to get your guys' perspectives. I know you have different views of how you're coming into the journey and how you're executing and I always say the beauty's in the eye of the beholder and that kind of applies to how the network's laid out. So Bob, you guys do a lot of high-performance encryption both on AWS and Azure. That's kind of a unique thing for you. How are you seeing that impact with multi-cloud? Yeah, and that's a new requirement for us too where we have an requirement to encrypt and they never get the question, should I encrypt, should I encrypt? The answer's always yes. You should encrypt when you can encrypt. For our perspective, we need to migrate a bunch of data from our data centers. We have some huge data centers and then getting that data to the cloud is a timely expense in some cases. So we have been mandated that we have to encrypt everything leaving the data center. So we're looking at using the Aviatrix insane mode appliances to be able to encrypt 10, 20 gigabits of data as it moves to the cloud itself. David, you're using Terraform, you got FireNet, you got a lot of complexity in your network. What do you guys look at the future for your environment? Yeah, so something exciting that we're working on now is FireNet. So for our security team, they obviously have a lot of knowledge based around Pal-Elto and with our commitments to our clients, it's not very easy to shift your security model to a specific cloud vendor, right? So there's a lot of, two compliance of things like that where being able to take some of what you've worked on for years on prem and put it in the cloud and have the same type of assurance that things are gonna work and be secure in the same way that they are on prem helps make that journey into the cloud a lot easier. And Luis, you guys got scripting, you got a lot of things going on. What's your unique angle on this? Yeah, no, absolutely. So full disclosure, I'm not an Aviatrix customer yet. It's okay, we wanna hear the truth. So that's good. Ellis, what are you thinking about? What's on your mind? No, really, when you talk about implementing a tool like this, it's really just really important to talk about automation and focus on value. So when you talk about things like encryption and things like, so yeah, encrypting tunnels and encrypting the path. And those things are, it should be second nature, really. When you look at building those back ends and managing them with your team, it becomes really painful. So tools like Aviatrix that add a lot of automation, it's out of sight, out of mind. You can focus on the value and you don't have to focus on those. I gotta ask you guys, obviously Aviatrix is here, they're a supplier to this sector, but you guys are customers. Everyone's pitching you stuff. People are not gonna even buy my stuff. How do you guys have that conversation with the suppliers, like the cloud vendors and other folks? What's it like, we're API all the way, you gotta support this. What are some of the, what are some of your requirements? How do you talk to and evaluate people that walk in and want to knock on your door and pitch you something? What's the conversation like? It's definitely API driven. We definitely look at the API structure that the vendors provide before we select anything. That is always first of mind and also what problem are we really trying to solve? Usually people try to sell or try to give us something that isn't really valuable, like implementing a Cisco solution on the cloud doesn't really add a lot of value, that's where we go. David, what's your conversation like with suppliers? Do you have a certain new way to do things? As becomes more agile, essentially networking become more dynamic. What are some of the conversations with the either the incumbents or new vendors that you're having? What do you require? Yeah, so ease of use is definitely high up there. We've had some vendors come in and say, hey, when you go to set this up, we're gonna want to send somebody on site and they're gonna sit with you for a day to configure and that's kind of a red flag. Well, wait a minute, do we really, if one of my really talented engineers can't figure it out on his own, what's going on there and why is that? So having some ease of use and the team being comfortable with it and understanding it is really important. Bobby, how about you? I mean, the old days was do a bake off and the winner takes all. I mean, is it like that anymore? But what's evolving? You did a bake off last year for us, do you win? But that's different now, because now when you get the product, you can install the product in AWS and Azure, have it up and running in a matter of minutes. And so the key is, can you be operational within hours or days instead of weeks, right? But do we also have the flexibility to customize it to meet your needs? You don't wanna be put into a box with the other customers when you have needs that surpass their needs. Yeah, I can almost see the challenge of you guys are living where you've got the cloud immediate value, depending on how you can roll up any solutions. But then you might have other needs so you gotta be careful not to buy into stuff that's not shipping. So you're trying to be proactive at the same time, deal with what you got. I mean, how do you guys see that evolving? Because multi-cloud to me is definitely relevant, but it's not yet clear how to implement a cross. How do you guys look at this? Baked versus future solutions coming. How do you balance that? So again, so right now we're taking the ad hoc approach and experimenting with the different concepts of cloud and really leveraging the native constructs of each cloud. But there's a breaking point for sure. You don't get to scale this like Simone said and you have to focus on being able to deliver a developer their sandbox or their play area for the things that they're trying to build quickly. And the only way to do that is with some sort of consistent orchestration layer that allows you to... So you expect a lot more stuff to be coming pretty quickly in this area? I do expect things to start maturing quite quickly this year. And you guys see similar trend, new stuff coming fast? Yeah, probably the biggest challenge we've got now is being able to segment within the network, being able to provide segmentation between production, non-production workloads, even businesses. Because we support many businesses worldwide and the oscillation between those is a key criteria there. So the ability to identify and quickly oscillate those workloads is key. So the CIOs that are watching are saying, hey, take that hill, do multi-cloud, and then the bottoms up organization like POS, you're kind of like off a little bit. It's not how it works. I mean, what is the reality in terms of implementing as fast as possible? Because the business benefits are clear but it's not always clear in the technology how to move that fast. What are some of the barriers? What are the blockers? What are the enablers? I think the reality is that you may not think you're multi-cloud but your business is, right? So I think the biggest barrier there is understanding what the requirements are and how best to meet those requirements in a secure manner. Because you need to make sure that things are working from a latency perspective, that things work the way they did. And get out of the mind shift that it was a tier three application in the data center, it doesn't have to be a tier three application in the cloud, right? So lift and shift is not the way to go. Scale is a big part of what I see is the competitive advantage of a lot of these clouds and it used to be proprietary network stacks in the old days and then open systems came, that was a good thing. But as clouds become bigger, there's kind of an inherent lock-in there with the scale. How do you guys keep the choice open? How are you guys thinking about interoperability? What are some of the conversations that you guys are having around those key concepts? Well, when we look at, from a networking perspective, it's really key for you to just enable all the clouds to be able to communicate between them. Developers will find a way to use the cloud that best suits their business needs. And like you said, it's whether you're in denial or not of the multi-cloud fact that your company is in already. It becomes really important for you to move quickly. Yeah, and a lot of it also hinges on how well is the provider embracing what that specific cloud is doing. So are they swimming with Amazon or Azure and just helping facilitate things? They're doing the heavy lifting API work for you or are they swimming upstream and they're trying to hack it all together in a messy way? And so that helps you stay out of the lock-in because if they're using Amazon native tools to help you get where you need to be, it's not like Amazon's gonna release something in the future that completely makes you have designed yourself into a corner. So the closer they are, the more cloud-native they are, the easier it is to deploy. But you also need to be aligned in such a way that you can take advantage of those cloud-native technologies, really makes sense. TGW is a game changer in terms of cost and performance. So to completely ignore that would be wrong. But if you needed to have encryption, TGW is not encrypted, so you need to have some type of gateway to do the VP at encryption. So the AVA tricks tool gives you the beauty of both worlds. You can use TGW for the gateway. Real quick on the last minute we have, I want to just get a quick feedback from you guys. I hear a lot of people say to me, hey, pick the best cloud for the workload you got then figure out multi-cloud behind the scenes. So that seems to be, do you guys agree with that? I mean, do I go one cloud across the whole company or this workload works great on AWS? That workload is great on this? From a cloud standpoint, do you agree with that premise and then with this multi-cloud stitch them all together? Yeah, from an application perspective, it can be per workload, but it can also be an economical decision. Certain enterprise contracts will pull you in one direction to add value. But the network problem is still the same. Yeah, it doesn't go away. Yeah. I mean, you don't want to be trying to fit a square into a round hole, right? So if it works better on that cloud provider, then it's our job to make sure that that service is there and people can use it. Yeah, I agree. You just need to stay ahead of the game, make sure that the network infrastructure is there, secure, it's available, and it's multi-cloud capable. Yeah, I'm at the end of the day. You guys just validate in that it's the networking game now. Cloud, storage, compute, check, networking is where the action is, awesome. Thanks for your insights. Guys, appreciate you coming on the panel. Appreciate it, thanks.