 From Santa Clara, California, in the heart of Silicon Valley, it's theCUBE. Covering Altitude 2020. Brought to you by Aviatrix. Our next customer panel got great, another set of cloud network architects, Justin Smith, Uzora, Justin Broadley with L.E. May, and Amit Otrija with Koopa. Welcome to the stage. All right, thank you. Thank you. Thank you. Thank you, Amit. Justin, how are you? Okay, did he say it right? Yeah. Okay, you've got all the cliff-nosed 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've 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, look, 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, 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've 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 having an 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 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 want to 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 want to 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 take on? We'll start with Amit, what do you think about that? Yeah, so you are going to 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 going to build your networks, how you are going to run security, how you are going to do egress, ingress out of it. So that's- You said networking is the big problem that's solved. 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 that 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 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 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 is 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 is code? Because storage and compute working really well is seeing all Kubernetes and service matches trend. Network is 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? Yeah, 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 called CloudFormation Terraform code and now coming into the data center, same. I just wanted to jump in on Justin Smith, one of the comments 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 Kopa, 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 run 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 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. You know, very interestingly, we have moved from having a backbone that we bought, that we own, that would be data center connectivity. We now, I work for Zora 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, 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, you know, 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 bandwidth, I think availability with your top three things. Guys, SLA, I mean, you 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 want to call blind spot. How are you guys looking at the interconnects between clouds? Because, you know, I can see that working from, you know, ground to cloud per cloud, but when you start dealing with multiclouds, workloads. I mean, SLA'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 data is flowing at what, latency and what availability is there and our authority needs to operate on that. So it's the key. So use the software dashboard, look at the times and look at the latency. In the old days, strong so on, open so on, 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 and 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's real, I can't ignore it. I 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 gonna run machine learning or AI. So you would have that preference of one cloud or other. 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 we, this failure domain idea, which is fairly interesting, how do I solve or guarantee against a failure domain? You have methodologies with backend 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 backend 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 could say. We always kind of had a very much an attitude of like 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 and 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. And so 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 say 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 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 span regions, I mean, 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 would be launching servers in 10.0.0 slash eight, right? And then VPC came out. Because they had the English for the live feed. Not good. So the VPC's concept came out, multi-account came out. So they are evolving. Azure had a lead start, but because they have a lead start, they saw the pattern and they have some mature set up on the network. They allow the same space, 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 a very much, 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 advantage. They've 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. It's just a great panel. It can 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 SD WAN, the old SD WAN is kind of changing to 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're managing networks and if you're 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. LAN WAN, same concept as a BS. Can you get something to say? I mean, 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 a 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 why we're seeing so much infrastructure as code. Yeah, so for me, I'll go back again to this. It's bandwidth and it's latency, right? 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 gonna go to someplace that's outside of their network, then they have to cross the security boundary and 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 gotta 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 gonna go multi-cloud talking to over the internet in some places, well, have app-to-app security. I mean, that's that simple. 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 to 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 is pretty interesting stuff. All right, guys, final question. You know, we heard on the earlier panel was also trending at re-invent. We take the T out of cloud native, it spells cloud naive. Okay, they got shirts now, A V H, it's 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 well, 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? Our industry, the network industry as a whole has been very much, I am 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. So now you're 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 got 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 and 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, 221, whatever it takes. Yeah, yeah, yeah. I thought we got that. Justin, what should I take? Anytime 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, we'll shut it. 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?