 Good morning, ladies and gentlemen. This is your captain speaking. We will soon be taking off on our way to Altitude. Please keep your seat belts fast and remain in your seats. We will be experiencing turbulence until we are above the clouds. Ladies and gentlemen, we are now cruising at Altitude. Sit back and enjoy the ride. Altitude is a community of thought leaders and pioneers, cloud architects and enlightened network engineers who have individually and are now collectively leading their own IT teams and the industry on a path to lift cloud networking above the clouds, empowering enterprise IT to architect, design and control their own cloud network, regardless of the turbulent clouds beneath them. It's time to gain Altitude. Ladies and gentlemen, Steve Malaney, president and CEO of AVA Tricks, the leader of multi-cloud networking. Good morning, everybody here in Santa Clara, as well as to the millions of people watching the live stream worldwide. Welcome to Altitude 2020. All right, so we've got a fantastic event today. I'm really excited about the speakers that we have today and the experts that we have and really excited to get started. So one of the things I wanted to just share was this is not a one-time event. This is not a one-time thing that we're gonna do. Sorry for the aviation analogy, but Sherry Way, AVA Tricks means female pilot, so everything we do has an aviation theme. This is a take-off for a movement. This isn't an event. This is a take-off of a movement, a multi-cloud networking movement and community that we're inviting all of you to become part of. And why we're doing that is we wanna enable enterprises to rise above the clouds, so to speak and build their network architecture regardless of which public cloud they're using, whether it's one or more of these public clouds. So the good news for today, and there's lots of good news, but this is one good news, is we don't have any PowerPoint presentations, no marketing speak. We know that marketing people have their own language. We're not using any of that in those sales pitches. So instead, what are we doing? We're gonna have expert panels. We've got Simone Richard of Gardner here. We've got 10 different network architects, cloud architects, real practitioners that are gonna share their best practices and their real-world experiences on their journey to the multi-cloud. So before we start, everybody know what today is. In the US, it's Super Tuesday. I'm not gonna get political, but Super Tuesday, there was a bigger Super Tuesday that happened 18 months ago. And AVH6 employees know what I'm talking about. 18 months ago, on a Tuesday, every enterprise said, I'm gonna go to the cloud. And so what that was, was the Cambrian explosion for cloud for the enterprise. So Frank Cabri, you know what Cambrian explosion is. He had to look it up on Google. 500 million years ago, what happened? There was an explosion of life where it went from very simple, single-cell organisms to very complex multi-cell organisms. Guess what happened? 18 months ago on a Tuesday, I don't really know why, but every enterprise, like I said, all woke up that day and said, now I'm really gonna go to cloud. And that Cambrian explosion of cloud meant that I'm moving from a very simple, single-cloud, single-use case, simple environment to a very complex, multi-cloud, complex use case environment. And what we're here today is we're gonna go and dress that. And how do you handle those complexities? And when you look at what's happening with customers right now, this is a business transformation. People like to talk about transitions. This is a transformation. And it's actually not just a technology transformation, it's a business transformation. It started from the CEO and the boards of enterprise customers where they said, I have an existential threat to the survival of my company. If you look at every industry who they're worried about is not the other 30-year-old enterprise. What they're worried about is the three-year-old enterprise that's leveraging cloud, that's leveraging AI, and that's where they fear that they're gonna actually get wiped out. And so because of this existential threat, this is CEO-led, this is board-led, this is not technology-led. It is mandated in the organizations. We are going to digitally transform our enterprise because of this existential threat, and the movement to cloud is gonna enable us to go do that. And so IT is now put back in charge. If you think back just a few years ago in cloud, it was led by DevOps, it was led by the applications, and it was, like I said, before the Cambrian explosion is very simple. Now with this Cambrian explosion, an enterprise is getting very serious and mission critical. They care about visibility, they care about control, they care about compliance, conformance, everything, governance, IT is in charge, and that's why we're here today to discuss that. So what we're gonna do today is much of things, but we're gonna validate this journey with customers. Did they see the same thing? We're gonna validate the requirements for multi-cloud because honestly I've never met an enterprise that is not going to be multi-cloud. Many are one cloud today but they all say I need to architect my network for multiple clouds because that's just what the network is there to support the applications and the applications will run and whatever cloud it runs best in and you have to be prepared for that. The second thing is architecture. Again, with IT in charge, architecture matters. Whether it's your career, whether it's how you build your house, it doesn't matter. Horrible architecture, your life is horrible forever. Good architecture, your life is pretty good. So we're gonna talk about architecture and how the most fundamental and critical part of that architecture and that basic infrastructure is the network. If you don't get that right, nothing works, right? Way more important than compute, way more important than storage. Network is the foundational element of your infrastructure. Then we're gonna talk about day two operations. What does that mean? Well day one is one day of your life, but I'm sure you wire things up. Day two and beyond, I tell everyone in networking and IT, it's every day of your life. And if you don't get that right, your life is bad forever. And so things like operations, visibility, security, things like that, how do I get my operations team to be able to handle this in an automated way because it's not just about configuring it in the cloud, it's actually about how do I operationalize it? And that's a huge benefit that we bring as AVATRIPS. And then the last thing we're gonna talk and it's the last panel we have, I always say you can't forget about the humans, right? So all this technology, all these things that we're doing, it's always enabled by the humans. At the end of the day, if the humans fight it, it won't get deployed. And we have a massive skills gap in cloud and we also have a massive skills shortage. You have everyone in the world trying to hire cloud network architects, right? There's just not enough of them going around. So at AVATRIPS, we said as leaders do, we're gonna help address that issue and try to create more people. We created a program and we call the ACE program, again, aviation theme. Stands for AVATRIPS certified engineer, very similar to what Cisco did with CCIEs. Where Cisco taught you about IP networking, a little bit of Cisco, we're doing the same thing. We're gonna teach network architects about multi-cloud networking and architecture. And yeah, you'll get a little bit of AVATRIPS training in there, but this is the missing element for people's careers and also within their organization. So we're gonna go talk about that. So great event, great show, we're gonna try to keep it moving. I'd next wanna introduce my host. He's the best in the business. You guys have probably seen him, multiple willing times. He's the co-CEO and co-founder of theCUBE, John Forrier. Yeah. Okay, awesome, great speech there, awesome. I totally agree with everything you said of the explosion happening. And I'm excited here at the heart of Silicon Valley to have this event. It's a special digital event with theCUBE and AVATRIPS where we live streaming to millions of people, as you said, maybe not a million, maybe not a million. Really take this program to the world. And this is a little special for me because multi-cloud is the hottest wave in cloud. And cloud-native networking is fast becoming the key engine of the innovation. So we got an hour and a half of action-packed programming. We have a customer panel, two customer panels. Before that, Gartner's gonna come on and talk about the industry. We have a global system integrators. They're talking about how they're advising and building these networks and cloud-native networking. And then finally, the ACES, the AVATRIPS certified engineer, is gonna talk more about their certifications and the expertise needed. So let's jump right in and let's ask Simone Richard to come on stage from Gartner. We'll kick it all off. All right. There you go. Okay, so kicking things off, certain started. Gartner, the industry experts on cloud. Really kind of more too, your background. Talk about your background before you got to Gartner. Yeah, before being at Gartner, I was a chief network architect of a Fortune 5 company with thousands of sites over the world. And I've been doing everything in IT from a C programmer in IT to a security architect to a network engineer to finally becoming a network analyst. So you rode the wave and now you're covering at the marketplace with hybrid cloud and now moving quickly to multicloud is really what I was talking about. Cloud-native's been discussed but the networking piece is super important. How do you see that evolving? Well, the way we see enterprise-adapted in cloud, first thing you do about networking, the initial phases, they either go in a very ad hoc way as usually led by non-IT, like a shadow IT or application people or sometime a DevOps team. And it's completely unplanned. They create VPCs left and right with different accounts and they create mesh to manage them and they have direct connect or express route to any of them. So that's a first approach. And on the other side, again, within a first approach, you see what I call the lift and shift way. We see enterprise IT trying to basically replicate what they have in a data center in the cloud. So they spend a lot of time planning, doing direct connect, putting Cisco routers and F5 and Citrix and any checkpoint Palo Alto, devise a data center, moving that to the cloud. I gotta ask you, the aha moment is gonna come up a lot in our panels is where people realize that it's a multicloud world. I mean, they either inherit clouds, certainly they're using public cloud and on-premises is now more relevant than ever. When's that aha moment that you're seeing where people go, well, I gotta get my act together and get on the cloud. Even before multicloud, so of these two approach, the first one like the ad hoc way doesn't scale. At some point, IT has to save them because they don't think about D2, they don't think about operations. They have a bunch of VPC and multiple clouds. The other way that if you do the lift and shift way, they cannot take any advantages of the cloud. They lose elasticity, auto scaling, pay by the drink, these feature all agility features. So they both realize, okay, neither of these ways are good. So I have to optimize that. So I have to have a mix of what I call the cloud native services within each cloud. So they start adopting like all the AWS construct, Azure construct or Google construct. And that's what I call the optimal phase. But even that, they realize up to that they're all very different. All these approaches are different. The cloud are different. Identity is completely difficult to manage across clouds. I mean, for example, AWS has accounts, there's subscription in Azure and GCP, they're projects, it's a real mess. So they realize, well, I can actually like concentrate use the cloud product in every cloud. That doesn't work. So I have, I'm going multi-cloud. I like to abstract all of that. I still wanna manage the cloud from an API point of view. But I don't necessarily wanna bring my incumbent data center products. But I have to do that in a more API driven cloud. They're not scaling piece that you were mentioning. That's because there's too many different clouds. Yes. That's the piece there. So what are they doing? What are they building different development teams? Is it software? What's the solution? Well, the solution is to start architecting the cloud. And that's the third phase. I call that the multi-cloud architect phase. Where they have to think about abstraction that works across cloud. In fact, even across one cloud, it might not scale as well. If you start having like 10,000 security group in AWS that doesn't scale, you have to manage that. If you have multiple VPC, it doesn't scale. You need a third party identity provider. So it barely scales within one cloud. If you go multiple cloud, it gets worse and worse. Steve, weigh in here. What's your thoughts? I thought we said this wasn't gonna be a sales pitch for AVATrix. You just said exactly what we do. So anyway, that's a joke. What do you see in terms of where people are in that multi-cloud? So like a lot of people, everyone I talked to started in one cloud, right? But then they look and they say, okay, but I'm now gonna move to Azure and I'm gonna move to Azure. Do you see a similar thing? Well, yes. They are moving, but there's not a lot of application that use a tree cloud at once. They move one app in Azure, one app in AWS, one app in Google. That's what we see so far. Yeah, I mean, one of the mistakes that people think is they think multi-cloud. No one is ever gonna go multi-cloud for arbitrage. They're not gonna go and say, well, today I might go into Azure because I get a better rate in my instance. That's never, do you agree with that? That's never gonna happen. What I've seen with Enterprise is I'm gonna put the workload and the app, the app decides where it runs best. That maybe Azure, maybe Google, and for different reasons, and they're gonna stick there and they're not gonna move. Well, let me ask you guys. But the infrastructure has to be able to support from a networking team be able to do that. Do you agree with that? Yes, I agree. And one thing that's also very important is connecting to the cloud is kind of the easiest thing. So while they're a network part of the cloud, connectivity to the cloud is kind of simple. I agree. IPsec, VPN, Direct Connect, Express Cloud. That's the simple part. What's difficult, and even the provisioning part is easy. You can use Terraform and create VPCs and VNets across the three cloud providers. What's difficult is the day to the operations. So we'll define day two operations. What does that actually mean? This is just the day to the operations. After, you know, the natural, let's add an app, let's add a server, let's troubleshoot a problem. So what happened after provisioning? So your life after you- Something changes. Now what do you do? So what's the big concerns? I wanna just get back to this cloud-native networking because everyone kind of knows what cloud-native apps are. That's been the hot trend. What is cloud-native networking? How do you guys define that? Because that seems to be the hottest part of the multi-cloud wave that's coming is cloud-native networking. Well, there's no official gardener definition, but I can create one on the spot, let's do it. I just want to leverage the cloud construct and the cloud API. I don't want to have to install, like, for example, the first version was let's put a virtual router that doesn't even understand the cloud environment. If I have to install a virtual machine, it has to be cloud-aware, it has to understand the security group if it's a router, it has to be programmable to the cloud API and understand the cloud environment. You know, one of the things I hear a lot from either CISOs or CIOs or CXOs in general is this idea of I'm definitely a going API, so it's been an API economy, so API is key on that point. But then they say, okay, I need to essentially have the right relationship with my suppliers, aka clouds, you call it above the clouds. So the question is, what do I do from an architecture standpoint? Do I just hire more developers and have different teams? Because you mentioned that's a scale point. How do you solve this problem of, okay, I got AWS, I got GCP or Azure or whatever. Do I just have different teams or I just expose APIs? Where is that optimization? Where's the focus? Well, I take what you need from an entry point of view as a way, a control plane across the three clouds and be able to use the APIs of the cloud to build networks but also to troubleshoot them and do they to operation. So you need a view across a tree cloud that takes care of routing connectivity. That's seen, that's the AVI tree plug-up you were right there. So how do you see, so again, your Gartner, you see the industry, you've bet on network architect. How do you see this playing out? What are the legacy incumbent client servers on-prem networking people gonna do versus people like Aviatrix, how do you see that playing out? Well, obviously all the incumbent like Arista, Cisco, Juniper, NSX, they wanna basically do the lift and chip part. They wanna bring, and you know, VMware wants to bring NSX and the cloud, they call that NSX everywhere and Cisco wants to bring NSX and the cloud, they call that NSX anywhere. So everyone, and then there's cloud vision for my Rista and Contrail is in the cloud. So they just want to bring the management plane and the cloud, but it's still based, most of them is still based on putting a VM them and controlling them. You extend your management console to the cloud. That's not truly cloud native. Cloud native, you almost have to build it from scratch. We like to call that cloud naive. Cloud naive, yeah. So close, one letter, right? Yeah, so that was a big contribution I reinvent. Take the T out of cloud native, it's cloud naive. That went super viral. You guys got T-shirts now, I know you love that. But that really ultimately is kinda double that sort. You can be naive on the architecture side and rolling that, but also suppliers can be naive. So how would you define who's naive and who's not? Well, in fact, they're evolving as well. So for example, in Cisco, it's a little bit more native than other ones because they really, ACI in the cloud, you really like configure the APIs of the cloud and NSX is going that way and so is Arista. But they're incumbent, they have their own tools, it's difficult for them, they're moving slowly. So it's much easier to start from scratch, have a new like, and you know, a network company that started a few years ago, there's only really two. AVA Tricks was the first one, they've been there for at least three or four years. And there's other ones like Alcira, for example, that just started. Now they're doing more connectivity, but they wanna create an overlay network across the cloud and start doing policies and abstracting all the clouds within one platform. So I gotta ask you, I interviewed executive at VMware, Sanjay Poonan, he said to me at RSA last week, oh, there'll only be two networking vendors left Cisco and VMware, what's your response to that? What's your response to that? Obviously, I mean, when you have these waves as new brands that emerge like Aviation and others, I think there'll be a lot of startups coming out of the woodwork. How do you respond to that comment? Well, there's still a data center, there's still like a lot of action on campus and there's the one. But from the cloud provisioning and cloud networking in general, I mean, they're behind, I think. In fact, you don't even need them to start with. You can, if you're small enough, you can just keep, if you're in AWS, you can use AWS construct, they have to insert themselves. I mean, they're running behind from that point of view. Yeah, they're all certainly incumbents. I love the term Andy Jesses at Amazon, web services, he uses old guard, new guard to talk about the industry. What does the new guard have to do? The new brands that emerge in, is it be more DevOps oriented? Is it NetSecOps? Is it NetOps? Is it programmability? These are some of the key discussions we've been having. What's your view on how you see this programmability? The most important part is they have to make the network simple for the dev teams. And you cannot make a phone call and get a V-line in two weeks anymore. So if you move to the cloud, you have to make the cloud construct as simple enough so that, for example, a dev team could say, okay, I'm gonna create this VPC. But this VPC automatically being associated to your account, you cannot go out on the internet, you have to go to transit VPC. So there's a lot of action in terms of the IAM part and then you have to put the control around them too. So to make it as simple as possible. You guys both, I mean, you're the COC aviatrix, but also you guys, a lot of experience going back to networking, going back to, I call the OSI days, for us old folks, know what that means, but you guys know what this means. I wanna ask you the question. As you look at the future of networking, you hear a couple of objections. Oh, the cloud guys, they got networking, we're all set with them. How do you respond to the fact that networking's changing and the cloud guys have their own networking? What are some of the pain points that's going on, premises in these enterprises? So are they good with the clouds? What needs, what are the key things that's going on in networking that makes it more than just the cloud networking? What's your take on that? Well, as I said earlier that once you, you could easily provision in the cloud, you can easily connect to the cloud, is when you start troubleshooting application in the cloud and try to scale. So this, that's where the problem occurs. Steve, what's your take on it? And you'll hear from the customers that we have on stage and I think what happens is all the clouds by definition designed to the 80-20 role, which means they'll design 80% of the basic functionality and they'll leave the 20% extra functionality that of course every enterprise needs, they'll leave that to ISVs like aviatrix. Because why? Because they have to make money, they have a service and they can't have huge instances for functionality that not everybody needs. So they have to design to the common and they all do it, right, they have to. And then the extra, the problem is, that came being an explosion that I talked about with enterprises, that's what they need, that they're the ones who need that extra 20%. So that's what I see is there's always gonna be that extra functionality in an automated and simple way that you talked about, but yet powerful with the visibility and control that they expect of on-prem. That kind of combination that Yin and Yang that people like us are providing. So I wanna ask you, we're gonna ask some of the cloud architect customer panels, so it's the same question. This pioneer's doing some work here and there's also the laggards who come in behind the early adopters. What's gonna be the tipping point? What are some of those conversations that the cloud architects are having out there? Or what's the signs that they need to be on this multi-cloud or cloud-native networking trend? What are some of the signals that are going on in their environment? What are some of the thresholds or things that are going on that they can pay attention to? Well, once they have application in multiple cloud and they get to wake up at two in the morning to triple shoot them, they don't know it's important. So I think that's where the rubber will hit the road. But as I said, it's easier to provide it because okay, it's AWS, it's easy, use a transit gateway, put the QVPCs and you're done and create some presence like Equinox and do direct connect and express route with Azure. That looks simple. As the operations, that's when they realize, okay, now I need to understand how cloud networking works. I also need a tool that gives me visibility and control. But not only that, I need to understand the basic underneath it as well. What are some of the day-in-the-life scenarios that you envision happening with multi-cloud? Because if you think about what's happening, it kind of has that same vibe of interoperability, choice, multi-vendor, because you have multi-cloud, essentially multi-vendor. These are kind of old paradigms that we've lived through with client server and internet working way. What are some of those scenarios of success and that might be possible or would be possible with multi-cloud and cloud-native networking? Well, I think once you have good enough visibility to satisfy your customers, not only like to keep the service running and application running, but to be able to provision fast enough, I think that's what you want to achieve. Simone, final question. Advice for folks watching on the live stream, if they're sitting there as a cloud architect or a CXO, what's your advice to them right now in this market? There's obviously public cloud check, hybrid cloud, they're working on that, that gets on premises done, now multi-cloud's right behind it, what's your advice? The first thing they should do is really try to understand cloud networking for each of the cloud providers and then understand the limitation and is what the cloud service provider offers enough or you need to look to a third party. But you don't look at a third party to start with, especially an incumbent one. So it's tempting to say, oh man, I have a bunch of F5 experts, nothing against F5, and I'm gonna bring my F5 in the cloud when you can use an ELB that automatically understand AZs and auto scaling and so on. And you understand that's much simpler, but sometimes you need your F5 because you have requirements, you have like I rules and that kind of stuff that you use for years, you cannot do it, so okay, I have requirement and I'm not met, I'm gonna use legacy stuff. And then you have to start taking, okay, what about visibility control about the three cloud? But before you do that, you have to understand the limitation of the existing cloud providers. So first, try to be as native as possible until things don't work. After that, you can start taking multi-cloud. Great insight, someone, thank you for coming on, someone in charge. With Gardner, thanks for sharing. Thank you. Appreciate it. Thanks a lot. Thank you. Thank you. Thanks, that's great. Informatica is known as the leading enterprise cloud data management company. We are known for being the top in our industry and at least five different products. Over the last few years, especially we've been transforming into a cloud model, which allows us to work better with the trends of our customers. In order to say agile and effective in a business, you need to make sure that your products and your offerings are just as relevant in all these different clouds than what you're used to and what you're comfortable with. One of the most difficult challenges we've always had is that because we're a data company, we're talking about data that a customer owns. Some of that data may be in the cloud, some of that data may be on-prem. Some of that data may be actually in their data center in another region or even another country. And having that data connect back to our systems that are located in the cloud has always been a challenge. When we first started our engagement with Aviatrix, we only had one plan. That was Amazon. It wasn't till later that Azure came up and all of a sudden we found, hey, the solution we already had in place for Aviatrix already working in Amazon now works in Azure as well. Before we knew it, GCP came up, but it really wasn't a big deal for us because we already had the same solution in Amazon and in Azure now just working in GCP. By having a multi-cloud approach, we have access to all three of them, but more commonly it's not just one, it's actually integrations between multiple. We have some data in Azure that we wanna integrate with Amazon. We have some data in GCP that we wanna bring over to a data lake in Azure. One of the nice things about Aviatrix is that it gives a very simple interface that my staff can understand and use and manage literally hundreds of VPNs around the world while talking to and working with our customers who are literally around the world. Now that we've been using Aviatrix for a couple years, we're actually finding that even problems that we didn't realize we had were actually solved even before we came across the problem and it just worked. Cloud companies as a whole are based on reputation. We need to be able to protect our reputation and part of that reputation is being able to protect our customers and being able to protect, more importantly, our customers' data. Aviatrix has been helpful for us in that we only have one system that can manage this whole huge system in a simple, easy direct model. Aviatrix is directly responsible for helping us secure and manage our customers not only across the world, but across multiple clouds. Users don't have to be VPN or networking experts in order to be able to use the system. All the members on my team can manage it. All the members, regardless of their experience, can do different levels of it. One of the unexpected advantages of Aviatrix is that I don't have to sell it to my management. The fact that we're not in the news at three o'clock in the morning or that we don't have to get calls in the middle of the night, no news is good news, especially in networking. Things that used to take weeks to build are done in hours. I think the most important thing about Aviatrix is it provides me consistency. Aviatrix gives me a consistent model that I can use across multiple regions, multiple clouds, multiple customers. Okay, welcome back to Altitude 2020 for the folks on the live stream. I'm John Furrier, Steve Mullaney with CEO of Aviatrix. 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 Shidnik 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. Thank you. Okay. Okay, customer panel, this is my favorite part. We get to hear the real scoop, we get the gardener giving us the industry overview. Certainly multi-cloud is very relevant in cloud native networking is the hot trend with the live stream out there and the digital events. 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 and 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 out 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 of the interesting challenges that come up that you get to tackle. And in fact, said you guys are mostly AWS, right? Yep, right now, 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. Awesome. 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. Even recently, Google Analytics, our journey has evolved into a more of a multi-cloud environment. Steve, weigh in on the architecture because this is gonna be a big conversation. I want you to lead this section. Yeah, so I mean, I think you guys agree, it seems like the journey started a couple years ago, got real serious. The need for multi-cloud, whether you're there today, of course, it's gonna 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. As a architecture perspective, we started our journey five years ago. Wow, okay. And we're just now starting our fourth evolution of our network architecture. And we call it network insecurity, 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 with 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 networking architecture. So on the fourth generation, Avi, 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 the pattern you took? It's probably the biggest lesson there is that when you think you finally figured it out, you haven't, right? Amazon will change something, Azure will change something. Transit Gateway is a game changer. So 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 Avi Aitrix 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, 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 different cloud vendors that you will absolutely have to support. Cloud vendors tend to want to pull you into using their native tool set 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. So that's it. Yeah, we were talking as a group earlier about day two operations. So how do I design, 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 that simplicity of operations is key, right? All right, so the holistic view of day two operation 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 miles there post multi-cloud world? What are some of the things that you want in a day two operations? Yeah, infrastructure as code is really important to us. So how do we design it so that we can 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. 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 wave coming into networking. That's gonna be a serious thing. I wanna get your guys' perspectives. I know you have different views of how you come into the journey and how you're executing and I always say the beauties in the eye are the beholder and that kind of applies to how the network's laid out. So, Bobby, 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 if you ever 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 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've got FireNet. You've 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 Palo Alto. 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 stuff. Two compliance and 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 ABA tricks 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 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 ABA tricks 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. So, I gotta ask you guys, obviously ABA tricks is here, they're a supplier to this sector, but you guys are customers. Everyone's pitching you stuff. People are not gonna be able to 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 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 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. 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? We did a bake-off last year for SDWN. But that's different now because now when you get the product, you can install the product in AWS and as you have it up and running it in a matter of minutes. So the key is, can you be operational within hours or days instead of weeks? 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 that you guys are living where you've got the cloud immediate value depending 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? Cause 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 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 and non-production workloads, even businesses, because we support many businesses worldwide and isolation between those is a key criteria there. So the ability to identify and quickly isolate 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 pause, 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 on 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. 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, you know, it was a tier three application in the data center, it doesn't have to be a tier three application into cloud. So lift and shift is not the way to go. Scale's a big part of what I see is the competitive advantage of all these clouds and they 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, when we look at from a networking perspective, it's really key for you to just enable, enable all the clouds to be, 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, that's, 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? And 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, more cloud native they are, the easier it is to deploy. Which also need to be aligned in such a way that you can take advantage of those cloud-nating 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 VPN encryption. So the Aviatrix tool gives you the beauty of both worlds. You can use TGW for the gateway. Real quick on the last minute we have, I wanna 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 and then figure out multi-cloud behind the scenes. So that seems to be, do you guys agree with that? I mean, is it, 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 where does 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 wanna 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 validating 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. Thank you. Okay. Thank you. See you guys. Bye. Okay, welcome back on the live feed. I'm John Ford, Steve Bellini, my co-host for the AVA Tricks. I'm with theCUBE for the special digital event. Our next customer panel got great, another set of cloud network architects, Justin Smith, Uzora, Justin Brodeley with LA May, and Amit Otrija with Koopa. Welcome to the stage. All right, thank you. Thank you. Thank you. Thank you. Amit, that's the warrior. Okay. Did he say it? Okay, you've got all the cliff notes from the last session. Welcome back. Rinse and repeat. Yeah. We're gonna go under the hood a little bit. I think they nailed what we've been reporting and we've been having this conversation around. Networking is where the action is because that's the end of the day. You gotta move a packet from A to B and you got workloads exchanging data so it's really killer. So let's get started. Amit, what are you seeing as the journey of multi-cloud? As you go under the hood and say, okay, I gotta implement this, I have to engineer the network. Make it enabling, make it programmable, make it interoperable across clouds. And that's like, I mean, almost sounds impossible to me. What's your take? Yeah, I mean, it seems impossible, but if you are running an organization which is running infrastructure as a code and all right, it is easily doable. Like you can use tools out there that's available today. You can use third-party products that can do a better job. But put your architecture first. Don't wait. Architecture may not be perfect. Put the best architecture that's available today and be agile to iterate and make improvements over the time. We got two Justin's over here, so I have to be careful when I point a question to Justin. They both have to answer. But okay, journeys, what's the journey been like? I mean, is there phases we heard that from Gardner? People come into multi-cloud and cloud-native networking from different perspectives. What's your take on the journey, Justin? Yeah, I mean, from our perspective, we started out very much focused on one cloud. And as we started doing acquisitions, we started doing new products in the market. The need for multi-cloud comes very apparent very quickly for us. And so, you know, having an architecture that we can plug and play into and be able to add and change things as it changes is super important for what we're doing in the space. Justin, your journey. Yeah, for us, we were very ad hoc oriented. And the idea is that we were reinventing all the time, trying to move into these new things and coming up with great new ideas. And so rather than it being some iterative approach with our deployments, that became a number of different deployments. And so we shifted that toward, and the network has been a real enabler of this, is that there's one network and it touches whatever cloud we want it to touch and it touches the data centers that we need it to touch and it touches the customers that we need it to touch. Our job is to make sure that the services that are available in one of those locations are available in all of the locations. So the idea is not that we need to come up with this new solution every time, it's that we're just iterating on what we've already decided to do. Before we get to the architecture section, I wanna ask you guys a question. I'm a big fan of, you know, let the app developers have infrastructure as code, so check. But having the right cloud run that workload, I'm a big fan of that if it works, great. But we just heard from the other panel, you can't change the network. So I wanna get your thoughts. What is cloud native networking and is that the engine really that's the enabler for this multi-cloud trend? What's your guys taking? We'll start with a minute. What do you think about that? Yeah, so you are gonna have workloads running in different clouds and the workloads would have affinity to one cloud over other, but how you expose that, it's a matter of how you are gonna build your networks, how you are gonna run security, how you are gonna do egress, ingress out of it. So that's- You said networking is the big problem, itself. Yes, yeah. How do you, what's the solution? What's the key pain points and problem statement? I mean, the key pain point for most companies is how do you take your traditionally on-premise network and then blow it out to the cloud in a way that makes sense. You know, IP conflicts, you have IP space, you have public IPs on-premise as well as in the cloud, and how do you kind of make a sense of all of that? And I think that's where tools like Aviatrix make a lot of sense in that space. From our side, it's really simple. It's latency, it's bandwidth and availability. These don't change whether we're talking about cloud or data center or even corporate IT networking. So our job when all of these things are simplified into like S3, for instance, and our developers wanna use those. We have to be able to deliver that and for a particular group or another group that wants to use just GCP resources. These aren't, we have to support these requirements and these wants as opposed to saying, hey, that's not a good idea. No, our job is to enable them, not to disable them. Do you think guys, do you guys think infrastructure as code, which I love that, I think that's the future it is. We saw that with DevOps. But I just start getting the networking. Is it getting down to the network portion where it's network as code? Because storage and compute working really well. You're seeing all Kubernetes on service mesh's trend. Network as code. Reality, is it there, is it still got work to do? It's absolutely there. I mean, you mentioned NetDevOps and it's very real. I mean, in Koopa, we build our networks through Terraform and on, not only just Terraform, build an API so that we can consistently build VNets and VPC all across in the same way. So you guys are doing it? Yeah, and even security groups. And then on top, when Aviatrix comes in, we can peer the networks, bridge all the different regions through code. Same for you guys. What do you think about this? Everything we deploy is done with automation. And then we also run things like Lambda on top to make changes in real time. We don't make manual changes on our network. In the data center, funny enough, it's still manual. But the cloud has enabled us to move into this automation mindset. And all my guys, that's what they focus on is bringing now what they're doing in the cloud into the data center, which is kind of opposite of what it should be. So it's full. Or what it used to be. It's full DevOps, then. Yes. Yeah, I mean, for us, it was similar. On-prem is still somewhat very manual, although we're moving more to Ninja and Terraform-type concepts. But everything in the production environment is code formation, Terraform code, and now we're coming into the data center. I just wanted to jump in on Justin Smith, one of the comment that you made, because that's something that we always talk about a lot, is that the center of gravity of architecture used to be an on-prem, and now it's shifted into cloud. And once you have your strategic architecture, what do you do? You push that everywhere. So what you used to see at the beginning of cloud was pushing the architecture on-prem into cloud. Now, I want to pick up on what you said. Do you others agree that the center of gravity is here? I'm now pushing what I do in the cloud back into on-prem. And then so first that, and then also in the journey, where are you at from 0 to 100 of actually in the journey to cloud? Are you 50% there? Are you 10%? Yeah, so I mean. Are you evacuating data centers next year? I mean, where are you guys at? Yeah, so there's two types of gravity that you typically are dealing with in a migration. First is data gravity in your data set and where that data lives. And then the second is the network platform that interrupts all that together. In our case, the data gravity is still mostly on-prem, but our network is now extending out to the app tier that's going to be in cloud. Eventually, that data gravity will also move to cloud as we start getting more sophisticated. But on our journey, we're about halfway there. Halfway through the process, we're taking a handle of lift and shift. And when did that start? We started about three years ago. OK. OK. Well, for Koopa, it's a very different story. It started from a garage and 100% on the cloud. So it's a business spend management platform, software as a service, 100% on the cloud. That was like 10 years ago, right? Yes. Yeah. You guys are riding the wave of the architecture. Justin, I want to ask you, Zora, you guys mentioned DevOps. I mean, obviously, we saw the huge observability wave, which is essentially network management for the cloud, in my opinion. It's more dynamic. But this is about visibility. We heard from the last panel, you don't know what's being turned on or turned off from a service standpoint at any given time. How is all of this playing out when you start getting into the DevOps down? Well, this is the big challenge for all of us is visibility when you talk transport within a cloud. Very interestingly, we have moved from having a backbone that we bought, that we own, that would be data center connectivity. Zora is a subscription billing company. So we want to support the subscription mindset. So rather than going and buying circuits and having to wait three months to install and then coming up with some way to get things connected and resiliency and redundancy, my backbone is in the cloud. I use the cloud providers' interconnections between regions to transport data across. And so if you do that with their native solutions, you do lose visibility. There are areas in that that you don't get, which is why controlling controllers and having some type of management plane is a requirement for us to do what we're supposed to do and provide consistency while doing it. Great conversation. I loved what you said earlier, latency band with, I think, availability with your top three things. Guys, SLA, you just do ping times between clouds. You don't know what you're getting for round trip times. This becomes a huge risk management black hole, whatever you want to call blind spot. How are you guys looking at the interconnects between clouds? Because I can see that working from ground to cloud or per cloud. But when you start dealing with multi-clouds, workloads, SLAs will be all over the map. Won't they just inherently? But how do you guys view that? Yeah, I think we talked about workload. And we know that the workloads are going to be different in different clouds. But they're going to be calling each other. So it's very important to have that visibility, that you can see how data is flowing at what latency and what availability is there. And our authority needs to operate on that. So use the software dashboard. Look at the times and look at the latency. In the old days, strong swan opens swan. You try to figure it out. In the new days, you have to figure out. Justin, what's your answer to that? Because you're in the middle of it. Yeah, I mean, I think the key thing there is that we have to plan for that failure. We have to plan for that latency in our applications. It's something you start tracking in your SLI, something you start planning for. And you loosely couple these services in a much more microservices approach. So you actually can handle that kind of failure or that type of unknown latency. And unfortunately, the cloud has made us much better at handling exceptions in a much better way. You guys are all great examples of cloud native from day one. You guys had the, when did you have the tipping point moment or the epiphany of saying, hey, multi-cloud is real. I can't ignore it. I've got to factor it into all my design, design principles, and everything you're doing. Was there a moment or was it from day one? No, there were two reasons. One was the business. So in business, there was some affinity to not be in one cloud or to be in one cloud. And that drove from the business side. So as a cloud architect, our responsibility was to support that business. And other is the technology. Some things are really running better in, like if you're running .NET workload, or you're going to run machine learning or AI. So you would have that preference of one cloud or other. So guys, any thoughts on that? That was the bill that we got from AWS. I mean, that's what drives a lot of these conversations is the financial viability of what you're building on top of. So this failure domain idea, which is fairly interesting, how do I solve or guarantee against a failure domain? You have methodologies with back-end direct connects or interconnect with GCP. All of these ideas are something that you have to take into account. But that transport layer should not matter to whoever we're building this for. Our job is to deliver the frames in the packets. What that flows across, how you get there, we want to make that seamless. And so whether it's a public internet API call or it's a back-end connectivity through direct connect, it doesn't matter. It just has to meet a contract that you've signed with your application folks. Yeah, that's the availability piece. Justin, your thoughts on any comment on that? So actually, multi-clouds become something much more recent in the last six to eight months, I'd say. We always had a very much an attitude of moving to Amazon from our private cloud is hard enough. Why complicate it further? But the realities of the business and as we start seeing improvements in Google and Azure and different technology spaces, the need for multi-cloud becomes much more important. As well as our acquisition strategies have matured, we're seeing that companies that used to be on-premise that we typically acquire are now very much already on a cloud. And if they're on a cloud, I now need to plug them into our ecosystem. That's really changed our multi-cloud story in a big way. I'd love to get your thoughts on the clouds versus the clouds because you compare them. Amazon's got more features. They're rich with features. I'll see the bills are high because people are using them. But Google's got a great network. Google's network is pretty damn good. And then you got Azure. What's the difference between the clouds? Whether they fall, whether they peak in certain areas better than others, what are the characteristics? Which makes one cloud better? Do they have a unique feature that makes Azure better than Google and vice versa? What do you guys think about the different clouds? Yeah, to my experience, I think the approach is different in many places. Google has a different approach, very DevOps friendly. And you can run your workload. Your network can spend regions time. But our application ready to accept that. Amazon is evolving. I mean, I remember 10 years back, Amazon's network was a flat network. We were launching servers in 10.0.0 slash 8. And then VPC came out. Because they had the English for the live fee. Not good. So the VPC's concept came out. Multi-account came out. So they are evolving. Azure had a late start. But because they have a late start, they saw the pattern and they have some mature setup on the network. They allow the girls to stay on the guys too. I mean, I think they're all trying to say they're equal in their own ways. I think they all have very specific design philosophies that allow them to be successful in different ways. And you have to kind of keep that in mind as you architect your own solution. For example, Amazon has very much a very regional affinity. They don't like to go cross region in their architecture. Whereas Google is very much it's a global network. We're going to think about it as a global solution. I think Google also has advantage of its third to market. And so it has seen what Azure did wrong. It's seen what AWS did wrong. And it's made those improvements. And I think that's one of their big advantages. They got great scale too. Justin, thoughts on the cloud. So yeah, Amazon built from the system up and Google built from the network down. So their ideas and approaches are from a global versus a regional. I agree with you completely. That is the big number one thing. But if you look at it from the outset, interestingly, the inability or the ability for Amazon to limit layer two broadcasting and what that really means from a VPC perspective changed all the routing protocols you can use, all the things that we have built inside of a data center to provide resiliency and make things seamless to users. All of that disappeared. And so because we had to accept that at the VPC level, now we have to accept it at the WAN level. Google's done a better job of being able to overcome those things and provide those traditional network facilities to us. Just great panel. We're going to go all day here. It's awesome. So I heard we'll get to the cloud native naive question. So kind of think about what's naive and what's cloud asset next. But I got to ask you, at a conversation with a friend, he's like, the WAN is the new LAN. So if you think about what the LAN was at a data center, WAN is the new LAN, because you're talking about the cloud impact. So that means the SD WAN, the old SD WAN is kind of changing through the new LAN. How do you guys look at that? Because if you think about it, what LANs were for inside of premises was all about networking, high speed. But now when you take the WAN and make essentially a LAN, do you agree with that? And how do you view this trend? And is it good or bad? Or is it ugly? And what's your guys take on this? Yeah, I think it's a thing that you have to work with your application architect. So if you are managing networks and if you are an SRE engineer, you need to work with them to expose the unreliability that would bring in. So the application has to handle a lot of this. The difference in the latencies and the reliability has to be worked through the application there. LAN, WAN, same concept as a BS. I think we've been talking about for a long time the erosion of the edge. And so this is just a continuation of that journey we've been on for the last several years as we get more and more cloud native. When we talk about APIs, the ability to lock my data in place and not be able to access it really goes away. And so I think this is just a continuation of that thing. I think it has challenges. We start talking about WAN scale versus LAN scale. The tooling doesn't work the same. The scale of that tooling is much larger. And the need to automation is much, much higher in a WAN than it was in a LAN. That's the reason why you're seeing so much infrastructure as code. Yeah, so for me, I'll go back again to this. It's bandwidth and its latency that define those two LAN versus WAN. But the other thing that comes up more and more with cloud deployments is where is our security boundary? And where can I extend this secure, aware appliance or set of rules to protect what's inside of it? So for us, we're able to deliver VRFs or route forwarding tables for different segments wherever we're at in the world. And so they're trusted to talk to each other. But if they're going to go to someplace that's outside of their network, then they have to cross the security boundary where we enforce policy very heavily. So for me, it's not just LAN WAN. How does environment get to environment more importantly? That's a great point. And security, we haven't talked to yet, but that's going to be baked in from the beginning in this architecture. Thoughts on security, how you guys are dealing with it? Yeah, start from the base. Have app-to-app security built in. Have TLS, have encryption on the data transit, data at rest. But as you bring the application to the cloud and they're going to go multi-cloud, talking to over the internet in some places, well, have app-to-app security. I mean, our principle is security is day zero every day. And so we always build it into our design, build it into our architecture, into our applications. It's encrypted everything. It's TLS everywhere. It's make sure that that data is secured at all times. Yeah, one of the cool trends at RSA just as a side note was the data in use encryption piece, which is a homomorphic stuff. That was pretty interesting stuff. All right, guys, final question. We heard on the earlier panel was also trending at re-invent. If you take the T out of cloud native, it spells cloud naive. Okay, they got shirts now. ABHR has kind of got this trend going. What does that mean to be naive? So if your peers out there watching on the live stream and also the suppliers that are trying to supply you guys with technology and services, what's naive look like and what's native look like? When is someone naive about implementing all this stuff? So for me, because we are in 100% cloud, for us, its main thing is ready for the change. And you will find new building blocks coming in and the network design will evolve and change. So don't be naive and think that it's static. Evolve with the change. I think the big naivety that people have is that while I've been doing it this way for 20 years and been successful, it's gonna be successful in cloud. The reality is that's not the case. You have to think some of the stuff a little bit differently and you need to think about it early enough so that you can become cloud native and really enable your business on cloud. Yeah, for me, it's being open-minded, right? The R industry, the network industry as a whole has been very much I'm smarter than everybody else and we're gonna tell everybody how it's gonna be done. And we fell into a lull when it came to producing infrastructure and so embracing this idea that we can deploy a new solution or a new environment in minutes as opposed to hours or weeks or months in some cases is really important. And so, you know, it's our... So naivety being closed-minded, native being open-minded. Exactly, and it took a, for me it was, that was a transformative kind of, where I was looking to solve problems in a cloud way as opposed to looking to solve problems in this traditional old school way. All right, I know we're out of time, but I ask one more question so you guys are so good. It could be a quick answer. What's the BS language when the BS meter goes off when people talk to you about solutions? What's the kind of jargon that you hear? That's the BS meter going off. What are people talking about that? In your opinion, you hear, you go, that's total BS. What triggers you? So I have two lines out of movies that are really, I can, if I say them without actually thinking them, it's like 1.21 gigawatts, how you're out of your mind from back to the future, right? Somebody's giving y'all these business banking. And then Martin Moll and Michael Keaton and Mr. Mom when he goes 220, 221, whatever it takes. Those two right there, if those go off in my mind, where somebody's talking to me, I know they're full of baloney. So a lot of speeds and feeds, a lot of speeds and feeds, a lot of... Yeah, just data, instead of talking about what you're actually doing and solutioning for, you're talking about, well, I does this, this, this, okay, 220, 220, whatever it takes. Yeah, we got that. Justin, what's your take on BS? Any time I start seeing the cloud vendors start benchmarking against each other, your workload is your workload, you need to benchmark yourself. Don't listen to the marketing on that, that's just all. And what triggers you on the BS meter? I think if somebody explains you are not simple, they cannot explain you in simplicity, then it's all bullshit. Oh, well, that's a good one. All right, guys, thanks for the great insight, great panel, how about a round of applause for the practitioners? Thank you guys, yeah, see you in a minute. Thanks, Jeff. Thanks. DXC is a solutions integrating company and we service customers from all industry verticals and we're helping them to move to the digital world. So as a solutions integrator, we interface with many, many customers that have many different types of needs and they're on their IT journey to modernize their applications into the cloud. So we encounter many different scenarios, many different reasons for those migrations, all of them seeking to optimize their IT solutions to better enable their business. We have our CPS organization, it's cloud platform services. We support AWS, Azure, Google, Alibaba, Oracle. We'll help move those workloads to wherever it's most appropriate. No one buys the house for the plumbing. Equally, no one buys the solution for the networking. But if the plumbing doesn't work, no one likes the house and if this network doesn't work, no one likes the solution. So the network is ubiquitous, it is a key component of every solution we do. The network connectivity is the lifeblood of any architecture. Without network connectivity, nothing works. Properly planning and building a scalable, robust network that's gonna be able to adapt with the application needs, it's critical. When encountering some network design and talking about speed to deployment, AVIatrix came up in discussion and we then further pursued an interview. DXC products at Incorporate AVIatrix is part of a new offering that we are in the process of developing that really enhances our ability to provide cloud connectivity for clients. Cloud connectivity is a new line of networking services that we're getting into as our clients move into hybrid cloud networking. It is much different than our traditional-based services and AVIatrix provides a key component in that service. Before we found AVIatrix, we were using just native peering connections, but there wasn't a way to visualize all those peering connections and with multiple accounts, multiple contexts for security, with AVIatrix, we were able to visualize those different peering connections of security groups. It helped a lot. Especially in the areas of early deployment scenarios, we're quickly able to then take those deployment scenarios and turn them into scripts that we can then deploy repeatedly. Their solutions were designed to work with the cloud native capabilities first and where those cloud native capabilities fall short, they then have solution sets that augment those capabilities. I was pleasantly surprised, number one, with the AVIatrix team as a whole and their level of engagement with us and we weren't only buying the product, we were buying a team that came on board to help us implement and solution. That was really good to work together to learn both what AVIatrix had to offer as well as enhancements that we had to bring that AVIatrix was able to put into their product and meet our needs even better. AVIatrix was a joy to find because they really provided us the technology that we needed in order to provide multi-cloud connectivity that really added to the functionality that you can't get from the basic cloud-providing services. We're taking our customers on a journey to simplify and optimize their IT infrastructure. AVIatrix certainly has made my job much easier. Okay, welcome back to Altitude 2020 for the digital event for the live feed. Welcome back. I'm John Furrier with the CUBE with Steve Mulaney, CEO of AVIatrix for the next panel from Global System Integrated as the folks who are building and working with folks on their journey to multi-cloud and cloud-native networking. We've got a great panel. George Buckman with DXC, and Derek Monahan with WWT. Welcome to the stage. Hey. Thank you. Okay, you guys are the ones out there advising, building, and getting down and dirty with multi-cloud and cloud-native networking. We just heard from the customer panel. You can see the diversity of where people come into the journey of cloud. It kind of depends upon where you are, but the trends are all clear, cloud-native networking, dev ops up and down the stack. This has been the main engine. What's your guys take of the journey to multi-cloud? What are you guys seeing? Yep. Yeah, it's critical. I mean, we're seeing all of our enterprise customers enter into this. They've been through the migrations of the easy stuff. Now they're trying to optimize and get more improvements. So now the tough stuff's coming on, right? And they need their data processing near where their data is. So that's driving them to a multi-cloud environment. Yeah, we heard some of the edge stuff. I mean, you guys are, you've seen this movie before, but now it's a whole ball game. What's your take? Yeah, so I'll give you a hint. Our practice is not called the cloud practice. It's the multi-cloud practice. And so if that gives you a hint of how we approach things, it's very consultative. And so when we look at what the trends are, let's look at it a little year ago. About a year ago, we were having conversations with customers. Let's build a data center in the cloud. Let's put some VPCs, let's throw in some firewalls, let's put some DNS and other infrastructure out there, and let's hope it works. This isn't a science project. So what we're trying to, what we're starting to see is customers are starting to have more of a vision. We're helping with that consultative nature, but it's totally based on the business. And you've got to start understanding how the lines of business are using the apps, and then we evolve into that next journey, which is a foundational approach to- What are some of the problem statements that your customers are solving? When they come to you, what are the top things that are on their minds? Obviously, the ease of use of Jilly, all that stuff. But what specifically are they digging into? Yeah, so complexity. I think when you look at a multi-cloud approach, in my view, is network requirements are complex. I think they are, but I think the approach can be, let's simplify that. So one thing that we try to do, and this is how we talk to customers, is just like you simplify, and Aviatrix simplifies the automation orchestration of cloud networking, we're trying to simplify the design, the planning implementation of infrastructure across multiple workloads, across multiple platforms. And so the way we do it is we sit down, we look at not just use cases, and not just the questions in common we anticipate, we actually build out, based on the business and functional requirements, we build out a strategy and then create a set of documents, and guess what, we actually build it in the lab. And that lab that we platform we built proves out this reference architecture actually works. Absolutely, we implement similar concepts. I mean, they're proven practices, they work, right? So- Well George, you mentioned that the hard parts now upon us, are you referring to networking? What is specifically, what are you getting at, Terence, the easy parts done now? So for the enterprises themselves, migrating their more critical apps or more difficult apps into the environments, they've just, we just scratch the surface, I believe, on what enterprises are doing to move into the cloud, to optimize their environments, to take advantage of the scale and speed to deployment, and to be able to better enable their businesses. So they're just now really starting to- So do you guys see what I talked about, I mean, in terms of the Cambrian explosion? I mean, you're both monster system integrators with top fortune enterprise customers really rely on you for guidance and consulting and so forth and deploy their networks. Is that something that you've seen? I mean, does that resonate? Did you notice a year and a half ago and all of a sudden the importance of cloud for enterprise, shoot up? Yeah, I mean, we're seeing it. In our internal environment as well. We're a huge company ourselves, customers zero or our internal IT, so we're experiencing that internally in every one of our other customers. So I have another question that I don't know the answer to this and the lawyer never asks a question that you don't know the answer to, but I'm gonna ask it anyway. DXC at WWT, massive system integrators. Why AVATRIX? Yep, so great question, Steve. So I think the way we approach things, I think we have a similar vision, a similar strategy, how you approach things, how we approach things at World Wide Technology. Number one, we wanna simplify the complexity and so that's your number one priorities. Let's take the networking, let's simplify it and I think part of the other point I'm making is we see this automation piece as not just an afterthought anymore. If you look at what customers care about, visibility and automation is probably at the top three, maybe the third on the list and I think that's where we see the value and I think the partnership that we're building and what I get excited about is not just putting years in our lab and showing customers how it works, it's co-developing a solution with you, figuring out, hey, how can we make this better? Visibility's a huge thing, just insecurity alone, network, everything's around visibility. What automation do you see happening in terms of progression, order of operations, if you will, what's the low hanging fruit? What are people working on now and what are some of the aspirational goals around when you start thinking about multi-cloud and automation? So I wanted to get back to answer that question. I wanted to answer your question, what led us there and why AVHRICS? In working some large internal IT projects and looking at how we were gonna integrate those solutions, we like to build everything with recipes, where network is probably playing catch up in the DevOps world, but with a DevOps mindset looking to speed the deploy, support all those things. So when you start building your recipes, you take a little of this, a little of that and you mix it all together, well, when you look around, you say, wow, look, there's this big bag of AVHRICS. Let me plop that in, that solves a big part of my problems that I have to speed to integrate, speed to deploy and the operational views that I need to run this. So that led me there. How about reference architectures? Yeah, absolutely. So they came with a full slate of reference architectures already out there and ready to go that fit our needs. So it was very, very easy for us to integrate those into our recipes. What do you guys think about all the multi-vendor interoperability conversations that have been going on? Choice has been a big part of multi-cloud in terms of customers want choice. They'll put a workload in the cloud if it works, but this notion of choice and interoperability has become a big conversation. It is, and I think our approach, and that's the way we talk to customers, is let's speed and de-risk that decision-making process. And how do we do that? Because interoperability is key. You're not just putting, it's not just a single vendor. We're talking many, many vendors. I mean, think about the average number of cloud applications a customer uses as a business, an enterprise business today. It's above 30, it's skyrocketing. So what we do, and we look at it from an interoperability approach, is how do things interoperate? We test it out, we validate it, we build a reference architecture that says, these are the critical design elements. Now let's build one with Aviatrix and show how this works with Aviatrix. And I think the important part there, though, is the automation piece that we add to it and visibility. So I think the visibility is what I see lacking across the industry today. And the cloud native, that's been a big topic. Okay, in terms of Aviatrix, as you guys see them coming in, they're one of the ones that are emerging and the new brands emerging with multi-cloud. You still got the old guard incumbents with huge footprints. How are customers dealing with that kind of component and dealing with both of them? Yeah, I mean, we have customers that are ingrained with a particular vendor and we have partnerships with many vendors. So our objective is to provide the solution that meets that client. And they all want multi-vendor. They all want interoperability. Correct. All right, so I got to ask you guys a question while we were defining day two operations. What does that mean? I mean, you guys are looking at the big business and technical components of architecture. What does day two operations mean? What's the definition of that? Yeah, so I think from our perspective, my experience, day two operations, whether it's not just the orchestration piece and setting up and let it automate and have some change control. You're looking at this from a day two perspective. How do I support this ongoing and make it easy to make changes as we evolve? The cloud is very dynamic. The nature of how this fast is expanding, the number of features is astonishing. Trying to keep up to date with the number of just networking capabilities and services that are added. So I think day two operation starts with a fundamental understanding of building out, supporting a customer's environment and making it the automation piece easy from a distance, I think. Yeah, and taking that to the next level of being able to enable customers to have catalog items that they can pick and choose, hey, I need this network connectivity from this cloud location back to this on-prem and being able to have that automated and provisioned just simply by ordering it. For the folks watching out there, guys, take a minute to explain, as you guys are in the trenches doing a lot of good work, what are some of the engagements that you guys get into? How does that progress? What happens there? They call you up and say, hey, I need some multi-cloud or you're already in there. Take us through how someone can engage to use a global SI to come in and make this thing happen. What's the typical engagement look like? Yeah, so from our perspective, we typically have a series of workshops and a methodology that we go along the journey. Number one, we have a foundational approach and I don't mean foundation, meaning the network foundation, that's a very critical element. We got a factor in security and we got a factor in automation. So when you think about foundation, we do a workshop that starts with education. A lot of times we'll go in and we'll just educate the customer. What is VPC sharing? What is a private link in Azure? How does that impact your business? We have customers that want to share services out in an ecosystem with other customers and partners. Well, there's many ways to accomplish that. So our goal is to understand those requirements and then build that strategy with them. Thoughts, George? Yeah, I mean, I'm one of the guys that's down in the weeds making things happen. So I'm not the guy on the front line interfacing with the customers every day, but we have a similar approach. We have a consulting practice that will go out and apply their practices to see what those... And when do you parachute in? Yeah, and when I parachute in is I'm on the back end working with our offering development leads for the networking. So we understand or seeing what customers are asking for and we're on the back end developing the solutions that integrate with our own offerings as well as enable other customers to just deploy quickly to meet their connectivity needs. So the patterns are similar? Right, final question for you guys. I wanna ask you to paint a picture of what success looks like. And you know, if the name customers, you don't have to get in and reveal kind of who they are, but what does success look like in multi-cloud? As you paint a picture with folks here and watching on the live stream, it's someone says, hey, I wanna be multi-cloud. I gotta have my operations agile. I want full dev ops. I want programmability, security built in from day zero. What does success look like? Yeah, I think success looks like this. So when you're building out a network, the network is a harder thing to change than some other aspects of cloud. So what we think is even if you're thinking about that second cloud, which we have most of our customers are on two public clouds today, they might be dabbling in that, is you build that network foundation, that architecture that takes in consideration where you're going. And so once we start building that reference architecture out that shows, this is how to approach it from a multi-cloud perspective, not a single cloud. And let's not forget our branches. Let's not forget our data centers. Let's not forget how all this connects together because that's how we define multi-cloud. It's not just in the cloud, it's on-prem and it's off-prem. And so collectively, I think the key is also is that we provide them an HLD. You got to start with a high level design that can be tweaked as you go through the journey, but you got to give a solid structural foundation and that networking, which we think most customers think as not the network engineers, but as an afterthought. We want to make that the most critical element before you start the journey. George, from your seat, how did success look for you? So it starts out on these journeys, often start out people not even thinking about what is going to happen, what their network needs are when they start their migration journey to the cloud. So I want the success to me, looks like them being able to end up not worrying about what's happening in the network when they move to the cloud. Guys, great insight. Thanks for coming on and sharing the panel. I'll put a round of applause for the global system integrators. All right. Thank you. Thanks, guys. Thanks, guys. Okay, welcome back from the live feed. I'm John Furrier with theCUBE. I'm Steve Milenny, CEO of Aviatrix. My co-host, our next panel is the Aviatrix certified engineers, also known as ACEs. This is the folks that have certified their engineering, they're building these new solutions. Please welcome Toby Foss from Informatica, Stacy Linier from Teradata, and Jennifer Reed with Victor Davis to the stage. I want to know where, oh, there it is. Welcome. Hi, I was just going to ask, where's the jacket? How are you? You got to show it, maybe. Where's your jacket, Toby? Take a look at it. Okay. You get it. That's awesome. I was just going to rib you guys and say, where's your jacket? And Jen's got the jacket on. Okay, good. Love the Aviatrix ACEs, pilot gear there above the clouds. That's right. Soaring to new heights. That's right. So guys, Aviatrix ACEs, love the name. Think it's great, certified. This is all about getting things engineered. So there's a level of certification. I want to get into that. But first, take us through the day in the life of an ACE and just to point out, Stacy's a squad leader, so he's like a squadron leader. Squadron leader. Squadron leader. So he's got a bunch of ACEs underneath him, but share your perspective day in the life. Jen, if we'll start with you. Sure. So I have actually a whole team that works for me, both in the North America, both in the US and in Mexico. And so I'm eagerly working to get them certified as well so I can become a squad leader myself. But it's important because one of the critical gaps that we've found is people having the networking background because you graduate from college and you have a lot of computer science background. You can program, you've got Python. But networking and packets, they just don't get. And so just taking them through all of the processes that it's really necessary to understand when you're troubleshooting is really critical. And because you're gonna get an issue where you need to figure out where exactly is that happening on the network? Is my issue just in the VPC? Is it on the instant side as a security group or is it going on-prem? And is it something actually embedded within Amazon itself? I mean, I troubleshot. An issue for about six months going back and forth with Amazon and it was the VGW and VPN because they were auto-scaling on two sides and we ended up having to pull out the Cisco's and put in Aviatrix so I could just say, okay, it's fixed and actually help the application teams get to that and get it solved. But I'm taking a lot of junior people and getting them through that certification process so they can understand and see the network, the way I see the network. I mean, look, I've been doing this for 25 years when I got out. When I went on the Marine Corps, that's what I did and coming out, the network is still the network but people don't get the same training they got in the 90s. It's just so easy to just write some software the network takes care of itself, right? Yeah, I know, it's 60 desks. Toby, I'll come back to that. I want to come back to that problem solved with Amazon, but Toby. I think the only thing I have to add to that is that it's always the network fault. As long as I've been in networking, it's always been the network's fault and even to this day, it's still the network's fault and part of being a network guy is that you need to prove when it is and when it's not your fault and that means you need to know a little bit about 100 different things to make that. And now you've got a full stack DevOps, you've got to know a lot more times another 100. And these times are changing, yeah. Tacey, you're a squadron leader, get that right. What is a squadron leader first? Can you describe what it is? I think it's probably just leading all the network components of it but I think from my perspective, when to think about what you asked them was it's about no issues and no escalation so if my day is like that, I'm happy to be honest. That's a good outcome. That's a good day. Yeah, sure is. Is there a good day? There's a good day. Well, you just said you had a good day with Amazon. Jennifer, you mentioned the Amazon thing, this brings up a good point. You know, when you have these new waves come in, you have a lot of new things, new use cases, a lot of the finger pointing it's that guy's problem, that girl's problem. So how do you solve that and how do you get the young guns up to speed? Is there training? Is this where the certification comes in? Well, this is where the certification is really gonna come in. I know when we got together at Reinvent, one of the questions that we had with Steve and the team was what should our certification look like? You know, should we just be teaching about what Aviatrix troubleshooting brings to bear but what should that be like? And I think Toby and I were like, no, no, no, no. That's going a little too high. We need to get really low because the better someone can get at actually understanding what actually happening in the network and where to actually troubleshoot the problem, how to step back each of those processes because without that, it's just a big black box and they don't know, you know? Because everything is abstracted and Amazon and Azure and Google is abstracted and they have these virtual gateways. They have VPNs that you just don't have the logs on and so you just don't know. And so then what tools can you put in front of them of where they can look? Because there are full logs. Well, as long as they turned on the flow logs when they built it, you know? And there's like each one of those little things that, well, if they had decided to do that when they built it, it's there. But if you can come in later to really supplement that with training to actual troubleshoot and do a packet capture here as it's going through, then teaching them how to read that even. Yeah, Toby, we were talking before we came up on stage about your career, you've been networking all your time and then, you know, you're now mentoring a lot of younger people. How is that going? Because the people who come in fresh, they don't have all the old war stories. They don't. They don't. They talk about, you know, it's never fall. I walk in bare feet in the snow when I was your age. I mean, it's so easy now, right? They say, what's your take on how you train the young people? So I've noticed two things. One is that they are up to speed a lot faster in generalities of networking. They can tell you what a network is in high school level now, where I didn't learn that till midway through my career. And they're learning it faster, but they don't necessarily understand why it's that way here. You know, everybody thinks that it's always slash 24 for a subnet and they don't understand why you can break it down smaller, why it's really necessary. So the ramp up speed is much faster for these guys that are coming in, but they don't understand why and they need some of that background knowledge to see where it's coming from and why is it important. And as old guys, that's where we thrive. Jennifer, you mentioned you got in from the Marines. Tell us about when you got into networking. What was it like then and compare it now? Because it's almost like, we heard earlier, static versus dynamic. Don't be static. Back then, you just set up the network, you got a perimeter. Yeah, no, there was no such thing. So back in the day, I mean, I mean, we had Banyan Vines for email. And you know, we had Token Ring. And I had to set up Token Ring networks and figure out why that didn't work. Because how many of things were actually sharing it? But then actually just cutting fiber and running fiber cables and dropping them over shelters to plug them in and oh crap, they swung it too hard and shattered it. Now I gotta figure eight polish this thing and actually shoot light to see if it works. I mean, that was the network. Current five cables to run an ethernet. And then from that to setting up the network switches, dumb switches, like those were the most common ones you had. Then actually configuring routers and logging into a Cisco router and actually knowing how to configure that. And it was funny because I had gone all the way up and was a software product manager for a while. So I've gone all the way up the stack and then two and a half, three years ago, I came across to work with Entity Group that became Victor Davis, but we went to help one of our customers, Avis. And it was like, okay, so we need to fix the network. Okay, I haven't done this in 20 years, but all right, let's get to it. Because it really fundamentally does not change. It's still the network. I mean, I've had people tell me, well, you know, when we go to containers, we will not have to worry about the network. And I'm like, yeah, you don't, I do. Yeah, yeah, yeah. And then with this program abilities, it really interesting. So I think this brings up the certification. What are some of the new things that people should be aware of that come in with the AVHRX-A certification? What are some of the highlights? Can you guys share some of the highlights around the certifications? I think some of the importance is that it's, it doesn't need to be vendor specific for network generality or basic networking knowledge. And instead of learning how Cisco does something or how Palo Alto does something, we need to understand how and why it works as a basic model and then understand how each vendor has gone about that problem and solved it in a general. That's true in multi-cloud as well. You can't learn how cloud networking works without understanding how AWS, and Azure, and GCP are all slightly the same, but slightly different and some things work and some things don't. I think that's probably the number one take. I think having a certification across cloud is really valuable because we heard the global SIs as you help with the business issues. What does it mean to do that? Is it code? Is it networking? Is it configuration? Is it AVatrix? What is the, I mean, obviously AVatrix is the ace certification, but what is it about the multi-cloud that makes it multi-networking and multi-bender? And what is the, what is it? Easy answer is yes. Yes, it's all, it's all true. So you gotta be a generalist, get your hands in the water. You have to be. Right, and it takes experience because it's, every cloud vendor has their own certification, whether that's SysOps and advanced networking and advanced security or whatever it might be. Yeah, they can take the test, but they have no idea how to figure out what's wrong with that system. And the same thing with any certification, but it's really getting your hands in there and actually having to troubleshoot the problems and actually work the problem and calm down. It's going to be okay. I mean, because I don't know how many calls I've been on or even had Aviatrix join me on. It's like, okay, so everyone calm down. Let's figure out what's happening. It's like we've looked at that screen three times, looking at it again, it's not gonna solve that problem. But at the same time, remaining calm, but knowing that it really is, I'm getting a packet from here to go over here. It's not working. So what could be the problem? And actually stepping them through those scenarios, but that's like, you only get that by having to do it and seeing it and going through it and then you get it. I have a question. So I just see it, we started this program maybe six months ago. We're seeing a huge amount of interest. I mean, we're oversubscribed on all the training sessions. We've got people flying from around the country, even with coronavirus flying to go to Seattle to go to these events were oversubscribed. The good squadron leader would put there. Yeah, that's right. So is that something that you see in your organizations? Are you recommending that to people? Do you see, I mean, I'm just, I guess I'm surprised, I'm not surprised, but I'm really surprised by the demand, if you would, of this multi-cloud network certification because there really isn't anything like that. Is that something you guys can comment on or do you see the same things in your organization? I see it from my side because we operate in a multi-cloud environment, so it really helps and it's beneficial for us. Yeah, true. I think I would add that the networking guys have always needed to use certifications to prove that they know what they know. It's not good enough to say, yeah, I know IP addresses or I know how a network works. And a couple little checkmarks or a little letters by your name helps give you validity. So even in our team, we can say, hey, we're using these certifications to know that you know enough of the basics and enough of the understandings that you have the tools necessary. Right, okay. I guess my final question for you guys is why an A certification is relevant? And then second part is share with the live stream folks who aren't yet A certified or might want to jump in to be AVH or certified engineers, why is it important? So why is it relevant and why shouldn't someone want to be an A certified, I mean certified engineer? I think my view is a little different. I think certification comes from proving that you have the knowledge, not proving that you get a certification to get, I mean they're backwards. So when you've got the training and the understanding and the, you use that to prove and you can like grow your certification list with it versus studying for a test to get a certification and have no understanding of that. Okay, so then who is the right person that look at this and say, I'm qualified? Is it a network engineer? Is it a DevOps person? What's your view? Is it a certain? I think cloud is really the answer. As we talked like the edge is getting eroded so is the network definition getting eroded. We're getting more and more of some network, some DevOps, some security, lots and lots of security because network is so involved in so many of them that it's just the next progression. Casey, you wanna add something there? I would say I expand that to more automation engineers because we have those now so I'd probably extend that field as well. Jennifer, you wanna add something? Well I think the training classes themselves are helpful, especially the entry level ones for people who may be, quote unquote, cloud architects but have never done anything in networking for them to understand why we need those things to really work, whether or not they go through to eventually get a certification is something different but I really think fundamentally understanding how these things work, it makes them a better architect, makes them a better application developer but even more so as you deploy more of your applications into the cloud, really getting an understanding even from our people who've traditionally done on-prem networking, they can understand how that's gonna work in the cloud too. Well I know we've got just under 30 seconds left but I wanna get one more question in, just one more. For the folks watching that are maybe younger that don't have that networking training, from your experiences, each of you can answer why should they know about networking? What's the benefit, what's in it for them? Motivate them, share some insights on why they should go a little bit deeper in networking. Casey, we'll start with you and we'll go down. I would say it's probably fundamental, right? If you wanna deliver solutions, networking is the very top. I would say if you, fundamental of an operating system running on a machine, how those machines talk together is a fundamental change, is something that start from the base and work your way up. Jennifer? Well I think it's a challenge because you've come from top down, now you're gonna start looking from bottom up and you want those different systems to cross-communicate and say you've built something in your overlapping IP space, not that that doesn't happen but how can I actually make that still operate without having to re-IP and re-platform? It's just like those challenges, like those younger developers or assist engineers can really start to get their hands around and understand those complexities and bring that forward in their career. They gotta know how the pipes are working. And they gotta know what's going, it's a plumbing. That's right. And they gotta know how it works and how to code it. That's right. Awesome, thank you guys for great insights. ACE, certified engineers, also known as ACEs, give them a round of applause. Great, thank you. Thanks, Toby, that was great. Thank you. Okay, all right. That concludes my portion. Thank you, Steve, thanks for having me. John, thank you very much. That was fantastic, everybody. Round of applause for John Furrier. Yeah, so great event. Great event. I'm not gonna take long. We got lunch outside for the people here. Just a couple of things. Just call to action, right? So we saw the ACEs, you know, for those of you out on the stream here, become ACE certified, right? It's great for your career. It's great for, knowledge is fantastic. It's not just an Aviatrix thing. It's gonna teach you about cloud networking, multi-cloud networking, with a little bit of Aviatrix, exactly what the Cisco CCIE program was for IP network. That type of the thing. That's number one. Second thing is learn, right? So there's a link up there to join the community. Again, like I started this, this is a community. This is the kickoff to this community, and it's a movement. So go to community.avh6.com, starting a community on multi-cloud. So get trained, learn. I'd say the next thing is we're doing over a hundred seminars across the United States, and also starting into Europe soon. But we'll come out, and we'll actually spend a couple hours and talk about architecture, and talk about those beginning things. For those of you on the live stream in here as well, we're coming to a city near you. Go to one of those events. It's a great way to network with other people that are in the industry, as well as to start to learn and get on that multi-cloud journey. And then I'd say the last thing is, we haven't talked a lot about what Aviatrix does here, and that's intentional. We want you leaving with wanting to know more, and schedule, get with us and schedule a multi-hour architecture workshop session. So we sit out with customers, and we talk about where they're at in that journey, and more importantly, where they're going, and define that in-state architecture from networking, compute, storage, everything, and everything you've heard today, every panel kept talking about architecture, talking about operations. Those are the types of things that we solve. We help you define that canonical architecture, that system architecture, that's yours. So many of our customers, they have three by five plotted lucid charts, architecture drawings, and it's the customer name slash Aviatrix network architecture, and they put it on their whiteboard. That's what we, and that's the most valuable thing they get from us, so this becomes their 20-year network architecture drawing that they don't do anything without talking to us and look at that architecture. That's what we do in these multi-hour workshop sessions with customers, and that's super, super powerful. So if you're interested, definitely call us and let's schedule that with our team. So anyway, I just wanna thank everybody on the live stream, thank everybody here. Hopefully it was very useful, I think it was, and join the movement, and for those of you here, join us for lunch, and thank you very much.