 From Santa Clara, California, in the heart of Silicon Valley, it's The Cube! Covering Altitude 2020, brought to you by Aviatrix. We will soon be taking off on our way to Altitude. Please keep your seatbelts fastened 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 Aviatrix, the leader of Multicloud 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 going to do. Sorry for the aviation analogy, but you know, Sherry Way, Aviatrix 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 multicloud networking movement and community that we're inviting all of you to become part of. And why we're doing that is we want to 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, right? So instead, what are we doing? We're going to have expert panels. We've got Simone Richard of Gardner here. We've got 10 different network architects, cloud architects, real practitioners. They're going to share their best practices and their real world experiences on their journey to the multicloud. So before we start, everybody know what today is. In the US, it's Super Tuesday. I'm not going to 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 going to go to the cloud. And so what that was was the Cambrian explosion for cloud for the enterprise. So Frank Cabri, you know what the 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 going to 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 going to 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 going to 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 going to 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 their 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 going to do today is much of things, but we're going to validate this journey with customers. Do they see the same thing? We're going to 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 going to 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. Way more important than compute, way more important than storage. Network is the foundational element of your infrastructure. Then we're going to talk about day two operations. What does that mean? Well, day one is one day of your life. That's who 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 Aviatrix. And then the last thing we're going to talk, and it's the last panel we have, I always say you can't forget about the humans. 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. There's just not enough of them going around. So at Aviatrix, we said as leaders do, we're going to help address that issue and try to create more people. We created a program, and we call the ACE program, again, aviation theme. It stands for Aviatrix 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 going to teach network architects about multi-cloud networking and architecture. And yeah, you'll get a little bit of Aviatrix training in there, but this is the missing element for people's careers and also within their organization. So we're going to go talk about that. So great event, great show. We're going to try to keep it moving. I next want to 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 Farrier. OK, awesome. Great speech there, awesome. I totally agree with everything you said about 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 Aviatrix where we live streaming to millions of people, as you said, maybe not a million. I 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 going to come on and talk about the industry. We have a global system integrators who talk about how they're advising and building these networks and cloud-native networking. And then finally, the ACES, the Aviatrix certified engineer who's going to 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. 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 I began 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 in the marketplace with hybrid cloud and now moving quickly to multi-cloud is really what I was talking about. Cloud-native has been discussed but the networking piece is super important. How do you see that evolving? Well, the way we see enterprise adoption 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 application people or sometimes a DevOps team. And it's, it just goes as, 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 our first approach, you see what I call the lift and shift way. We see like 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 that they are in 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 multi-cloud 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. Well, the first, even before multi-cloud, 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. Then 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'm not really like concentrate used 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 want to manage the cloud from an API point of view. I don't necessarily want to bring my incumbent data center products, but I have to do that in a more API-driven cloud-native way. 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. 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. See, way in here. What's your thoughts? I thought we said this wasn't going to be a sales pitch for Aviatrix. 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, OK, but I'm now going to move to Azure and I'm going to move to Azure. Do you see a similar thing? Well, yes. They are moving, but there's not a lot of applications that choose 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. OK. Yeah, I mean, one of the mistakes that people think is they think multi-cloud. No one is ever going to go multi-cloud for arbitrage. They're not going to go and say, well, today I might go into Azure because I get a better rate of my instance. That's never going to happen. Do you agree with that? That's never going to happen. What I've seen with Enterprise is I'm going to 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 going to stick there, and they're not going to move. Well, let me ask you guys. But the infrastructure has to be able to support, from a network container, 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, DirectConnect, ExpressCloud. That's the simple part. What's difficult, and even the provisioning part is easy. You can use Terraform and create VPCs and VNAPs across your free cloud provider. What's difficult is the day-to-day operations. So we'll define day-to-day operations. What does that actually mean? It's just the day-to-day operations. After 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 want to 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 to 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. 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, OK, 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, OK, 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 Android point of view as a way to control playing across the three clouds and be able to use the APIs of the cloud to build networks, but also to troubleshoot them and do data operation. So you need a view across a tree cloud. That takes care of routing connectivity. That's seen. That's the AVA tree plug-up you were right there. So how do you see, so again, your Gartner, you see the industry, you bet on network architect. How do you see this playing out? What are the legacy incumbent client server on-prem networking people going to do versus people like AVA Tricks? Well, how do you see that playing out? Well, obviously, all the incumbent, like, Arista, Cisco, Juniper, NSX, they want to basically do the lift and chip part. They want to bring, and VMware want to bring NSX in the cloud. They call that NSX everywhere. And Cisco wants to bring NSX in the cloud. They call that NSX anywhere. So everyone, and then there's cloud vision from Arista and Contrail is in the cloud. So they just want to bring the management plane in the cloud, but 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 really cloud-native. Cloud-native, you almost have to build it from scratch. We like to call that cloud naive. Cloud naive. So close. One letter, right? So that was a big conversation 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 kind of 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. I have a new like, you know, a network company and I started a few years ago. There's only really two. Aviatrix 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 want to create an overlay network across the cloud and start doing policies and abstracting all the clouds within one platform. So I got to ask you, I interviewed an executive at VMware, Sanjay Poonan. He said to me at RSA last week, oh, there will 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 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. If you're small enough, you can just keep. If you're in AWS, you can use the AWS construct. They have to insert themselves. I mean, they're running behind from that point of view. Yeah, they're all certainly in comments. I love the term Andy Jesses at Amazon Web Services. These are 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, OK, I'm going to 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 got a lot of experience going back to networking, going back to, I call the OSI days, for us old folks to know what that means. But you guys know what this means. I want to 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 is changing and the cloud guys have their own networking? What are some of the pain points that's going on, premises of 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? As I said earlier, once you could easily provision in the cloud, you can easily connect to the cloud is when you start trouble shooting application in the cloud and try to scale. So 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, design to the 80-20 role, which means they'll design 80% of the basic functionality. And they'll leave 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. 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. They're the ones who need that extra 20%. So that's what I see is there's always going to 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's that kind of combination that Yin and Yang did that people like us are providing. So I want to ask you. We're going to ask some of the cloud architect customer panels. So it's the same question. This pioneer is doing some work here, and there's also the laggards who come in behind the early adopters. What's going to 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 2 in the morning to troubleshoot 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. And you can say, OK, 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 a direct connect and express route with Azure. That looks simple. As the operations, that's when they'll realize, OK, now I need to understand how cloud networking works. I also need a tool that gives me visibility and control. But on top of 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? Because 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 and nothing against F5. I'm going to 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 OK, I have a requirement and I'm not met. I'm going to use legacy stuff. And then you have to start thinking, OK, what about a visibility control about the tree 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 thinking multi-cloud. Great insight. Someone, thank you for coming on, someone in charge. With Gardner, thanks for sharing. Thank you.