 Actually, OK, here we go. Great. All right, thanks so much for sticking around and joining us for our panel this afternoon, the Future of Cloud Networking and Policy Automation. So I'd like to thank you for joining us and I'd like to begin by introducing our panel. I'll start out. My name is Matias Makowinski. I'm a research director for IHS Market. We are an intelligence and information services company. We cover a wide variety of different sectors and industries anywhere from materials to energy, transportation, and technology. Myself, I sit in the technology division and I cover things like enterprise networking and communications, as well as support our cloud and data center research, of which I will present some of our findings here in just a few moments. So why don't you go ahead and introduce yourselves? Hi, I'm Doug Larno. I'm a network architect at Riot Games. I've been working there for about four years. Just help make the data centers consistent across the globe and enable our developers to make awesome things. I'm Joel Beathers. I work for Cox Communications, a cable provider here in the United States. I manage the network design team that is deploying our NFE high infrastructure for virtualized network functions. Hi, everyone, Rahul Ravlor, the co-founder and CEO for AppOrbit. AppOrbit is a two-year-old startup in the Bay Area. What we do is we provide an application data platform for customers to build, release, manage applications on the hybrid cloud very easily. And we do that one of the aspects how we do that is by providing a policy-based infrastructure. I'm D.P. Iadevra. I'm director of product management at Juniper and I'm part of the Contrail Business Unit. Contrail Business Unit primarily develops the open-contrail product, which is an overlay-based SDN solution for a multi-cloud environment. Excellent. Great. Thanks so much. And what I'd like to do next is just present a few slides of some of the research that we've done to set the context, set the stage for our discussion today. And one of the things we hear a lot, of course, is things are moving to the cloud. And some of you might already know that, have some idea about it. But we like to look at how much, how real is this movement, how fast is it progressing? And so one of the things that we do is talk to a lot of enterprise users. Once a year, we do a series of surveys and questions. And one way to look at this is to see what are companies actually spending on cloud services. And what you can see here is the budget has been consistently moving towards cloud services over the past few years. It exceeded 10% in 2015. And by the end of 2017, it's expected to reach close to 20% of the budget. So that's a nice portion. Of course, the flip side to that is 80% is still spent on in-house infrastructure. And one of the things that we're seeing is adoption moving beyond the early adopters to mainstream buyers, as well as companies making their offerings consumable as a service. Another way you can look at this market is to look at the revenues that the cloud services providers obtain every year. And as you can see here, infrastructure as a service, cloud as a service, platform as a service, and software as a service. If you combine these four pieces together, that's well over $100 billion in annual revenue and expected to be well over $300 billion by 2021. Double digit growth every year. You can see that the market so far has been very concentrated with infrastructure as a service. So compute, storage on demand, as well as software as a service. And we think these will continue to be mainstays in this market. But a lot of the growth is really coming from cloud as a service, which is an orchestrated platform where you can just load your applications in, as well as platform as a service, which is geared towards application developers. So those are the two high growth markets and is our expectation over the coming years. Another interesting thing that we find is that enterprises use multiple types of cloud service providers. The average here in this particular survey was six, and they expect that to grow to about eight by 2018. Multiple reasons behind that. A lot of services providers are very focused. They may only offer IaaS or SaaS. That's starting to change a little bit as they're branching out into some of the other high growth areas. There's a lot of SaaS offerings out there that address some very specific needs. Say if you're a health care provider, there's probably a SaaS platform out there that takes care of some of the specific requirements that you have. And then this last piece is this need for local operations as well, depending on regulatory or data security, data privacy types of requirements. So you may need to have a local provider in region. So that gives rise to a number of different cloud architectures on-premises, on the left side, and then off-premises, the services-based market on the right. One thing that we see happening there is public cloud has been at the forefront. Now we see a lot of interest in off-premises private cloud sorry, in private cloud services so that your infrastructure is dedicated to you and not shared with other customers. And then we see various types of hybrid models evolving here. And then this last piece I want to touch on is the networking equipment market opening up over the past few years. One way to look at that is look at software-defined networking capabilities where vendors are offering APIs into their equipment and allow control by third-party applications or by controllers. So if you go back a few years, a lot of this was really driven by the big cloud services providers rolling out bare-metal equipment, putting their own operating systems on this. And now we've seen a lot of the traditional vendors also following suit, making their equipment more open, programmable, and letting it be controlled by, again, a controller or third-party application. So that's my part of the presentation here. And what I'd like to do next is we have this structure into three different topics. First, I'd like to talk to a panel about the cloud, what it means for their business, how they're using it. After that, we'll take a look at policy automation, which is another big segment here of our discussion today. And then finally, look at intent-driven automation. So let's begin with our first topic here, the cloud. Maybe each one of you can weigh in and let us know, how are you using the cloud in your business? And yeah, tell us more, who wants to start? I guess I'll go first. So for us, we have no aspirations of trying to take on Google or Amazon or those things that wouldn't make sense for us. What we do want to do is get more out of our customers. So how can we provide a better experience at the home? How can we provide more services for our business customers who want all these things, but don't really like when we come in with 45RU worth of equipment to provide services and expect them to pay for the power for all this and whatnot. So there's that aspect of it. And then internally, how do we provide our own customers and systems to meet the everyday business needs in a much more succinct manner? So for us at Riot Games, interestingly enough, never really developed a virtual machine infrastructure. Part of it was that our game servers, if they run more than 50%, or if there's contention on the CPU, it actually affects the tick rate of the server, which players can feel, and they interpret it as lag. So internally, we never needed to develop that skill set, but application teams were coming to us and saying, like, we need infrastructure now. So we're like, well, we don't have anything to do other than we just have to give you bare metal. And they say, well, what about Amazon? So go for it. So in the early days, it was just about them unblocking themselves and being able to develop rapidly. And then by the time they got done with the product, they'd bring it in-house and we'd ship it out in our data centers. But as time goes on, as you all well know, if people develop in Amazon, they want to stay in Amazon because moving their infrastructure is work. So what we're trying to do now is identify the patterns of our development teams and say, okay, this development team is doing it this way. We see other teams doing it in a similar way. So let's bring those patterns to a central team and then try and leverage that knowledge and make a golden path and say, okay, now this works, use it, and by the way, it'll work in any data center across the globe. So we're really leveraging the expertise of our development teams to help give back to other development teams. So in a roundabout way, it's really all about what works best for the developers. In our case, I work for Juniper and I said, we work on OpenConTrail, so we are enabling all these user use cases and experiences. Having said that, we also eat our own dog food, what it means by that is a lot of hard development happens on cloud, basically. Juniper switches around Junos, a lot of the CICD environment for that runs on our IT clouds, some of which are open stack enabled on-prem and there are developers who are also, for example, in our own OpenConTrail development team, they leverage AWS and Google Cloud, et cetera, to bring up environments where they can experiment with and so on. So we are on the vendor side where we provide solutions at the same time, we are also experiencing a lot of those use cases like both Doug and Joe mentioned. So I spent many years at VMware before this and so one of the things we saw was around virtualization, it was all around the richness of the virtual machine and the different kind of capabilities that the platform provided earlier. And so the shift that we've seen in the next, I would say the past four years or so, is it's not really about what the virtual machine actually gives you, but it's really the access. So it kind of resonates with what Doug was saying earlier. It's really about the application patterns and how quickly can I get it and as long as I get those different abilities being honored by the underlying infrastructure doesn't really matter from that standpoint. So this is where one of the things are kind of what we are taking to our customers and what we're hearing from them is they really want to be able to really get infrastructure based on these different capabilities, right? And as quickly, so availability, performance, security, those are the different abilities that you want to expose back up and then have the ability to go and actually get that in a self-service fashion as quickly as possible, get visibility to the costs and be able to govern that from that standpoint. So cloud is really, it comes down to this ability to really consume this infrastructure which is this infinite capacity based on the requirements that the application needs. Yeah, okay, perfect, thank you. So what I'd like to do next is actually shift to our second topic, which is one of the key pieces of our panel today and we really want to take a closer look at policy automation. What I'd like to do is get, first of all, I'd like to get you to take what does policy automation mean to you and how does it relate to your operations of cloud networks and how does it address some of the, how could it potentially address some of the challenges? So who would like to start? So policy automation for us one of those things that has just been a huge pain point for deploying across our infrastructure. We have many data centers across the globe. Some are running, Juniper Firewalls, we got Cisco, we got IP tables. In one data center, we have all our rules and we have five, like it's just kind of a mess, but it's difficult to justify going and like moving all those things around when it does work and we can just kind of throw bodies at it to solve that problem, but it doesn't scale long term. So what we ended up developing is actually agnostic language that is really about app A talking to app B and we put that into GitHub and our developers can go in, make pull requests against each other's repos and use that as a mechanism to request access from one app to the other. We then run a process that grabs all of the JSON with all the app to app policies and then compiles it into API calls which actually talk to Contrail. Then Contrail just does its thing and then spits out into the V routers and then all the policies live across the entire infrastructure and since we can put Contrail on top of any infrastructure, now we have a unified policy framework that works in our local data centers, it works in cloud and pretty much anything that we are gonna come across. So it's all about just getting developers to be able to self-service but also not have to know IP addresses or any of the down and dirty details of infrastructure. So we estimated we've saved like three years worth of man hours just alone just after implementing the system and things are way more secure, way more consistent and also because it's application, I'm sorry, infrastructure agnostic, like it's just app to app, like not that we would ever throw out Contrail but like if we did, then we can just write a new compiler for something else. So it also protects us in a way from vendor lock-in. Mm-hmm. So for us being a service provider, we probably have more firewalls than you'd expect. I think we have in the neighborhood of maybe 140 firewalls, pairs? Pairs, I'm crazy. So sometimes, and sometimes it's, I'll have my firewall talk to your firewall type of thing. So we have applications that have to be double-naded and also have to transit yet another firewall. So you can imagine this is painful for anybody. So what we started to, what we've really noticed is it starts, it's a, I'll piggyback on what Doug was talking about. It starts about an, it's about an architecture. Can I get to a place where my policy framework is modular and portable? And then can I layer on a security analyst that will say, okay, you have A to Z, you transit three firewalls and maybe a load balancer, will the requested connectivity work? And if the answer is yes, have at it. If the answer is nope, it stops at the third firewall, what do you want me to do? Do you want me to fix it? Or do I have to kick that to our security team and say, hey, is this even appropriate? And they can answer in a timely manner. Ultimately, a lot of this is about take it intake and managing a tracking of changes and things of that nature. Layer on top of that, we are moving to a regionalized firewall model where all hosts live in their take, excuse me, connectivity domains and they can have ubiquitous east-west within their domains. How do I stop that? Well, this is great. You can do that in all this connectivity now that they don't have to jump through all kinds of firewalls, but how do I keep them from attacking each other? Well, so this is where we have SDN control coming to play sick. We are leveraging it to find grain, say, well, this host can talk to these seven items on these ports and no more. So a couple of things. So policy at the most fundamental level is the rule, right, that you want to enforce. And you want to do this, those couple of reasons will go into why this has become a bigger issue than not. And it is like cloud or big data, right? It's become one of those tones where you have policy at different layers, actually. So you have policy for data, you have policy for networking and security, you have policy for being able to even intend availability, the placement of the application. But the one thing that actually is really apparent that comes up is when you actually, you want to define your intent and you want to be able to go actually then configure that intent, right? So you define what your application needs to be able to be able to talk to, then you configure that, and then you want to be able to manage that, right? So you want to be able to enforce against that policy. So the approach that we've taken is that when you actually take a look at this policy from a networking standpoint, a security standpoint, specifically is when you deploy an app, this is where it actually gets really complicated, right? Because, I mean, you've heard some a couple of really great examples around firewall rules of being able to like set up, even for example, load balancing, like if my application is scaling, how do I actually, you know, until what? And there are now, you set up business policies to say, what level do I scale that up, right, at that point? So we, what we've done as we, from a networking and security standpoint is very simply define, at an application level, be able to say, what are the different components that can talk to each other? What are the different ports that are exposed? What are the protocols that are exposed as well? The direction of traffic? And then that actually changes even in the life cycle of the application because you want maybe a more restricted policy in your production environments, but when it goes into maybe a development or a staging environment, a more permissive policy which doesn't necessarily cost as much is actually acceptable at that point in time, right? So this is a problem in your fourth, right? All your points are done. Just to wake up people now. So on a serious note, right? I mean, typically when we talk to our customers in the conversations, there are two to three fundamental challenges they have that they bring to us, right? One, for example, in the case of app developers or application companies, right? You have the developer workflow and then you have the administrative workflow where the CSOs and the network admins want to apply policies and make sure you're meeting your regulatory requirements and compliances, et cetera, right? And the first problem statement is how do I keep my, how do I automate policies in a way that I keep the developer workflow independent of the policies I want to apply so that I don't have to every time go get the app config to be changed, et cetera, right? That's one. The second thing is as we all discussed already, I mean, people have a hybrid cloud environment or a multi-cloud environment. So every time you want to apply a policy on a particular environment, you should be able to take a single definition and be able to apply it, right? You don't want to have a policy for, let's say, a VM-based infrastructure, have a policy for AWS and so on. You should take the same policy as Doug mentioned, like an app kind of an abstraction and be able to, we call it compile it locally to what is specific to that infrastructure, right? So that's one. And then the last thing is, again, I think both Joe and Doug mentioned, you have multi-vendor environments, right? And so are you going to use five different manageability pains to manage these or do you want to use one, right? So these are typical problems that we have heard from our customers. And through Contrail, through various features, we try to address these so that you have centralized policy definition and compilation happens locally so that it's more infrastructure specific. We use a lot of tags and labels so that things stay abstracted, right? So these are some of the key things we are doing and to address the four problem statements I mentioned. Nice, thank you. So I'd like to remind our audience or just let our audience know that we are open to questions. We have two microphones set up here. If you have a question for our panel, feel free to step up and ask your questions and we'll get them answered, hopefully. So with that invitation out there, I have some other questions for you. So one of my questions was going to be have you implemented policy automation? I think that is, you know, it's clear that many of you are already down that path. So perhaps you can, you know, talk about some of your experiences and maybe what were some of the challenges, some of the pitfalls? What's some of the practical advice that you can give to our audience here based on what you've learned? Sure, from our perspective, right? One, so when we started off at OpenContrail as an SDN solution, it was meant to be more cloud-native, which means we started with virtual endpoints, right? So we did have, we understood the policy, you know, it's a critical part and so we implemented and at that time, this is four or more than four years back, right? So we, for us, the abstraction was virtual network. I mean, we still abstracted it to an entity and that was virtual network. And through the years, through a lot of interaction with Sass, Freud, Stelcos, et cetera, what we learned is now we have to further abstract it to the app level and be able to be, so that, like I said earlier, right, people don't have to worry about what network infrastructure is underneath to define my policy and IP addresses and all that. So abstraction is very critical and scale is very critical. How you define the policy and where does it get interpreted kind of has a direct impact because these days it's more about zero trust and so a lot of cloud environments are more about white listing, which means explicitly you're allowing communication and so the scale is going to be pretty huge. So how you define and are able to compile and apply these policies is very relevant to kind of how our policy framework has been evolving and yeah, hopefully we're meeting the needs of our customers with that. Just to add on to what DP said earlier as well is there's a couple of things. One is that you need to stratify this. So essentially there's different layers, as I mentioned, where these policies need to be applied and so, for example, you could say, I want to set up my parameter policies for my production environment but then as the application is deployed within it, it actually gets its own policies that are defined with it as well at that point. So now then you have two different policies that are being applied by two different users as well from that standpoint. The second part is the big change that has really happened, I would say is really the pace at which applications are being released has, that's what has made it a lot more difficult now, right? So earlier you could actually set it up in a way that was pre-configured an environment and then you're deploying an application within it but now let's say this application is being made up of these different components and you introduce a new one, now you need to actually go in and update your policies right at that point in time. So how do you actually enable that from a self-service fashion so your development teams can actually go define that and that actually makes its way across the application lifecycle to the ops teams as well that are actually going to go and enforce it then they know what the intent was and they can actually measure against that intent right from that standpoint. John. Yeah, I just had a question for you guys as far as if you're going to do an automated setting up your connections between networks have you thought about auditing the connections that have been set up to make sure everything's correct because my company kind of have the same thing and I'm gonna be in charge of doing the auditing and I just wanna know if you guys have any ideas if you do have anything in place that you're doing that right now. So I'll go first on that. We have a tool that we've been leveraging in the lab extensively over the last eight to 12 months and we're starting to deploy it in production. It's current mode of operating, you can do several things but it's currently what we're doing is leveraging it to do exactly what you're asking. It goes out and says, is this policy ever used? If the answer is no, then we schedule it to delete it. If it's used maybe four or five sparingly then we take a look at it and say, well, why is this used so sporadically? Can we just migrate this to is our security posture too granular? Can we just kind of lump it in with another thing that kind of looks the same, walks, talks and acts the same? So we put everything in code as like that app-to-app language, right? But in some parts there's still IP addresses, largely because we have legacy environment that we need to talk to, so there are just times when you need to talk to an IP address. Since everything is kind of joined and collected together in one giant GitHub repo, it's all JSON and the security team can actually pull that whole repo and then just do anything they want basically on those policies. So that's something they're looking into is like how often do they do it? Because they don't want to be blocking, they want developers to be able to do what is best for them and then kind of every once in a while just be like, so you didn't really put zero, whack, zero in there, did you? Like that's kind of a little too broad. And one other thing that's nice about GitHub actually is really tough to find in traditional firewalls and security appliances is GitHub has this great feature called Blame, which is like the perfect name, right? Because you go into GitHub and you see exactly who committed that line and then you can follow up with a person and say, okay, what was your intention behind this rule? Because if it just gets to IP addresses, like you have no idea what they want and maybe the flow works, but maybe that's not even what they're supposed to trying to do and we're getting connections in from other parts of the world that are like RDPing into our systems, like it's part of it, but it's not like should this be here and can someone answer for the policy? And I think a lot of security is just being able to figure out like who ultimately owns this policy, who's ultimately responsible, who has the final say and what was their intention? Because all too often security policies just, they always seem to grow and they never ever shrink unless the rule is never used. So like you just kind of, over time you just get more and more cropped in the environment. So I'd be able to every once in a while kind of run a compaction strategy on it with the sense of intelligence that ties back to a human is really valuable. Excellent, thanks for the question. So any others, feel free to step up and we talked about, okay, here's one, perfect. Thanks for the talk. I have two points I want to know what's your idea about it. One is, so you mentioned application to application. So first thing is application. What we can think of currently still based on IP addresses but what are the other identities or how to manage those differences, how to model that. The second point is since we have this hybrid kind of deployment, you have a legacy system, you have an SDN, you have a public cloud and you have maybe a firewall. So even if you have application to application modeling then how to manage those hybrid system, how to convert it. Yeah, so the first one is like how do you get around IP addressing being your source of truth basically. So what we did in our control deployment is we said there's one gigantic system, or one giant pool of IP addresses and every time you spin up a new instance of something like you just get a random IP address and that's just the world that developers are gonna live in now. So if you wanna identify that application you actually do it by the virtual network name. So we have a system that says your network name is actually named after your application and we have a format for that that makes everything standardized. So when you look in the contrail like debug view you can basically see like VNA talking to VNB on this port and then as apps come and go they always fall into that VN and then inherit that policy. If we need a fixed point we rely on DNS or there's also a concept especially for like public like whitelisting coming in from the edge like sometimes you just need to have it. You can set aside like a special range and just say like okay this is the exception but that's a floating IP address. So like that you'll come in you'll hit that and then that does a nat which will hit the actual so that floating IP will stay static so someone can hit it but behind the scenes it's always changing IPs. What was your second question? Second question is you have a different kind of system. You have a legacy system. You have a firewall and public cloud. Yeah so we implemented a system called in our cluster we trust which what we said was in our SDN is where all the policies live and these all of our SDN clouds come from known address spaces and in our cluster we trust says that all the rest of the systems should just trust that the clusters are filtering on outbound. So the rest of the systems that are external to the cluster you have to manually go and define like I wanna reach it. So it's kind of shifting the policy from the external device closer to the source but there's still a point of enforcement in between the applications. So there's one rule on all of our devices that say like you can permit these 10 addresses they're 10 WAC 8s or whatever we WAC 16s as a summary and then that way we'd never have to update those legacy devices anymore. Yeah another maybe my point is you have this different kind of system. So the enforcement mechanism may be different. For example in public cloud maybe you cannot use like neutral security group to do that because so I want to know how you consider this. So I can take that one right? So basically the way we do it is based on tags and labels right? Now for example if you have contrary less the SDN across all these environments right? What you can do is when a VM comes up for example it comes up in a particular let's say let's take the example of deployment and site. So it comes up in let's say test deployment and the site is let's assume it's Boston or hypothetically right? So when a VM comes up we know where the location is and so these tags get applied there yeah? So now what you're seeing now in your application now when you're defining policy you can say I want app A to talk to app B but only if their deployment matches and they are on the same site right? Something to that extent. That trans, so that abstract policy goes down to let's say your respective cloud and man-mans and Contrail knows that these tags right? When a VM came up it knew it came up in Boston and so on and when you're getting in traffic in or when you're really applying the policy you use these tags to match exactly where things are coming and all that stuff right? So tags and labels are ways you can abstract out the real infrastructure underneath so you don't necessarily have to do it security group based et cetera. So the tags actually you are carried in the pack the header? So I think we're now going into more implementation details probably we can have a conversation on the site but we can talk about that yeah? Okay thanks. Okay thanks for the question. So another topic that we like to touch on we're getting towards the end here. You talked about intentions now this is not exactly the same thing here but one of the things we said we would cover is intent based policy. So I like to hear from our panel what can we understand by this term intent based policy and yeah let's start there and then we can look at implementation how do you actually go about implementing it? So as I said earlier a big part of intent is actually describing application behavior. So for us the way we actually define this is the application intent is actually captured in a textual file right? Which describes what the application needs in terms of application to application communication or even external communication to external services as well and we do this by essentially that definition needs to be in a portable fashion right? And now when you deploy that particular application at that point in time that intent needs to get plumbed down into different configurations like setting up your firewalls or setting up your networking routes as well from that standpoint and then you measure against that intent right? And then so that intent is what you are managing at that point in time to make sure it is always being enforced. So I'll piggyback off of that too. We have a team that used to essentially just kind of decide where things go. Oh this is a web server okay it has to go over here. This is a database it goes over here. Oftentimes we have an MIS network that's well it's 10 slash eight we'll just shove it in there and deal with it. We are rapidly moving towards more of a like what Rahul is talking about of identifying okay this is a web server. Is it an internal web server? Is it an external web server? And then developing policy around it and saying okay well if it's an external web server you naturally get X policy. And no matter where you go this policy follows you around no matter where you live. If it's in our data center, if it's in public cloud it just follows you around wherever you go. Yeah I think you guys said it well. It's for us just like what do you want to happen and we will take care of the details. So as long as you're not being too descriptive like you're just saying I want me to talk to this and maybe talk to a load bouncer and that's it. Like then it frees up that the operations team is just in force at anyway they want. So it really just makes a good level of abstraction because that's all application developers really want to say is like I need to talk to this. Like make it happen. So we don't want them specifying IP addresses and things because they're probably gonna not have the knowledge to do that or if they do it's gonna be difficult and painful for them so it's just a good way to kind of that separation of concerns and allow each team to do what they do best. From tools and vendors perspective, right? Couple of things that are essential to help our customers realize intent based policies. One, you're defining a policy now do you really know if your intent has actually been met with the policy, right? So there are things like capabilities like you can add where you have a learning mode where you are simulating your policies and making sure the intent is actually being met, right? So that's one of the things you can do as tools. And secondly, now where is this intent coming from, right? Given the world we are in and how it's evolving with analytics and monitoring a lot of your policies are going to come through like this and anomalous behavior detected and an automatic, you know, the analytics tool or monitoring tool may want to impose a policy and so it may basically just do a self remedial policy invocation, right? So in those cases, your API should be actually flexible enough to capture an intent and so on. So from a tools perspective, those are two things I would say. Okay, perfect, thank you. So we're getting near the end of our session so perhaps we can end on a last question here. Sort of looking ahead into the future. What does the future hold for policy automation? And you guys all come from very different backgrounds here and have different, you know, maybe you're working on something as a vendor or perhaps as a user, service provider, you have certain things on your wish list. So what's next for policy automation? For me, I hope that the community drives toward unified policy language. If you think about it's really not any vendor's best interest to come up with this because they all have their own ways of doing things. And if we need, if we want to be able to be portable across vendors and we really want to enable our developers to just simply state what they need and then free us up, that kind of has to come from us. It's a huge challenge to interact with devices today that are, you know, one may speak in firewall zones, another one has access groups, another one has policy statements, another one like is, you know, it's just by P-tables. It's just all over the place. And I don't think those are ever gonna unify on their own. But if we create, is any, I pick on software developers sometimes because they want to solve everything with like another layer of abstraction. But like I think this is probably like, just like network engineers, like any problem can be solved with another tunnel. So it's like, maybe we should just tunnel the abstraction layers and, oh, it's contrail. But like that's what I hope is that, because right now the primitives that we use in OpenStack are very much like, here's an ACL and they kind of still speak in that language. So I would like to see another kind of project or effort that speaks from a different perspective into the system that will take in that and then allow maybe another compiler somewhere in the middle to actually, you know, affect the policy. So we want to do two things. We want to leverage a centralized policy enforcement configuration to free up our operations team. We're pretty much at like 125% of what we can do. We've been told you're not getting any more FTEs so figure it out. So, you know, what's the next evolution? And it's essentially kind of what Doug is talking about of, well, we got to start automating this and get this day-to-day offer back and free up our guys to do what they really were hired to do in the first place, which is solve head-scratching problems like, wow, would it do that? So I think it all comes down to really, you know, scale, speed, talent, right? So what you're going to find is, you know, earlier you had a server-to-admin ratio of probably what, about 10 to 1 with virtualization that went to 100 to 1. And now I think we're going to see the next level of magnitude, right? And the only way you'll get there is with policies because you need that to manage scale, right? And the issue you're going to really face is there's a talent crunch. You just can't find really good people, right, to go do that at that point. So what we're going to find is, you know, we're going to get more and more sophisticated in terms of applications. There are some great talks here as well about how applications are going to move closer to the user for performance to essentially satisfy performance QoS. There's going to be, for cost arbitrage, you'll be able to move applications to lower cost infrastructures as well. And all of this is going to be automated, right? And so what TPU was talking about earlier about things like machine learning, and there's a lot of different aspects that need to get factored into creating these policies automatically as well. And so when you kind of take these kind of these business factors in mind and the technology constructs are all there, it's just a question of how quickly can we actually get to those different proof points. And lastly, I think I would summarize it to two things primarily from our perspective to help our customers realize exactly what they have said here, right? So the right level of abstraction is important and how you can translate that abstraction to be able to enforce policies on a variety of infrastructures. So be infrastructure agnostic, but at the same time when you have public cloud or when you have on-prem cloud be it open stack or whatever, be able to apply that policy in these diverse environments, right? These two are the most critical things from our perspective. Perfect. Well, thank you so much to our panel and also thank you to our audience for sticking around and asking your thoughtful questions. Really appreciate it and this concludes our session today. Thank you. Thank you. Thank you.