>> (Narrator) Live from Vancouver, Canada, it's The Cube, covering OpenStack Summit North America 2018, brought to you by Red Hat, the OpenStack Foundation, and its Ecosystem partners. >> Welcome back, I'm Stu Miniman with my co-host John Troyer and you're watching The Cube, worldwide leader in tech coverage, and this is OpenStack Summit 2018 in Vancouver. Happy to welcome to the program, first-time guest Melvin Hillsman, who's the governance board member of OpenLab, which we got to hear about in the keynote on Monday. Thanks so much for joining us. >> Thanks for having me. >> Alright, so Melvin, we were given, start us off with a little bit about your background, what brought you to the OpenStack community, and we'll go from there. >> Sure, yeah, so my background is in Linux system administration and my getting involved in OpenStack was more or less seeing the writing on the wall as it relates to virtualization and wanting to get an early start in understanding how things would pan out over the course of some years. So I probably started OpenStack maybe three or four so years ago. I was probably later to the party than I wanted to be, but through that process, started working at Rackspace first and that's how I really got more involved into OpenStack in particular. >> Yeah, you made a comment, though. The writing on the wall for virtualization. Explained that for a sec. >> So for me, I was at a shared hosting company and we weren't virtualizin' anything. We were using traditional servers, dedicated servers, installing hundreds of customers on those servers. And so, at one point, what we started doing was we would take a dedicated server, we would create a virtual machine on it, but we would use most of the resources of that dedicated server, and so what allowed that shared hosting was to tear stuff down and recreate it, but it was very manual process and so, of course, the infrastructure service and orchestration around that OpenStack was becoming the de facto standard and way of doing it, and so I didn't want to try to learn manually, or fix something up internally, I wanted to go where OpenStack was being highly developed a lot and people working on it in their day to day jobs, which is why I went to Rackspace. >> Okay, one of the things we look at, this is a community here, so it takes people from lots of different backgrounds, and some of them do it on their spare time, some of them are paid by larger companies to participate, so to tell us about OpenLab, itself, and how your company participates there. >> Sure, so I started, well I'm at Huawei now, but I was at Rackspace and that's kind of how I got more involved in the community and there I started working on testing things above the OpenStack ecosystem, so things that people want to build on top of OpenStack and during that process Huawei reached out to me and was like hey you know you're doing a great job here, and I was like yeah I would love to come and explore more of how we can increase this activity in the community at large. And so Oakland Lab was essentially born out of that, which the OpenStack community, they deliver the OpenStack API's, and they kind of stop there, you know. Everything above that is, you do that on your own, more or less, and so also, as a chair of the user committee, again, just being more concerned about the people who are using stuff, OpenLab was able, was available to facilitate me having access to hardware and access to people who are using things outside OverStack in use cases, et cetera, where we want to test out more integrated tools working with OpenStack and different versions of OpenStack. And so that's essentially what OpenLab is-- >> So in OpenLab, projects come together and it's basically, it's an Interop, boy, in the networking world, they've had the Interop plug and plug fest for a long time, but, in essence, projects come together and you integrate them and start, you invite them in and they integrate and start to test them. Starting with, I mean, I see, for this release, Terraform and Kubernetes. >> Yeah, so a lot of people want to to use Kubernetes, right? And as an OpenStack operator you essentially, you don't really want to go and learn all the bits of Kubernetes, necessarily, and so, but you want to use Kubernetes and you want to work seamlessly with OpenStack and you want to use the API's that you're used to using with OpenStack and so we work very heavily on the external cloud provider for OpenStack, enabling Cinder V3 for containers that you're spinning up in Kubernetes, so that they have seamless integration, you don't have to try to attach your volumes, they are automatically attached. You don't have to figure out what your load balancing is going to to look like. You use Octavia, which is load balancing service for OpenStack, very tightly integrated and things, you know, as you spin things up, they work as you as you would expect and so then all the other legacy applications and all the things you're used to doing with OpenStack, you bring on Kubernetes and you essentially do things the way you've been doing them before, with just an additional layer. >> Yeah, now I wonder if you can talk a little bit about the providers and the users, you know how do they get engaged, to and give us a little flavor around those. >> Yeah, so you get engaged, you go to OpenLabtesting.org and there's two options. One, is you can test out your applications and tools, by clicking get started, you fill that out. And what's great about open lab is that we actually reach out and we talk with you, we consult with you, per se, because we have a lot of variation in hardware that's available to us and so we want to figure out the right hardware that you need in order to do the tests that you want, so that we can get the output as it relates to that integration that will, of course, educate and inform the community at large of whether or not it's working and been validated. And, again, so as a person who wants to support OpenLab or for a provider, for example, who wants to support OpenLab, you click on the support OpenLab link, you fill out a form and you tell us you know, do you want to provide more infrastructure, do you want to talk with us about how clouds are being architected, integrations are being architected, things that you're seeing in the open source use cases that may not be getting the testing that they need and you're willing to work with engineers from other companies around that, so individual testers and then companies who may bring a number of testers together around a particular use case. >> Now, you're starting to publish some of the results of Interop testing and things like that. How is open lab, how does it produce its results, is it eventually going to be producing white papers and things like that or dashboards or what's your vision there? >> Yeah, so we produce a very archaic dashboard right now, but we're working with the CNCF to, if you go to CNCF.CI, and they have a very nice dashboard that kind of shows you a number of projects and whether or not they work together. And so it's open source, so what we want to do is work with that team to figure out how do we change the logos and the git repos, to how to driving those red and green, success or failure icons that are there, but they're relevant to the test that we're doing in OpenLab, so yeah. So we definitely want to have a dashboard that's very easy to decipher what tests are failing in or passing. >> Looking forward, what kinds of projects are you most interested in getting involved? >> Right now, very much Kubernetes, of course. We're really focusing on multi architecture, again, as a result of our work with Kubernetes and driving full conformance and multi architecture. That's kind of the wheelhouse at this time. We're open for folks to give us a lot of different use cases, like we were starting to look at some edge stuff, how can we participate there, we're starting looking at FPGA's and GPU's, so a lot different, we don't have a full integration in a lot of different areas, just yet, but we are having those conversations. >> So, actually, I spent a bunch of years, when I worked on the vendor side, living in an Interrupt lab, and the most valuable things were not figuring out what worked, but what broke, so what kind of things, you know, as you're working through this, what learnings back do you share with the community, both the providers and users? Big stumbling blocks that you can help people, give a red flag, or say you know, avoid these type of things. >> Yeah, exactly what you just said. You know, what's good is some of our stuff is geographically dispersed, so we can start to talk about if, what's the latency look like? You may, within that few square miles that you're operating and doing things, it works great, but when I'm sending something across the water how, is your product still moving quickly, is the latency too bad that we can't, I can't create a container over here because it takes too long, so one example of looking at something fail as it relates to that is we're talking with Octavia folks to see, if I spin up a lot of containers am I going to therefore create a lot of load balancers and if I create a lot of load balancers I'm creating a lot of VM's, or am I creating a lot of containers or are things breaking apart, so we need to dig a little bit further to understand what is and is not working with the integrations we're currently working on and then again we're exploring GPV, GPUs just landed more or less, that was a part of the keynote as well, and so now we're talking about, well, let's do some of that testing. The software, the code, is there but is it usable? And so that's one area we want to start playing around with. >> Okay, one of the other things in the keynote's got mentioned was Zul, the CIDT tool, how's that fitting into the OpenLab? >> Yeah, we use Zul as our gating, so what's great about Zul is that you can interac6t with projects from different SCM's, so we have some projects that live in github, some that utilize Garrote, some that utilize gitlab, and Zul has applicability where it can talk to different, it can talk across these different SCM's, and if you have a patch that depends on a patch in another another pod, so a patch on one project in one SCM can depend on a patch in another project, in a different SCM, and so what's great about Zul is that you can say, hey I'm depending on th6at, so before this patch lands, check to make sure this stuff works over there, so if it succeeds there and it's a dependency then you basically confirm that succeeds there and then now I can run the test here, and it passes here as well, so you know that you can use both of those projects together again, in an integration. Does it makes sense? Hopefully I'm making it very clear, the power there with the cross SCM integration. >> Yeah, Melvin, you've had a busy week, here, at the show. Any, you know, interesting things you learned this week or something that you heard from a customer that you thought, oh boy we got to, you know, get this into our lab or a road map or, you know-- >> The ARM story, the multi architecture is, I feel like that's really taking off. We've had discussions with quite a few folks around that, so yeah, that for me, that's the next thing that I think we're really going to concentrate a little bit harder on is, again, figuring out if there are some problems, because mostly it's been just x86, but we need to start exploring what's breaking as we add more to multi architecture. >> Melvin, no shortage of new things to test and play with, and every customer always brings some unique spins on things, so appreciate you giving us the update on OpenLab, thanks so much for joining us. >> You're Welcome. Thanks for having me. >> From John Troyer, I'm Stu Miniman, thanks so much for watching The Cube. (electronic music)

>> Announcer: Live from Vancouver, Canada, its theCUBE! Covering OpenStack Summit North America 2018. Brought to you by Red Hat, the OpenStack foundation, and its ecosystem partners. >> Welcome back, I'm Stu Miniman, and you're watching theCUBE's live coverage of OpenStack Summit 2018, in Vancouver. My co-host John Troyer is here, happy to welcome back to the program, Mark Baker who's a Product Manager with Canonical. Mark, how's the show treating you so far? >> Show's been going very well. So, we've seen people coming to us on the show floor, coming to the sessions. We're seeing really interesting building, scalable production Clouds, and so and coupling that with all the container technologies and a lot of other complimentary technology by machine-learning. So, a lot of the discussion is, can we build Cloud? But also, much more about the workloads and the kind of integration with, parallel if you like, or adjoining technologies. >> Great, want to talk about the customers really, Mark. So as you said, you've been to a few of these shows, we've been to a few of these also and, the makeup of the attendees has changed a bit, one of the things I heard, it is 2X the number of Cloud architects, with their title, compared just to last year, little bit of a broadening into the scope, what do you hear from customers, what brings them here, what's exciting them, in this environment? >> So, I mean yes certainly Cloud architects, and at Canonical we regularly talk to Cloud architects, because architecture with the Cloud is something that evolves, it's not something that's pinned. As workloads evolve, and new technologies come along you need to be able to evolve that architecture, and therefore people that understand that are important. I think it's also noticeable, I'm sat here wearing my blazer, is there's noticeable seeing quite a few people round the show, wearing blazers. So, you go back a couple years ago, or even a year or so ago, it was very much a sort of developer centric type of event. We're seeing more business conversations now, and even discussing things such as money, and economics, which weren't necessarily conversations that we were going too heavily in a couple of years ago. >> There's still a bunch of the hoodies set here, lots of cool T-shirts and, yeah, ironic facial hair and the like, so, maybe from your standpoint at Canonical, talk a little bit about those constituencies of who to sell with. We've got the operators, you've got the developers, you've got the C suite, I'm sure the answer is yes, but who you find yourself maybe, help walk us through some of those roles that you're talking to, some of the biggest concerns they're having and how you're helping them. >> So in most enterprises that we go and talk to we're typically talking to, initially operations, because they know that they need to be able to ride services to, Cloud services, and container services, to their customers internally, or within the business, and they're looking at okay how can we operate this, how can we secure it, how can we scale it, in smart ways, they're looking for our help and assistance doing that. Very soon after that we'll need to go and talk to developers, or engage line of business developers, primarily because we need to, this represents change to them, moving into a Cloud or, moving their applications to containers represents change, and we want to get them onboarded into this environment and to start to begin that change as quickly as possible. The Cloud, to succeed, it needs to have many running workloads on it, and so engaging with the developers, to take advantage of the capabilities the platform can provide is really important. We'd love to be able to go and talk to at that sea level, and we are starting to have more of those conversations, but I think the type of infrastructure, the OpenStack and container technologies provides, it's the initial interest is very much coming from those operators, from the architects, and from the developers. >> Well lets talk about operators for a minute, I mean, once upon a time there was a tribe of people called sisbits, they were kind of surly, and they took care of things like Linux, right, and now, out of that Linux framework, there's a huge set of technologies, that have grown all based on Linux, on all that Canonical works with, and there's a new set of skills required. Can you talk a little bit about what the new operator needs to know, and how you can help train people and Canonical help train people that you're assistant men working with Linux, what different things do I need to care about now in the Cloud management world, Cloud operator world? >> Yeah sure so, you're right, it used to be relatively simple, and you would run a VM or you'd run an application on top of bare metal and, there'd be certain things you'd need to be able to tweak to scale it and up the performance, but, we're running an, as we say, more agile infrastructure, so whether it's Cloud or containers or combinations of both, there are very many different variables, and how an application's able to take advantage of the storage or the capabilities that a platform provides, there's many different nobs and dials that you can turn. We tend to be advising right now, people on bringing in services such as CICD, Continuous Integration Continuous Deployment, so that they can start to adopt some of these newer ways of working. Operators now need to, they need to be much more aware of okay, what the workload characteristics are, and how that might behave on a hyper vise, or how it might behave within a containerized environment. I just came out of a conversation with a customer for example, who was asking detailed questions about storage performance, right? They have applications that require certain levels of storage performance and different types of storage that we can bring to bare, in conjunction with an OpenStack, which is going to be the appropriate one, and how do they segment them and so, it's definitely become more complex, but I think, through collaboration events like this, we're actually getting much better at being able to provide them with the information and the choices they need to make. >> Mark, speak to us a little bit about the community. OpenStack started heavy users in the community, contributed the community, how do you see that dynamic playing out today? >> Well there's still lots of contribution coming into OpenStack, and that's good to see. We are starting to see, as OpenStack has matured, as the market place has matured, some of the focus no longer being purely on contributing code, but now sharing experiences around operations, and that's starting to move into this area of people use this phrase, "Infrastructure as code", to be able to access infrastructure programmatically. I think we're seeing collaboration now in the OpenStack community and adjacent communities around collaborating on the operations, especially when those operations themselves are encapsulated in code. So, very simple thing, sounds simple, not necessarily easy to do but, being able to upgrade, update and place, how you would sort of suspend the system whilst you perform some maintenance and evacuating the workloads and bring them back in and those kinds of very common tasks for Cloud operators. We saw, even just a few years ago, how operators would each have their own way of doing it, their own preferred methods, and this was generally not so efficient so, collaborating on those and sharing best practices is one of the really interesting things to see within this community today. >> John: Sure, sure, I mean you, I think the evolution goes, everybody then starts to write scripts, which you all write scripts in your own way, and eventually you have to come up with a framework. And you all have developed a couple different frameworks in terms of installation and upgrades and things like that. >> Absolutely, and one of the things that once the customer start to understand that we've developed a framework around operations, those operations are encapsulated within code, and it means that if we have a customer, dodgy telecom, for example one of our customers that is understandably very security conscious, 'cause they run the telco network, has best practices around the security of their Cloud, and we're able, when they start to make recommendations or updates to that, we're able to take those and share them with a broad audience, and get that sort of collaborative spirit around what's the best way to be able to do this. >> So, you mentioned security there, any other kind of key pinpoints, what are you hearing out in the market place, is GDPR something that a lot of your customers are beaten on you and, what's the Canonical decision there? >> Yeah, absolutely, so, GDPR has been a real catalyst for people to look at areas for security that they probably meant to get round to at some point but never had, so. >> Some people said it's the Y2K of this generation >> Yes, exactly, definitely a forcing function. And so one of the areas we've seen a lot of activity around and solely we've committed resources to it within the last couple of months has been around encryption of data at rest. So, obviously in the Cloud, you're going to have a lot of data that's there with the relevant workloads, and some of that regulations in GDPR regulation is about what happens if somebody removes a disk from the server, does that mean that they have access to the data? As we start looking at things such as Edge Cloud, so very many Clouds close to the customer or close to the edge, which don't necessarily have the same data center infrastructure around them, how do we secure the data there, right? So, encryption of data, but doing it in a way that doesn't require to manually typed passwords in to be able to access them all of the time, is not a simple problem and, we've spent quite a few resources, working out how do we address that, how can we do it in a way that's going to allow it to be dealt with economically, and scalably. >> There's been a lot of talk about open infrastructure in general here at the show, and OpenStack obviously is designed to manage infrastructure, but we've already talked about containers here, with you in this segment, there's a lot of container news, Kubernetes news, OpenDev Summit going on at the same time, so how do you as a Product Manager, you can't just be worried about one part of the stack, how do you and your team worry about that integration and that unified platform and bring together these interactions will all these different OpenSource projects? >> Oh yes, for sure, and that's, it certainly is one of the things Canonical has been cognoscente on and focusing on, or working on for quite a long time is a Linux distribution at it's heart is really the integration of very many different components, from a kernel, and libraries, and pilots and all the various other pieces that go with that. So, understanding how these components plug together, whether it's OpenStack, with containers, and open V switch for the networking, and set for storage for example, that's very much part of what we've been doing. We're learning with customers as we go, very much, that how they want to plug these things together with Kubernetes, Kubernetes running alongside OpenStack, Kubernetes running on top of OpenStack, OpenStack even running on Kubernetes, some of them are looking at, so understanding how they, people want to be able to plug technologies together, and we'd standardized very much on sort of reference architectures of combination of OpenStack plus Kubernetes as a really simple example, but then as part of our QA process, testing process, all this reference architectures that we build with hardware partners and other partners too, is ensuring that we're able to deliver that as a stand-alone product as required, but also as effectively solutions together, that are fully integrated, fully supportable and they're going to deliver the capability that the customer needs. >> First of all, the OpenStack on top of Kubernetes, really? Is that something you'd recommend to customers or? Or is it a specific use case for that? >> It's not something that we recommend today. So, there's been certainly a lot of discussion in the OpenStack community around the control plane, and what's the best way to deliver the control plane. Canonical made a very strategic or specific choice several years ago that actually, containerizing the services is the right way to do this, so we containerized basically all of the control plane services apart from Neutron Gateway which would be a little tricky to do that but, so we containerized all of those services, and it gives us flexibility when we want to perform updates and migrate services between different systems, for example. How do you manage those containerized services though? There's lots of diversity of opinion. Some people want to be able to do that with Kubernetes, and that's great, then we certainly track those efforts and work with those people, if they're using a (mumbles) or some of our technologies, but I think, it's still yet to be decided, what's the best way to be able to do that. >> So you must, you have an interest in Java as a Product Manager, you always want to productize in general, standardize as much as possible, in the needs communities you have the diversity of opinions, oh I'll take this piece, I'll get rid of the core, I'll do something over here, I'll flip it upside down, how do you balance that, giving customers choice, but making sure you can deliver solid offerings that you can support? >> And so, that's very much it. It's a choice and we can say, look, we can deliver a robust, high performing Cloud, with these reference architectures, we've learned that through experience with customers, and working with our partners. We understand that customers all believe they're special and they all have their own special requirements, often with good valid reason, so, but we'll always try and start from a base, and then say let's start to iterate through that, adding in additional capabilities or, maybe tweaking something for your particular use case if you do that, and see how it impacts the Cloud. Because, for us to be successful, us, the OpenStack community to be successful, we need to ensure that those Clouds can live and breathe and evolve over time, and if they're making too many or too heavy customization of that Cloud, then it can start to impact their ability to do that. So, it's, we'll offer that choice. >> Speaking a little bit on the line of standardized services, I'm really intrigued by managed OpenStack, from Canonical. Can you talk a little about what customers it's right for, and when it comes into the conversation and then where in the lifecycle, 'cause I guess then it can also eventually go as as the control container back over to the customers when they don't, when they're finished with managed. >> Absolutely, so we started providing what we call boot stack, as fully managed OpenStack service, primarily to address the skills gap within the OpenStack community. So, we saw a lot of companies interested in deploying OpenStack, a lot of enterprises looking for OpenStack, but they couldn't find the talent, or the people with the experience of deploying a managing OverStack. Just, there weren't the people around, right? Hiring was hard. So, and that was becoming a blocker for us to be able to deliver Clouds to those customers, so we started to offer a managed service, we had a lot of the reference architectures and best practices pretty well nailed down, but it was a facilitator for them to get up and running with the Cloud and there's a point where they, that they became comfortable operating it, managing themselves, hand control back. We've seen, that is a very popular model, and that period where they're having us manage it, can be six months or 12 months or 18 months, but the customers know that they have the reassurance that they can take it back, control and house, they can operate it themselves, and they can manage their own environment, they become self sufficient, but they're not doing that from day one. We're holding their hand, and taking them along that path. So, that's been a very popular offer. >> Mark Baker, really appreciate you giving us an update on really the broad spectrum of customer use cases and all the updates from Canonical. For John Troyer, I'm Stu Miniman. Back with more coverage here from the OpenStack Summit 2018, in Vancouver. Thanks for watching theCUBE. (electronic music)

>> Narrator: Live from Austin, Texas, it's theCUBE, covering KubeCon and CloudNativeCon 2017, brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Okay, welcome back, everyone. This is theCUBE's exclusive coverage live here in Austin, Texas for the CNCF's two conferences, CloudNativeCon, which was yesterday, and two days, today and tomorrow, KubeCon for Kubernetes' conference. This is theCUBE, of course, from SiliconANGLE Media. I'm John Furrier with my cohost, Stu Miniman. Our next guest, Dan Kohn, is the executive director of the CNCF, the man who put it all together. Congratulations. Welcome back to theCUBE. Good to see you. >> Oh, absolutely. Thrilled to have you guys back here again. >> So you kind of doing a victory lap here now, high fiving each other? >> Dan: Great hugs. >> John: Great event. >> Laughing: I'm glad it's a good event, and I am hearing fantastic feedback that folks are thrilled to be here. But we sort of describe this moment for the organization and the community as being the end of the beginning. >> John: Yeah. >> Where we now have all the major cloud vendors, all of the biggest enterprise software companies. We have a core group of 14 projects anchored by Kubernetes, but tons and tons of work in front of us. >> And tons of success, so I'm just going to read a couple of highlights from yesterday. There's a lot today. Baidu joins the CNCF, a lot of scaling production application examples, 31 new silver end-user members joined, Alibaba Cloud update to platinum, CoreDNS 1.0, Containerd, Fluentd, Jaeger, tons of news. Obviously, we've been pumping out the coverage. Today, again, more and more great goodness. But really interesting is that you guys have put a frame around this community to allow it to grow, to fertilize the open source vibe, which is all cloud but yet scaled. And you put up a slide I want to get your reaction to that I thought was compelling yesterday during your keynote. It was the flywheel, circle, and it said projects, products, profit. >> Dan: Right. >> And not that you're promoting profit, but you're not hiding the ball, either, saying, hey, you know what? There's a lot of commercial interest in cloud, obviously. We saw AWS' success last week. And that is if you create good products in this community framework, there's profit to be had. >> Right. So first of all, I should admit to plagiarizing that slide from Linux Foundation Executive Director Jim Zemlin. >> And similarly, I think you can look at a lot of aspects... >> It's an open source feature. >> Dan: Yes. >> Free for you to use. >> John: Right. >> Similarly, I think there's a lot of ways in which Kubernetes is trying to build on the success of Linux. And Jim even describes Kubernetes as the Linux of the cloud. >> John: Yeah. >> Stu: Yeah. >> John: That's a good point. >> Dan, one of the things we've been talking around Kubernetes is you talk about scale. >> Dan: Right. >> Talk about scale of the CNCF. You have 4 to 14 projects. People are a little worried when you get all the vendors around here and there's all these projects. It's a foundation thing, it's going to go off the rails. >> Dan: Yeah. >> Customers aren't going to have a voice. How do we make sure we kind of learn from some of the things that other projects have had challenges with in the past? >> And I think that's our advantage, which is the great thing about coming later than some of the other foundations, is we can look at where they had successes and where they had issues. And our aspiration for CNCF is to get to go make entirely new mistakes rather than replicating some of the issues that have come before. And so really from the beginning of CNCF, we had a somewhat unusual and frankly a little bit cumbersome charter where I describe it at times as a three-ring circus. We have a governing board made up of the vendors that are putting a lot of money into the community, but they don't get to run the projects and they don't even get to pick the projects. Instead, they appoint six of the nine members of an independent technical oversight committee, kind of like the Supreme Court. And then we have a third group in the end-user community that I'm thrilled to say is now up to 28 members in it. They appoint one of those folks. We finally got that working. We have Sam Lambert, the director of infrastructure at GitHub, who has just made a huge commitment to Kubernetes and is moving all their infrastructure over into it. Those seven appoint the last two. And so that body, and they just had their public meeting a couple hours ago. They feel very strongly about their independence, about their reputation, that they're trying to make very good judgments based on what they're seeing in the marketplace. >> That's interesting, the three-ring circle. I like how you put it. But let's talk about the end-user piece because I think that's critical. One of the things we were commenting earlier from the Lyft folks was you have a lot of end users who have built some large-scale systems out of their own sheer necessity. >> Dan: Definitely. >> And that is now being donated in. We saw Kubernetes come in with, you shepherded beautifully, went from Google, but you've got Lyft donating an amazing product convoy. >> This first convoy has a huge amount of excitement. And what was fun was, actually, on the same stage that they contributed back in LA in September, Uber contributed a separate project. Now, unlike Uber and Lyft, the two projects are in no way competitive- >> John: Yeah. >> Like Jaeger is really fantastic tracing one. But what they have in common is that they're companies that have had to grow from nothing to extremely high scale and then had problems that they solved. And they wanted to share that expertise with us. >> I want to get your thoughts on this. Because we've been speculating, on theCUBE, we've been kind of thinking, an editorial, but just that this is all good business. Now, that's pretty obvious, right? You're starting to see this kind of contribution, the gifts that keep on giving. These are significant code. >> Dan: Yeah. >> Not like, okay, let's start a little group and huddle and build something organically. You have real goodness coming in from Google, Uber, Lyft, and there's a million others. >> Dan: Right. >> How is that changing the game? Certainly accelerating it. That's really bringing goods to the table. >> Right. I think the whole... >> You have to manage it. >> Well, and for what it's worth, I don't actually manage the projects. And so we do provide a set of services- >> John: The community? >> -to them and we help them, we market them. But one of the unusual aspects of CNCF is that the projects do actually manage themselves. A little bit of guidance from the TOC, but we really are unusual in that sense. And that's one of the reasons the projects have been... >> And what's interesting is, to connect the dots, though, one step further, you're talking about a commercial entity donating massive intellectual property in the open for all the goodness of everyone else. But yet that flywheel is continuing. They're still using it. So it is inherently commercial dynamic. >> Right. And back to that circle, I think really the underlying concept is that companies agree that sharing key parts of their infrastructure has a huge amount of value to the whole ecosystem, to each other. And then they're absolutely eager to compete above that. And so you can look at it with the public clouds where we have now Amazon, Microsoft, Google, Alibaba, IBM, Oracle all at the table. They are absolutely fierce competitors. But they're saying that this specific software infrastructure layer isn't the area that they want to compete. They want to compete on all the value-added services, customer service, et cetera. >> Dan, I wonder if you can speak to how CNCF connects to some of the broader communities out there. Things like Kata containers got announced coming out of the OpenStack group. You've got a serverless track happening here, kind of extends some of where Kubernetes is going. How does CNCF fit into the broader... >> Sure. And it's definitely the case that all the innovation out there cannot happen in CNCF. Most obviously, everything that we do, almost everything depends on Linux. And so that's our parent organization, the Linux Foundation. But we've had a good collaboration with Jonathan Bryce from OverStack. They have two booths on the floor here at the show. And we've spoken to Clear Containers and RunV, the two predecessors in the past. But the part that I'm particularly pleased with for Kata containers is that it is an OCI-compliant runtime, that's another sister organization, and is really designed to work well for Kubernetes. And then they can pitch that and let the market go decide which container runtimes they find the most valuable. >> Obviously a lot of traction here in terms of the sentiment around service meshes and pluggable lock-in textures. That's been very cool. But security came up. So I want to get your thoughts around security, obviously storage and these older models around how to deal with storage and networking. Obviously, always in the action. >> Yeah. >> But security is top of mind for everyone. How is that being addressed? You know, talk is out there... >> Sure. I mean our philosophy on this is that moving to cloud-native and particularly the continuous integration and continuous development that goes along with that is the most important step that you can do to help secure your infrastructure. And Equifax is the example everyone always brings up. But there was a case where they were using known insecure software and they didn't have the processes up to place where instead of doing quarterly updates or monthly updates, you want to be doing dozens of updates per day. And a cloud-native infrastructure allows you to do that. >> What's next for you? Because you've got great traction with both community response, and the community has been absolutely amazing, the quality of people, level has been great, but also at the funding sponsors. You've got a lot of people that are involved. What's next? What happens next? What do you envision happening? What's the plan, and then how do you view that evolving? >> Well, I hate to fall into the buzzword implosion here, but if you go back to the crossing the chasm metaphor, I think we're still very much just in the early adopter phase. 2018 could very well be the moment that we jump over to the early majority. And I do feel like this whole community now has the velocity to do that and that we're on track for it. But as that happens, there's just far, far more people who need to be educated so they understand the projects and the options and how to work with them. And then hopefully they go from just being consumers of these technologies to contributors and that we can welcome them into our community and hopefully get the advantage of their expertise as well. >> I want to get your thoughts on a comment that Stu and I were talking about. Stu, you and I were talking about the notion of value creation above the stack, and then how Kubernetes, although some could say being commoditized, but it's also creating value because with that consistency of Kubernetes, you can now create value. So we believe, and I want to get your reaction to this, because we think a whole new ecosystem dynamic will emerge of a new kind of ecosystem. And if this new app developer combined with software engineering, which is really going on, you're talking about the cloud, the app developers will just build in value, that value creation will be rewarded. That's where monetization will be happening. >> And if I could build off that... >> John: Yeah. >> Dan, I loved one of your opening comments. You quoted, "exciting times for boring infrastructure, "maybe too exciting." So this week we've been teasing out there's a lot of work to make that infrastructure boring. You've got everybody on this floor, the CNCF board, lots of new projects making that. Where the action is and what this is going to create is that application monetization and the speed and agility of being able to create these cool new cloud-native applications out there. So it's interesting dynamic, spans broad pieces of this, layers of the stack there. >> Yeah. Well, I will point out that there was an odd level of unanimity of just a ton of different leaders in the community, in keynotes from Craig McLuckie and Chen Goldberg and others where they all agree that Kubernetes is not by any means the ultimate answer or the final answer. I think everybody now expects to see Kubernetes as a core aspect of the infrastructure for software for the next decade or more. But there's a belief that there's a whole ton of value that needs to be added above it, particularly to try and show for a regular application developer who just has a PHP app or no-GS microservices or anything else what's the easiest way to go from having a piece of software and deploying it effectively. >> Dan, so it's interesting. You watch the people on the outside. They're like, oh, look at Kubernetes. They're all holding hands and saying Kumbaya. We know there's some spirited debates that happen- >> Dan: Definitely. >> In the code, some projects that are sometimes competing up there. Why has the community come together, and where are some of the areas that we still need to work on and improve to help customers going forward? >> And again, I think they have the big advantage of having watched other communities that didn't value community and consensus and the ability to work through their issues. And so thankfully, we just have a ton of really capable engineers who also have some of those social or personal qualities that they care about working these things out. And to date, at least, I think most of those disagreements have been settled pretty amicably and in a positive direction. I think there's still huge swathes of this space that are still up in the air. Storage is an obvious one where there's a ton of work going on in a storage working group of CNCF. Serverless is another where I think everyone agrees that the application deployment model of AWS Lambda is really exciting and has things that people should replicate and should be brought over to Kubernetes. But how that should happen, what the software is, et cetera, there's still, in fact, we have our first serverless track today here at KubeCon where several different competing approaches are all talking about what they'd like to do. >> Awesome stuff. And you also announced some dates for next year, December 11 and 13 in Seattle. >> Dan: Yes. >> Okay. >> Dan: That's a year from now. >> November 14 and 15 in Shanghai. >> Now, you and I met in Hangzhou in the lobby, which was just amazing. But I certainly am hoping to convince you to go back to China with us. This will be our first event... >> I got a three-year visa. >> Good, yeah, that's the exactly right one. But this will be our first event in China, which I think is just a huge opportunity. We now have Baidu, Tencent, Huawai, ZTE, a number of startups. There's just so much excitement for this space over there that we're really excited to satisfy. >> Stu: And Copenhagen in May. >> And that's the last one. Thank you. May 2 to 4 in Copenhagen, and we're really excited for the event, to bring it to Europe and the rest of the world. >> Okay. So you've been working like a dog, you've been working hard. I've seen you in China. It's serendipitous. But it's not without being mentioned that this has been great effort by your team and the Linux Foundation and Jim and the whole team. But congratulations. Are you having a pinch me moment? I know it's too early to do a victory lap. >> But you've got to be pretty excited. >> Yeah. It really has been a great thing for the foundation that we sort of accomplished many of our 2018 and 2019 goals this year. But I'm sure we're going to find plenty of stuff to do next year. >> And your goal for the next 6 to 12 months, what's on your top three to-do's, continue the momentum? Share your API for... >> Yeah. What's great is that we really have plenty of members. We'd always like to add new ones and serve the ones we have better. But right now, the focus is really about providing better services to our projects. All of them feel overworked. They would love help on documentation, on marketing, on messaging about it, and some of them need help with testing development and other things. So that's really what we're buckling down on. >> Great community are going to test them, being here on the ground, personally present at creation. And I was standing there with J.J. and Lew Tucker, OpenStack three years ago, talking about Kubernetes. We were kind of ripping. We couldn't have imagined, then, obviously, they bolted it on last year with your event. Now second year here, huge community... >> But you have 4,100 folks here, is more than the previous four events combined. >> Yeah, awesome. >> So it really is exciting. >> TheCUBE, always on the ground. And sometimes the squirrel finds a nut. We found a cloud-native foundation, part of the Linux Foundation. CNCF, Cloud-Native Compute Foundation, really a new, growing, and relevant community for cloud and a new way to do software and reimagine the future from software engineering to full application development, a new way. This is theCUBE's coverage, and we are here live in Austin. More live coverage after this short break. We'll be right back. [Techno Music]