 From around the globe, it's theCUBE with digital coverage of DockerCon Live 2020, brought to you by Docker and its ecosystem partners. Welcome, welcome, welcome to DockerCon 2020. You've got over 50,000 people registered, so there's clearly a ton of interest in the world of Docker Nettys, as I like to call it. And we've assembled a power panel of open source and cloud native experts to talk about where things stand in 2020 and where we're headed. I'm Sean Conley. I'll be the moderator for today's panel. I'm also a proud alum of Jbos, Red Hat, Spring Source, BMware, and Hortemarks, and I'm broadcasting from my hometown of Philly. Our panelists include Michelle Nourali, Senior Software Engineer at Microsoft, joining us from Atlanta, Georgia. We have Kelsey Hightower, Principal Developer Advocate at Google Cloud, joining us from Washington State. And we have Chris Anizic, CTO COO at the CNCF, joining us from Austin, Texas. So I think we have the country pretty well covered. Thank you all for us spending time with us on this CUBE power panel. Chris, I'm going to start with you. Let's dive right in. You've been in the middle of the Docker Nettys wave since the beginning with a clear focus on building a better world through open collaboration. What are your thoughts on how the open source landscape has evolved over the past few years? Where are we in 2020? And where are we headed from both community and a tech perspective? Just curious to get things sized up. Sure, you know, when CNCF started about roughly four over four years ago, the technology mostly focused on just the things around Kubernetes, you know, monitoring Kubernetes with technology, Prometheus. And I think in 2020, in the future, we've definitely, quote unquote, moved up the stack. So there's a lot of tools being built on the periphery now. So there's a lot of tools that handle running different types of workload on Kubernetes. So things like CUBE vert essentially runs VMs on Kubernetes, which is crazy, not just containers. We have folks at Microsoft experimenting with a project called Crosslet, which is trying to run WebAssembly workloads natively on Kubernetes. So I think what we've seen now is more and more tools built around the periphery while the core of Kubernetes has stabilized. So different technologies and spaces, such as security and different ways to run different types of workloads on Kubernetes. That's kind of what I've seen. So do you have a fair amount of sort of vendors as well as end users still submitting in projects in, you know, is there still a pretty high volume? Yeah, we have 48 total projects in CNCF right now. And Michelle could speak a little bit more to this, being on the DOC, but the pipeline for new projects is quite extensive and it covers all sorts of spaces from the service meshes to security project and so on. So it's ever kind of ever so expanding and filling in gaps in that, in that cognitive landscape that we have. Awesome. Michelle, let's head to you. But before we actually dive in, let's talk a little glory days. A rumor has it that you were the fifth grade kickball championship team captain. So are the rumors true? They are. They are. I used to give a speech at the end of the year. It was the first talk I ever gave. But yeah, it was really fun. I was happy because I wasn't really great at anything else. But I would definitely cheer on the team, but yeah. A little better than my eighth grade spelling champ award. So I think I'd rather have the kickball. But you've definitely, you know, spent a lot of time leading an open source. You've been across many projects for many years. So how does the art and science of collaboration, inclusivity and teamwork vary? Cause you're involved in a variety of efforts both in the CNCF and even outside of that. And then what are some tips for expanding the tent of open source projects? That's such a good question. You know, I think it's about transparency. Just come in and tell people what you really need to do and clearly articulate your problem is the more clearly articulate your problem and why you can't solve it with any other solution. The more people are going to understand what you're trying to do and be able to collaborate with you better. So I think what I love about open source is that where I've seen it succeed is where incentives of different perspectives and parties align and you're just transparent about what you want. So you can collaborate where it makes sense even if you compete as a company with another company in the same area. So I really, I really like that. But I just feel like transparency and honesty is what it comes down to and clearly communicating those objectives. Yeah, and the various foundations, I think one of the things that I've seen particularly Apache software foundation and others is the notion of checking your badge at the door because it can get the competition might be between companies but in many respects you have engineers across many companies they're just kicking butt with the tech they contribute and claiming victory in one way or the other might make for interesting marketing drama. But I think that's a little bit of the challenge. In some of the standards-based work you're doing, I know CNI and some other things, are they similar or are they different? How would you compare and contrast into something that's a little more structured like CNCF? Yeah, so most of what I do is in the CNCF but there's like specs and there's projects. I think what CNCF does a great job is is just iterating to make it an easier place for developers to collaborate. You can ask the CNCF for basically whatever you need and they'll try their best to figure out how to make it happen and we just continue to work on making the processes are clearer and more transparent. And I think like in terms of like specs and projects, those are such different collaboration environments, right? Because if you're in a project, you kind of have to say, okay, I want this feature or I want this bug fix. But when you're in a spec environment, you have to think kind of a little outside of the box and like what framework do you want to work in? You have to think a little farther ahead in terms of is this solution or this decision we're gonna make going to last for the next how many years? You have to get more of a buy-in from all of the key stakeholders and maintainers. So it's a little bit of a longer process I think but what's so beautiful is that you have this really solid standard or interface that opens up an ecosystem and allows people to build things that you could never have even imagined or dreamed of. So I think that's pretty cool. Gotcha. So Kelsey, we'll head over to you as, I mean, your focus is on developer advocate. You've been on the cloud native front lines for many years. Today developers are faced with a ton of moving parts, spanning containers, functions, cloud service primitives, including container services, serverless platforms, lots more, right? I mean, there's just a ton of choice. How do you help developers maintain a minimalist mantra in the face of such a wealth of choice? I think minimalism, I hear you talk about that periodically. I know you're a fan of that. How do you pass that on in your developer advocacy and your day-to-day work? Yeah, I think for most developers, most of this is not really the top of mind for them, it's something you may see a post on Hacker News and you might double click into it. Maybe someone on your team brought one of these tools in and maybe it leaks up into your workflows or you're kind of forced to think about it. But for most developers, they just really want to continue writing code like they've been doing. And the best of these projects, they'll never see, right? They just work, they get out of the way, they help them with logging, they help them run their application. But for most people, this isn't the core idea of the job for them. For people in operations, on the other hand, maybe these components fill a gap. So they look at a lot of this stuff that you see in the CNCF and the open source space as number one, various companies or teams sharing the way that they do things, right? So these are ideas that are put into the open source. Some of them will turn into products. Some of them will just stay as projects that have mutual benefit for multiple people. But for the most part, it's like walking through an aisle and like Home Depot, right? You pick the tools that you need. You can safely ignore the ones you don't need and maybe something looks interesting and maybe you study it to see if you have a problem. And for most people, if you don't have that problem that that pull solves, you should be happy. No one needs every project. And I think that's where the foundation for confusion. So my main job is to help people not get stuck in confusion land and just be pragmatic and just use the tools that work for them. Yeah, and you've spent the last little while in the serverless space really sort of diving into that area, compare and contrast, I guess, you know, what you're found there, you know, minimalist approach, you know, who are you speaking to from a serverless perspective versus that are the broader CNCF? The serverless thing, the thing that really pushed me over, I was teaching my daughter how to make a website, right? So she's on her Chromebook making a website and she's hitting 127.0.0.1. And it looks like GeoCities from the 90s, but look, she's making a website and she wanted her friends to take a look. So she copied and paste from her browser 127.0.0.1 and then her friends could pull it up. So this is the point where every parent has to cross that line and say, hey, do I really need to sit down and teach my daughter about Linux and Docker and Kubernetes? That isn't her main goal. Her goal was to just launch her website in a way that someone else can see it. So we got Firebase installed in her laptop, she ran one command Firebase deploy and her site was up in a few minutes and she sent it over to her friend and there you go, she was off in the running. The whole serverless movement has that philosophy as one of those stated goal. That needs to be the workflow. So I think serverless is starting to get closer and closer you start to see us talk about and Chris mentioned this earlier for moving up the stack. Where we're going to up the stack, the North Star there is that kind of feel where you get to focus on what you're doing and not necessarily how to do it underneath. And I think serverless is not quite there yet for every type of workload, stateless web apps, check event driven workflows, check, but not necessarily for things like machine learning and some other workloads that more traditional enterprises want to run. So there's still work to do there. So serverless for me serves as the North Star for why all of these projects exist for people that may have to roll their own platform to provide that experience. So Chris on a related note with what we were just talking about with Kelsey, what's your perspective on the explosion of the cloud native landscape, right? There's a ton of individual projects. Each can be used separately, right? But in many cases, they're sort of like Lego blocks and used together, right? So things like the service mesh interface, standardizing interfaces, so things can snap together more easily, I think are some of the approaches, but are you doing anything specifically to encourage this sort of cross fertilization and collaboration of plugability? Or because there's just a ton of projects, not only at the CNCF, but outside the CNCF that need to plug in? Yeah, I mean, a lot of this happens organically. CNCF really provides kind of the neutral home where companies, competitors could trust each other to kind of build interesting technology. We don't force integration or collaboration. It kind of happens on its own. We essentially allow the market to decide what a successful project is long-term or what an integration is. We have a great technical oversight committee that kind of helps shepherd the overall technical vision for the organization and sometimes steps in and tries to do the right thing when it comes to potentially integrating a project. Previously, we had this issue where there was a project called Open Tracing and an effort called Open Census, which is basically trying to standardize how you're going to deal with metrics, telemetry, and so on in a cloud-native world that we're kind of essentially competing with each other. The CNCF, TOC, and community, I came together and merged those projects into one parent effort called Open Telemetry. And so that to me is kind of a good case study, how our community kind of helps bridge the things, but we don't force things. We essentially want our community of end users and vendors to kind of decide which technology is best in the long-term and we're going to support that. Okay, awesome. And Michelle, you've been focused on making distributed systems digestible, which to me is about simplifying things, right? And so back when Docker arrived on the scene, some people refer to it as developer dopamine, which I love that term, because it simplified a bunch of crafty stuff for developers and actually helped them focus on doing their job writing code, delivering code. What's happening in the community to help developers wire together multi-part modern apps in a way that's elegant, digestible, feels like a dopamine rush. Yeah, that was the, that was one of the goals of the HOM project was to make it easier to deploy an application on Kubernetes so that you could see what the finished product looks like and then dig into all of the things that that application is composed of, all of the resources. So I'm really passionate about this kind of stuff for a while now. And I love seeing projects that come into the space that have this same goal and just iterate and make things easier. I think we have a ways to go still. I think a lot of the iOS developers and no JS developers I get to talk to don't really care that much about Kubernetes. They just wanna like Kelsey said, just focus on their, focus on their code. So one of the projects that I really like just working with is tilt, gives you this like dash forward in your CLI, it aggregates all your logs from your applications and it kind of watches your, watches your application changes and reconfigures those changes in Kubernetes so you can see what's going on and it'll catch errors. Anything with a dashboard I like love these days. So Kiali is like a metrics dashboard that's integrated with Istio and you a service graph of your service mesh and lets you see the metrics running there. I love that dashboard so much. LinkerD has some really good service graph images too. So anything that helps me as an end user, which not technically an end user, but me as a person who's just trying to get stuff up and running and working, see the state of the world easily and digest that has been really exciting to see and I'm seeing more and more dashboards come to light and I'm very excited about that. Yeah, as part of the DockerCon, just as a person who'll be attending some of the sessions, I'm really looking forward to see where Docker Compose is going. I know they open up the spec to broader input. I think your point, the good one is there's a little, there's a bit more work to kind of really embrace sort of the wealth of application artifacts that compose a larger application so there's definitely work the broader community needs to lean in on I think. I'm glad you brought that up actually. Compose is something that I should have mentioned and I'm glad you bring that up. I wanna see programming language libraries integrate with the Compose spec. I really wanna see what happens with that. I think it's great that they open that up and made that a spec because obviously people really like using Compose. Excellent. So Kelsey, I'd be remiss if I didn't touch on your January post on changelog entitled monoliths are the future. Your post actually really resonated with me. My son works for a software company in Austin, Texas. So you're hometown there Chris. Shout out to Will and the Coros team. His development work focuses on adding modern features via microservices as extensions to the core monolith that the company was founded on. So just share some thoughts on monoliths, microservices and also what's deliverance dopamine from your perspective sort of more broadly? But monoliths, people usually phrase it as monoliths versus microservices but I get the sense you don't believe it's either or. Yeah, I think most companies from the pragmatic so that argument is one of pragmatism. Most companies have trouble designing any app, monolith, deployable or microservices architecture. And then these things evolve over time. Unless you're really careful, it's really hard to know how to slice these things, right? So taking an idea or a problem and just knowing how to perfectly compartmentalize it into individual deployable component, that's hard for even the best people to do and double down knowing the actual solution to the particular problem. A lot of problems people are solving, they're solving for the first time. It's really interesting like our industry in general, a lot of people who work in it have never solved the particular problem that they're trying to solve for the first time. So that's interesting. The other part there is that most of these tools that are here to help are really only at the infrastructure layer, right? We're talking freeways and bridges and toll bridges so there's nothing that happens in the actual developer space right there in memory. So the libraries that interface to the structured logging, the libraries that deal with rate limiting, the libraries that deal with authorization, can this person make this query with this user ID? A lot of those things are still left for developers to figure out on their own. So while we have things like Kubernetes and FluidD, we have all of these tools to deploy apps into those targets, most developers still have the problem of everything you do above that line. And to be honest, the majority of the complexity has to be resolved right there in the app. That's the thing that's taking requests directly from the user. And this is where maybe as an industry, we're over-correcting. So we had, you know, you say you come from the Jboss world, I kind of started a lot of my system administration. There's where we kind of focused a little bit more on the actual application needs, maybe from around it as well, but now what we're seeing is things like Spring Boot, start to offer a little bit more integration points in the application space itself. So I think the biggest parts that are missing now are, what are the frameworks people will use for authorization? So we have projects like OPA, OPA, Open Policy Agent for those that are new to that. It gives you this very low level framework, but you still have to understand the concepts around what does it mean to allow someone to do something? And one misconfiguration, all your security goes out of the window. So I think for most developers, this is where the next set of challenges lie if not actually the original challenge. So for some people, they were able to solve most of these problems with virtualization, right? Run some scripts, virtualize everything and be fine. And monoliths were okay for that. For some reason, we've thrown pragmatism out of the window and some people are saying the only way to solve these problems is by breaking the app into a thousand pieces. Forget the fact that you had trouble managing one piece. You're gonna somehow find the ability to manage one thousand pieces with these tools underneath but still not solving the actual developer problem. So this is where you've seen it already with a couple of popular blog posts from other companies. They cut too deep. They're going from 2,000, 3,000 microservices back to maybe a hundred or 200. So to my world, it's gonna be not just one monolith, but end up maybe having 10 or 20 monoliths that maybe reflect the organization that you have versus the architectural pattern that you're at. Yeah, I view it as like a constellation of stars and planets, et cetera. Where you might have a star that has a variety of, which is a monolith and you have a variety of sort of planetary microservices that sort of float around it. But that's reality. That's the reality of modern applications, particularly if you're not starting from a clean slate. And your point's a good one is, in many respects, I think that infrastructure as code movement has helped automate a bit of the deployment of the platform. I've been personally focused on app development, Jboss as well, the spring source, the spring team. I know that tech pretty well over the years because I was involved with that. So I find that James Governor's discussion of progressive delivery really resonates with me as a developer, not so much as an infrastructure deployer. So continuous delivery is more of an infrastructure notion. Progressive delivery, feature flags, those types of things are app level concepts, minimizing the blast radius of the new features you're deploying. That type of stuff I think begins to speak to the pain of application delivery. So I guess I'll put this up, Michelle, I might aim it to you and then we'll sort of go around the horn. What are your thoughts on sort of the progressive delivery area, how could that potentially begin to impact cloud native over 2020? Like I'm looking for some rallying cries that move up the stack and give some a set of best practices if you will. And I think James Governor and Redmauk are poking on something I think is pretty important. Yeah, I think it's all about automating all that stuff that you don't really need to know about. Like Flagger is an awesome progressive delivery tool. You can just deploy something and people have been asking for so many years, ever since I've been in the space, it's like, how do I do AB deployment? How do I do Canary? How do I do, how do I execute these different deployment strategies? And Flagger is a really good example for example, it's a really good way to execute these deployment strategies, but then make sure that everything's happening correctly via observing metrics, roll back if you need to, so you don't destroy your whole system. I think it solves a problem. It allows you to take risks, but also kind of keeps you safe in that, you can be confident as you roll out your changes that it all works, it's metrics driven. So I'm just really looking forward to seeing more tools like that and dashboards enable that kind of functionality. Chris, what are your thoughts in that progressive delivery area? I mean, CNCF alone has a lot of projects in this space, things like Argo that are tackling it, but I kind of want to go back a little bit to your point around developer dopamine. As someone that probably spent about a decade his career focused on developer tooling and in fact, if you remember the Eclipse IDE and that whole integrated experience, I was blown away recently by a demo from GitHub. They have something called Codespaces, which a long time ago, I was trying to build development environments that essentially if you were an engineer that joined a team recently, you could basically get an environment quickly started with all everything configured, source code checked out, environment properly set up and that was a very hard problem. This is like before container days and so on and to see something like Codespaces where you go to a repo or project, open it up, behind the scenes, they have a container that is set up for the environment they need to build and just have a VS code ID integrated experience. To me is completely magical. It hits like developer dopamine immediately for me because a lot of the problems when you're going to work with a project to contribute that whole initial bootstrap of, oh, you need to make sure you have this library, this is all, it's so incredibly painful on top of just setting up your developer environment. So as we continue to move up the stack, I think you're going to see an incredible amount of improvements around the developer tooling and developer experience that people have powered by a lot of this cloud native technology behind the scenes that people may not know about. Yeah, because I know I've been talking with the team over at Docker, the work they're doing with that desktop, enable the aim local environment, make sure it matches as closely as possible as your deployed environments that you might be targeting. These are some of the pains that I see. It's hard for developers to get bootstrapped up. It might take them a day or two to actually just set up their local laptop and development environment and particularly if they change teams. So it's that complexity really corraling that down and not necessarily being overly prescriptive as to what pool you use, right? So if your visual code, great, it should feel integrated into that environment. If you use a different environment or if you feel more comfortable at the command line, you should be able to opt into that. That's some of the stuff I get excited to potentially see over 2020 as things progress up the stack, as you said. So, Michelle, just from an innovation train perspective, we've covered a little bit, what's the best way for people to get started? I think Kelsey covered a little bit of that, right? Being very pragmatic, but there's just, all this innovation is pretty intimidating. You can get mowed over by the train, so to speak, right? So what's your advice for how people get started? How do they get involved, et cetera? Yeah, it really depends on what you're looking for and what you want to learn. So if you're someone who's new to the space, honestly, check out the case studies on CNCF.io. Those are incredible. You might find environments that are similar to your organization's environments and read about what worked for them, how they set things up, any hiccups they crossed. It'll give you a broad overview of the challenges that people are trying to solve with the technology in this space. And you can use that to drill into the areas that you want to learn more about just depending on where you're coming from. I find myself watching old KubeCon talks on the Cloud Native Computing Foundation's YouTube channel. So they have like playlists for all of the conferences and the special interest groups in CNCF. And I really enjoy watching, excuse me, the older talks just because they kind of explain why things were done the way they were done. And that helps me build the tools I built. And if you're looking to get involved, if you're building projects or tools or specs and want to contribute, we have special interest groups in the CNCF. So you can find that in the CNCF Technical Oversights Committee's TOC GitHub repo. And so for that, if you want to get involved there, kind of choose a vertical. Do you want to learn about observability? Do you want to drill into networking? Do you care about how to deliver your app? So we have a SIG called App Delivery. There's a SIG for each major vertical. And you can go there to see what is happening on the edge, really. These are conversations about, okay, what's working, what's not working, and what are the next changes we want to see in the next few months. So if you want that kind of granularity and discussion on what's happening like that, then definitely join those meetings and check out those meeting notes and recordings. Gotcha. So Kelsey, as you look at 2020 and beyond, I know you've been really involved in some of the earlier emerging tech spaces. What gets you excited when you look forward? You know, what gets your own level of dopamine up versus sort of the broader community? You know, what do you see coming that we should start thinking about now? I don't think any of the raw technology pieces get me super excited anymore. Like I've seen the circle come around three or four times, right? Like in five years, there's going to be a new thing. There might be a new foundation. There'll be a new set of conferences and we'll all rally up and probably do this again. So what's interesting now is what people are actually using the technology for, right? Some people are launching new things that maybe weren't possible because infrastructure costs were too high. There are people able to jump into new business segments. You start to see this with like these channels on YouTube where everyone can buy a mic and a free app and have their own podcast, right? And be broadcast to the globe just for a few bucks if not for free. Those kind of revolutionary things are kind of the big deal and they're hard to come by. So I think we've done a good job democratizing these ideas, distributed systems. You know, one company got really good at packaging applications to share with each other. I think that's great. And now we're going to reset again. And now what's going to be interesting is what will people build with this stuff? If we end up building the same things we were building before and then we're talking about another digital transformation 10 years from now because people will be, you know it's going to be funny but Kubernetes will be the new legacy. It's going to be the things that, oh man I got stuck in this Kubernetes thing and there'll be some governor on TV looking for old school Kubernetes engineers to migrate them to some new thing, right? That's going to happen, right? You got to know that. So at some point this merry-go-round will stop. And we're going to be focused on what you do with it. So the internet is kind of there. Most people have no idea the complexities of underwater sea cables. It's beyond one or two people or even one or two companies to comprehend. You're at the point now where most people that jump on the internet are talking about what you do with the internet. You can have Netflix. You can do meetings like this one. It's about what you do with it. So that's going to be interesting. And we're just not there yet with tech. Tech is so, or infrastructure stuff. We're so in the weeds that most people, you know almost burn out with just getting to the point where you can start to look at what you do with this stuff. So that's what I keep in my eye on is when do we get to the point when people just ship things and build things, right? And I think the closest I've seen so far is the mobile space. If you're iOS developer, Android developer you use the SDK that they give you. Every year there's some new device that enables some new things, speech to text, VR, AR, and you import an SDK and it just worked. And you can put it in one place and a hundred million people can download it at the same time with no DevOps team. That's amazing. When can we do that for server-side applications? That's going to be something I'm going to find really innovative. Excellent. Yeah, I mean, I could definitely relate. I was Hortonworks in 2011, right? So Hadoop in many respects was sort of the precursor to the Kubernetes area in that, you know it was as I like to refer to it was, you know it was a bunch of animals in the zoo wasn't just the yellow elephant, right? And when things matured beyond it's basically talking about what kind of analytics they're driving what type of machine learning algorithms and applications are they delivering? You know, that's when things tip over into a real solution space. So I definitely see that I think the other cool thing even just outside of the container and, you know container spaces, there's just such a wealth of data of related services. And I think how those two worlds come together you brought up the fact that in many respects serverless is great at stateless but there's just a ton of stateful patterns out there that I think also need to be addressed as these richer applications. So we're from a data processing and actionable insights perspective. I want to be also want to be clear on one thing. So some people confuse two things here but Michelle said earlier about for the first time a whole group of people get to learn about distributed systems and things that were reserved to white papers, PhDs CS that this stuff is now super accessible. You go to the CNCF site like all the things that you read about or we used to read about you can actually download see how let's implement it and actually change how it works. That is something we should never say is a waste of time. Learning is always good because someone has to build these type of systems and whether they sell it under the guise of serverless or not, this will always be important. Now that the other side of this is that there are people who are not looking to learn that stuff, like the majority of the world isn't looking and in parallel, we should also make this accessible. We should enable people that don't need to learn all of that before they can be productive. So that's like two sides of the argument that can be true at the same time. A lot of people get caught up and everything should just be serverless and everyone learning about distributed systems and contributing and collaborating is wasting time. Where we can't have a world where there's only one or two companies providing all infrastructure for everyone else and then it's a black box. We don't need that. So we need to do both of these things in parallel. So I just want to make sure I'm clear that it's not one of these or the other. Yeah, makes sense, makes sense. So we'll just hit the final topic, Chris. I think I'll ask you to help close this out. COVID-19 clearly has changed how people work and collaborate, I figured we'd sort of end one. How do you see, so DockerCon is going to a virtual event. Inherently, the open source community is distributed and is used to sort of not face to face collaboration but there's a lot of value that comes together by assembling a tent where people can meet. What's the best way, how do you see things playing out? What's the best way for this to evolve in the face of the new normal? I think in the short term, you're definitely going to see a lot of virtual events propping up all over the place in different themes, verticals. I've already attended a handful of virtual events the last few weeks from Red Hat Summit, Open Compute, Summit to Cloud Native Summit. You'll see more and more of these. I think in the long term, once the world either gets past COVID, there's a vaccine or something. I think the innate nature for people to want to get together and meet face to face and deal with all those serendipitous activities you would see in a conference will come back but I think virtual events will augment these things in the short term. One benefit we've seen like you mentioned before, DockerCon can have 50,000 people at it. I don't remember what the last physical DockerCon had but that's definitely an order of magnitude more. So being able to do these virtual events to augment potential physical events in the future so you can build a more inclusive community so people who cannot travel to your event or weren't lucky enough to win a scholarship could still somehow interact during the course of the event to me is awesome and I hope something that we kind of take away when we start all doing these virtual events when we get back to kind of physical events, we find a way to kind of ensure that these things are inclusive for everyone and not just folks that can kind of physically make it there. So those are my thoughts on the topic and wish you the best of luck planning DockerCon and so on. So I'm kind of excited to see how it turns out. 50,000 is a lot of people and that just terrifies me from a CloudNativeCon coupon point of view because we'll probably be somewhere. Yeah, we'll get ready. Excellent. All right, so that is a wrap on the DockerCon 2020 open source power panel. I think we covered a ton of ground. I'd like to thank Chris, Kelsey and Michelle for sharing their perspectives on this continuing wave of Docker and CloudNative innovation. I'd like to thank the DockerCon attendees for tuning in and I hope everybody enjoys the rest of the conference. Thank you.