>>from Santa Clara, California In the heart of Silicon Valley, it's the queue covering altitude 2020. Brought to you by aviatrix. >>Our next customer panel got great. Another set of cloud Network architect Justin Smith, was Aura Justin broadly with Ellie Mae and omit Otri job with Cooper. But on the stage. >>Yeah, all right. Thank you. Thank you, Thank you. Yeah, >>he's got all the cliff notes from the last session. Welcome, Rinse and repeat. Yeah, we got to go under the hood a little bit and I think they nailed the what we've been reporting and we've been having a conversation around. Networking is where the action is, cause that's the end of the day. You gotta move impact from a to B. And yet workloads exchanging data. So it's really killer. So let's get started. I mean, what are you seeing as the journey of of multi cloud as you go under the hood and say, Okay, I got to implement this, have to engineer the network, make it enabling make it programmable, making interoperable across clouds. And that's like I mean, almost sounds impossible to me. What's your take? >>Yeah, I mean it. It seems impossible. But if you're running an organization, which is running infrastructures, according 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 But what? Your architecture first, don't wait. Architecture may not be perfect, but the best architecture that's available today and be agile to idiot and make improvements over there. >>We got to Justin's over here, so I have to be careful when I pointed Question and Justin, they both have the 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 perspective. What's your take on the journey? Justin? >>Yeah, I mean, from our first do, we started out very much focused on one cloud. Ah, and as we started acquisitions, we started doing new products to market. The need for multi cloud becomes very apparent very quickly for us. And so, you know, having architecture that we can plug in, play into and be able to add and change things as it changes is super important For what we're doing in this space >>just in your journey? >>Yes, 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 tour in the network has been a real enabler of this is that there's one network and it touches whatever cloud we wanted to touch on. It touches the data centers that we needed to touch, and it touches the customers that we needed 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 dio >>before we get the architecture section, I want to ask you guys a question. 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 want to get your thoughts. What is cloud native networking and is that the engine really got the enabler for this multi cloud trend. But you guys take it, we'll start with What do you think about that? >>Yeah, So you're gonna have workloads running in different clouds, and the workloads would have affinity to one cloud or another. But how you expose that? It's a matter of how you're gonna build your networks, how we're gonna run security, how we're gonna do egress, ingress out offered. So >>networking is the big problem. How do you suppose this? What's the solution? That's the key Pain points and problem statement. >>I mean, they get the key pain point for most companies is how do you take your traditional on premise network and then blow it out to the cloud in a way that makes sense. I p conflicts. You have space. You have public eyepiece 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 it's really simple. It's latency and bandwidth and availability. These don't change whether we're talking about cloud or data center or even corporate I t. Networking. So our job when when these all of these things are simplified into like s three, for instance. And our developers want to use those, we have to be able to deliver that and for a particular group or another group that wants to use just just GC p resource is these aren't we have to support these requirements and these wants, as opposed to saying, Hey, that's not a good idea. Our job is to enable them not disable them. Do >>you think I do? You guys think Infrastructure's code, which I love that because that's the future it is. We saw that with Dev Ops, but I just start getting the networking. Is it getting down to the network portion where it's network as code storage and compute? Working really well is seeing all kubernetes and service meshes. Trend network is code reality is that there is still got work >>to do. It's absolutely there. I mean, you mentioned that develops and it's very real. I mean, in Cooper, we build our networks through terraform and on not only just data from building a p I so that we can consistently build we nuts and vpc all across in the same way >>you got to do it. >>Yeah, and even security groups and then on top and aviatrix comes in. We can peer the network's bridge bridge, all the different regions through court. >>Same with you guys about >>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 what it should be that's full. When it used to be. >>It's full dev ops, then >>yes, yeah, I mean, for us, it was similar on premise. Still somewhat very manual though we're moving more Norton Ninja and Terra Form concepts, but everything in the production environment, confirmation terraform code and now coming into the data center. So I just wanted to jump in on Justin Smith. One of the comment >>that you made because it's something that we always >>talk about a lot is that >>the center of gravity of architectures used to be an on Prem, and now it's shifted in the cloud it once you have your strategic architecture what what do you do? You push that everywhere. So what you used to see the beginning of cloud was pushing the architecture on Prem into cloud. Now I won't pick up on what you said The you others agree that the center >>of architect of gravity is here. I'm now pushing what I do in the cloud >>back into on Prem. And 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%. So you evacuating data centers next year? I mean, where are you guys at >>s. So there's there's two types of gravity that you typically are dealing with the migration. First is data gravity in your data set and where that data lives. And the second is the network platform that interrupts all that together in our case, the data gravity still mostly on Prem. But our network is now extending out to the APP tier that's gonna be in cloud, right? Eventually that data gravity will also move to cloud as we start getting more sophisticated. But, you know, in 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. >>Okay, Well, for us, it's a very different story. Started from a garage 100% in the cloud. It's a business spend management platform as a software as a service, 100% in the cloud. It was like 10 years ago, right? Yes. >>Yeah. Has a riding the wave of the architecture. Just I want to ask you is or you guys mentioned Dev ops. I mean, obviously we saw the huge observe Ability way which essentially network management for the cloud. In my opinion, it's more dynamic, but this is about visibility. We heard from last panel. You don't know what's being turned on or turned off from a services standpoint at any given time. How is all this playing out when you start getting into the Dev Ops down? >>Well, this this is the big challenge for all of us is visibility when you talk transport within a cloud. You know, we very interesting. We have moved from having a backbone that we bought that we own. That would be data center connectivity. We now I work as 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, I 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 you don't get, which is why controlling you know, controllers and having some type of management plane is a requirement for us to do what we're supposed to and provide consistency while doing it. >>Great conversation. I love what you said earlier laden C band with I think availability with your SIM pop three things guys s l A and just do ping times between clouds. It's like you don't know what you're getting for round trip times. This becomes a huge kind of risk management. Black hole, whatever you wanna call Blind Spot. How are you guys looking at the interconnect between clouds? Because, you know, I can see that working from ground to cloud on cloud. But when you start dealing multi clouds, workloads, sl A's 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 their data is flowing at war latency and what our ability is is there and over a Saturday meets to operate on. So it's >>so use the software dashboard, look at the Times and look at the latest in >>the old days strong So on open salon, you try to figure it out, and then your data, as you look at our >>Justin, what's your answer? That cause 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 a plan for that latency and our applications. That something is we're tracking ingress, Ally, something you start planning for. And you loosely couple these services in a much more micro services 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 much better way. >>You guys are all great examples of cloud native from day one you guys had When did you have the tipping point moment or the epiphany of saying a multi clouds real? I can't ignore it. I got a factor into all my design, design principles and everything you're doing. What? It was there a moment or was it from day one? >>Now there are 22 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 of a responsibility was to support the business, and the other is the technology. Some things are really running better in, like if you're running dot net workload or you're gonna run machine learning or yeah, so you have You would have that reference off one cloud over the other. So >>your thoughts on that >>that was the bill that we got from AWS. I mean, that's that's what drives a lot of these conversations is the financial viability of what you're building, on top of which is so we this failure domain idea, which is which is fairly interesting. How do I solve or guarantee against a failure domain You have methodologies with, you know, back in direct, connects or interconnect with DCP. 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, AP I call or it's a back end connectivity through direct connect. It doesn't matter. It just has to meet a contract that you signed with your application, folks, >>that's the availability piece just in your thoughts on that comment >>s actually multi clouds become something much more recent. In the last 6 to 8 months, I'd say we always kind of had a very dramatic like movie to Amazon from our private cloud is hard enough. Why complicated further but the realities of the business. And as we started seeing, you know, improvements in Google and Azure and different technology space is the need for multi cloud becomes much more important as well. As other acquisition strategies matured. We're seeing that companies that used to be on premise that we typically acquire are now very much already on the cloud. And if they're on a cloud, I need to plug them into our ecosystem. And so that's really changed our multi cloud story >>in a big way. I'd love to get your thoughts on the cloud versus the cloud because you know you compare them. Amazon's got more features. They're rich with features. I'll see the bills. Are people using them. But Google's got a great network. Google's networks pretty damn good. And then you've got azure. What's the difference between the clouds? Who? Where they involved with a peak in certain areas, better than others? What? What are the characteristics which makes one cloud better? Do they have a unique feature that makes Azure better, then Google and vice versa. What you guys think about the different clouds? >>Yeah, so my experience, I think there is a deep approach is different in many places. Google has a different approach, very developer friendly. And you can run your workload with the your network and spend regions. I mean, but our application ready to accept Amazon is evolving. I mean, I remember 10 years back Amazon's network was a flat network. We will be launching certain words and 10.0 dot zero slash right on, and the repeat came out >>with Life is not good. >>So so the VPC concept came on multi core came out, so they are evolving as you already let's start. But because they have lived start, they saw the patron and they have some mature set up on the ground, >>and 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 a 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 gonna think about a global solution. I think Google also has evangelists third to market, and so has seen what Azure did wrong. It seemed, with AWS did wrong and it's made those improvements. And I think that's one of their big >>advantage. Great scale to 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 original. I agree with you completely that 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 to 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, provide resiliency and make things seamless to users. All of that disappeared on DSO because we had to accept that at the VPC level. Now we have to accept it. At the one level, Google's done a better job of being able to overcome those things and provide those traditional network facilities to us. >>Just scrape and go all day. Here is awesome So I heard. But we will get to the cloud native Naive question. So I kind of think about what's not even what clients that next. But I got to ask. You had a conversation with a friend. He's like, When is the new land? So if you think about what the land was in a data center, when is the new language you're talking about? The cloud impact. So that means SD win. The old SD Wan is kind of changing the new land. How do you guys look at that? Because even think about it. What lands were for inside of premises was all about networking speed. But now, when you take the win and make essentially land, do you agree with that. And how do you view this trend? Is it good or bad or ugly? What's what's your guys take on this? >>Yeah, I think it's Ah, it's a thing that you have to work with your application architect. So if you're managing networks and if you're a sorry engineer, you need to work with them toe expose the unreliability that would bring in. So the application has to handle a lot off this the difference in the latency, ease and and the reliability it has to be worked with application there >>land way and same concept as a B S >>E. I think we've been talking about for a long time the erosion of the edge and so is 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 and we talk about a p, I is 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 continuation that thing. I think it has challenges. We are talking about land scale versus land scale. The tooling doesn't work the same. The scale of that tooling is much larger on the need for automation is much, much higher in a way that it wasn't a land. That's where you're seeing so much. Infrastructure is code. >>Yeah, so for me, I'll go back again to this. It's bandwidth, and it's latency, right that that define those two land versus went. But the other thing that's comes up more and more with cloud deployments is where's our security boundary? And where can I extend this secure, aware appliance or set of rules Teoh to protect what's inside of it. So for us, we're able to deliver VM ref. So our route forwarding tables for different segments wherever we're out in the world and so they're trusted to talk to each other. But if they're going to go to some place that's outside of their network, then they have to cross a security boundary, and we'll reinforce policy very heavily. So for me there is. It's not just land when it's it's how does environment get to environment more importantly, >>as a great point and security we haven't talked about yet, but that's got to be baked in from the beginning of this architecture. Thoughts on security, how you guys are dealing with it. >>Yes, start from the base. Have app, Web security built in? Have TLS have encryption on the data in transit or at rest? But as you bring the application to the cloud and they're going to go multi cloud talking toe or the Internet in some places, well, have app, Web security >>I mean our principles. Day security is a day zero every day, and so we always build it into our design, build into our architecture into our applications. It's encrypt everything. It's TLS everywhere. It's make sure that that data is security at all times. >>Yeah, one of the cool trends that are, say, just as a side note was the data in use encryption piece, which is a home or fix stuff. Interesting. Alright, guys, final question. You know, we heard on the earlier panel was also trending at reinvent. We take the tea out of cloud native. It spells cloud naive. They got shirts now aviatrix kind of got this trend going. What does that mean to be naive? So if you're to your peers out there watching 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 it's someone naive about implementing all this stuff. >>So for me, it's because we are 100% cloud for us. Its main thing is ready for the change, and you you will find new building blocks coming in and the network design will evolve and change. So don't be naive and things that are static you all with the change. >>I think the big naivety that people have is that, well, I've been doing it this way for 20 years and been successful. It's going to be successful in cloud. The reality is, that's not the case. You have to think some of the stuff differently, and you need to think about it early enough so that you can become cloud native and really enable your business on cloud. >>Yet for me, it's it's being open minded, right? The our 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 on the way we fell into a law 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 >>being closed minded native, being open minded. >>Exactly. And it took for me. It was that was a transformative kind of, uh, 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 got one more question for you guys. So good. It could be a quick answer. Um, what's the B s language? When you bs? Meter goes up when people talk about solutions, what's the kind of jargon that you here that's the BS meter going off? What are people talking about that in your opinion, You. Here you go. That's total bs. But what triggers? >>So I have two lines out of movies that are really like it. I say them without actually thinking them. It's like 1.21 gigawatts of your of your mind. Back to the future, right? Somebody's going to the bank and then and then Martin Ball and and Michael Keaton and Mr Mom when it goes to 22. 21 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. >>A lot of speeds and feeds a lot of speeds and feeds a >>lot of data instead of talking about what you're actually doing in solution ing for You're talking about What does this? This This is okay, 2020 A. >>Just take any time I start seeing the cloud vendors start benchmarking against each other. Your workload is your workload. You need a benchmark yourself. Don't Don't listen to the marketing on that. That's that's >>what triggered you in the BSP. >>I think if somebody explains you're not simple, they cannot explain you in simplicity. Then then it's all >>that's a good one. All right, guys, Thanks for the great insight. Great panel around >>Applause, right? >>Yeah. Yeah,