 For the comment today, I hope you've had a great day. I know I've had a great day. I enjoy Cloud Foundry Summit quite a bit. So I want to talk a little bit today sort of like the black holes discussion. What does this cloud-native transformation mean to you? Trying to put a little bit of actual science behind how we're going to get there. Sort of thinking about cloud-native, you've got to start with, what does it mean? How do you define cloud-native? Talk about for those of us who've been on this journey for some time, what are the lessons that we've learned? And I guess more importantly, what does that mean going forward? How do we take what we've learned and what we know today and move forward with that? And then something I want to kind of analysis exciting is some work that we've been doing with Mezos and with the Cloud Foundry community. And so what is cloud-native? Cloud-native is simply defined by these three different areas. You have sort of container packaged. So how do you take an application and look at making it sort of a subset of components? How do you break that application into smaller pieces? It's sort of the orchestration and dynamic management of that application. So you have to, one thing is having container packaged. The next thing is orchestration and the management of that in a dynamic environment. And I think the last thing which gets overlooked a lot is it's this whole new sort of application architecture or application design pattern that is microservices enabled. How do you take an application architecture and break it into the smaller components that you then can make containerized? So those are the three areas that we think about when we talk about cloud-native in the industry. When you think about those three things, you think about the people in your organization. You're probably saying, well, we've had a hard time just moving into cloud, much less moving to this whole microservices model. I think it's important to realize that you have to work with your people, help your people understand. And these are like employees, developers, and operators, and DevOps teams. Help them understand what this means to them, right? That you can't just use the term magically, microservices fixes all of these problems, right? You still have a lot of organizational legacy ways of doing your business that you have to look at. You don't have to change all of them, but you have to look at which ones make sense to change versus which ones do not. You also have a lot of process areas to think about. And so this whole SDLC process and this whole move towards agile development is great, but it does come with a little bit of a new methodology around how do you develop your code? How do you manage and maintain your code? How do you then deploy that in a lot of different environments? So when you think about cloud, you're not looking at just your own internal data systems anymore, you're thinking about other environments as well, typically. And so how do you manage deployments across multiple environments, multiple infrastructures? How do you operate that service across multiple environments? How do you update it? How do you maintain your software differentiation when you're deploying this service out into the public internet? And there's this whole problem of it works fine when I was developing it. Why doesn't it work in production, right? And so a lot of what we've seen in this process is that development is much more complicated now than it was before. We've done a great job as an industry, I think, especially from an infrastructure side of things. We made the infrastructure really simple, really fast to get your VMs or get your containers, right? And it's very simple to do this. But you pushed all of that complexity now to the developer. And you ask a developer to make these hard choices about how much CPU they need, how much memory they need, where they want to deploy their application. As an industry, I think we've pushed the problem up to the software level. And that's where a lot of times you see this issue of, it worked fine when I was testing on my laptop. But why doesn't it work in production? And the thing I've noticed with cloud native development is that it always works great when it works. But when it doesn't, it's very difficult to troubleshoot. And that's a problem I think it's an industry we can solve for sure. There's also obviously technology pieces as well, right? And so everything in our industry has a lot of technology pieces. And so when you think about your data centers and how they're transforming always, you want to sort of think about something I call hybrid DevOps, which is you're in a current state. There's a future state you're going to always want to get to, kind of building a continuous pipeline of going from where you're at to the future is something you should probably invest in now, right? Instead of always having a next gen something, let's create a platform that has sort of next gen built into it. So as next gen comes around, it's just a new service or a new capability that just shows up in your SDLC. You don't have to think about, how do I involve this new platform? The other thing that I think is interesting is this commoditization of infrastructure, right? And so when we talk about multiple clouds and hybrid cloud, now you're asking basically your developers to not only understand how to write the application in a way that differentiates your business, but they also have to now understand the APIs of any sort of external cloud site they deploy into. And so now they've, in addition to making sure their application is helping your business grow and differentiating in your business, they now have to understand how all these other cloud providers, APIs, will support them. And any time there's a change to those APIs, guess whose job it is to figure that out? The developer, right? And so you just complicated their job, again, by saying, hey, go use this cloud provider. They're great. And they're like, oh, that's great, but I don't know that API. Now I have to learn that API, right? And if a provider comes along and says, hey, we'll give you a great deal, switch over to our cloud, guess what? It's, again, the developer's job to figure out how to write to that API again, right? And they might say they're compatible, but they're really not. So that's just kind of a trick to remember from a technology standpoint. So what are some of the lessons that we as a community are learning? Not just the Cisco customers I work with, but being in the community, I've worked with a lot of different customers from different areas. And so I think the first one is, whatever you're doing from a deployment model, however you're orchestrating that deployment needs to be part of your test process, right? There's sort of this new problem that we didn't really quite understand until recently that, instead of it being that it worked on my machine, it's an ops problem now, it's sort of like, well, it orchestrated on my machine. Why doesn't it work in that environment, right? And so the more that you can take your orchestration components that you leverage for deployments into whatever environment you deploy into and make that part of your build process and your testing of that build process, I think the better off you are at solving this problem. The other problem that we've kind of looked at, at least from a Cisco standpoint, is this entire infrastructure thing I mentioned before with we made it really easy for infrastructure, we made it more difficult for the developers, how do we sort of help the developer now? How do we think more about the software developer and make it easier for them to deploy their application, make it easier to integrate with how they develop? And so kind of this whole like, as you build your application, let the developer write in the programs that they like to write in, right? So a good example of that is Cloud Foundry is a very popular framework. So why not allow the developer to develop in Cloud Foundry, focus on their application and then separate the deploy from that piece so that you can then have a choice of places to deploy to that you've already sort of made sure that those APIs work with that infrastructure deployment model, right? So you don't have to ask the developer to go figure out those infrastructure components and then give a single interface for that developer to look at that application running across those multiple hybrid clouds and understand how it's going to run. There's this whole like aspect of how do you solve for this code issue, right? As you write your code and test it, you want to kind of make sure that everything's working together. The way you kind of take a big model application and break it into smaller components is important in this conversation because if you are going to think about applications as terms of smaller services and how those services interact, it's important to consider at first, how do I break that apart? Do I, how many services do I need? And there's a new term that we've been starting to use called nano services, right? You don't want to create a bunch of nano services where you're making individual component level calls to do like one function, right? You want to kind of break your software into small enough chunks that you can execute them at a level of abstraction that doesn't require you to make individual calls to each individual component. You also want to kind of understand how to control where these clouds are being deployed to some extent, right? And this is one of those debatable areas, but I think there's still a desire for having policy and having an ability to kind of control compliance and governance type of areas and security components within that infrastructure and in those deployments. And so having the ability to sort of control that, I think it's still important in this discussion and being able to really make sure that that visibility extends across the entire spectrum, right? Because today it's very difficult to isolate a problem because you have to log in to four or five different consoles. And maybe one of those consoles will tell you where the problem is, but in most cases it's a combination of issues that cause the problem and it's hard to isolate those. So this is kind of tying back to the previous conversation, right? I think Einstein had a lot of great ideas, but this is probably the best one, right? That when you're doing this, it starts a complicated environment today. Let's make it simpler, right? Let's try to make this a lot easier to do. And I think when you look at cloud native architectures, that's trying to get to that discussion where we make things simpler in the end. It may seem complicated if you get underneath the covers, but it should seem as simple as possible. The other thing is you don't wanna have too much of a hierarchy within your organization so that you sort of cause your projects to fail because you just have too many different layers of individuals and processes and tooling that has to be gone through. And so a big part of this is don't forget to look at your organization, how you structure your teams, how you structure your projects, how you structure your development projects and frameworks. And then the last lesson learned is sort of this whole composition thing. Making these services as reusable as possible and as self-contained as possible is really important, but don't forget that there's still linkages between these services, right? And it might be a loose coupling, but there's still a coupling there that they're not lose track of. And so that's sort of the lessons we've learned along the way and that are still learning, I should say. And so then what I wanna talk about next is sort of what I've been working on at Cisco is creating a Mezos framework to support all the cloud native services. And it's kind of, we'll call it a containerized, trying to containerize Cloud Foundry is what we're trying to do. I'm working with the foundation right now to sort of get certification for this work. But the idea was sort of taking each of the different CF components and putting them inside a framework and we're demoing this in our booth if you wanna come down and see it tomorrow. But all the different aspects of a Cloud Foundry deployment you can leverage within a Mezos framework. And then what we've did was kind of tie it into the pipeline, of course. So as new capabilities come out, we pick them up and create a relevant framework and highlight those changes in the pipeline. And then the other thing is a lot of administration has been done in a lot of enterprises that take Cloud Foundry and kind of leverage the authentication mechanisms. So we wanted to make sure we supported that as seamlessly as possible. So if you're interested in learning more about any of these projects, we have a couple of sites. So you can go look at Mantle.io. This is an open source project that Cisco started, but it's a large community now. It's definitely not, I think I have like eight developers on it, but there's like 70 developers working on the project. So it was definitely not a Cisco only project. But the whole point of Mantle is sort of taking the best of breed open source components and bringing them together and making it easier and simpler to run services and this whole new infrastructure that we'll call in microservices infrastructure, I'm making this whole cloud native model a lot easier. We also have a developer experience to kind of go along with this. It sort of looks at that problem I mentioned earlier of trying to solve this developer, making it easier for developers to build and deploy and run their applications without having to worry about the underlying complexities of the infrastructure. And so that's at CiscoShip.io. And then so those are sort of the two big projects we have the work we're doing in Cloud Foundry, containerizing Cloud Foundry as part of that Mantle.io site. So you can look at that code if you want. And so in summary, the cloud native transformation is something that is occurring in most places already. Most of you guys are here because you're part of that already. So there's no reason for me to make it more obvious than it's happening. You can look around and see other people here. So we know it's happening. There are the things that you need to think about with your people and your organization on how you look at that. There are things in the process and making sure that your orchestration is happening as part of your development process versus an after the fact thing. And there's a lot of lessons to be learned on sort of how do you adopt new technologies and make this more continuous from the beginning. And then the interesting, if you're interested in the work on the MESO stuff we're doing, we're also planning to do the same thing with Kubernetes. And so our goal is to sort of make it an open platform that allows a lot of different choice for the developer and for the infrastructure admins. And so that's sort of what we're working on. And thank you very much for your time.