>> Live from Barcelona, Spain, it's theCUBE. Covering KubeCon, CloudNativeCon, Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation and Ecosystem Partners. >> Welcome back to theCUBE here in Barcelona, Spain. This is KubeCon, CloudNativeCon 2019. I'm Stu Miniman, my co-host for two days of wall-to-wall coverage is Corey Quinn. Joining us on the program we have two gentleman from Red Hat. To my right is Josh Berkas who's the Kubernetes community manager and sitting to his right is Dejan Bosanac who's a senior software engineer and as I said, both with Red Hat. Gentlemen, thanks so much for joining us. >> Well thank you. >> Thank you. >> All right. So Josh, a community manager in the Kubernetes space, so what brings you here to KubeCon and maybe explain to us and give the clarification on the shirt so that we can be educated to properly call this city and residence by, how they should be. >> Oh, so many things, so. I mean obviously, I'm here because the community is here, right? A very large community. We had a contributor summit on Monday. They had a couple hundred people, three hundred people at it. The important thing, when we talk about community in Kubernetes there's the general ecosystem community and then there's the contributor community. >> Right. >> And the latter is more with what I'm concerned with. Because even the contributor community by itself is quite large. As for the t-shirt, speaking of community, so we like to actually do special t-shirts for the contributor summits. I designed this one. Despite my current career, my academic background is actually in art. This is obviously a Moreau pastiche, but one of things I actually learned by doing this was I did a different version first, It said Barca on it, and then one of the folks from here is like, "Well that's the football team." That when they abbreviate the city, it's actually Barna. >> It was news to me. I am today years old when I found that out. >> Yes. >> So thank you very much for that. >> Yes, that was an additional four hours of drawing for me. >> All right. Go ahead Corey. >> So a while back, I had a tweet that went out that I knew was going to be taken in two different ways and you were one of the first people to come back on that in the second way. Everyone first thought I was being a snarky jerk. >> Yeah. Which, let's be honest, fair. >> Yeah. >> But what I said was that in five years no one is going to care about Kubernetes. >> Right. >> And your response was yeah, that's a victory condition. If you don't have to think or care about this, >> Yeah. >> that means it won >> Right. >> in a similar way that a lot of things have slipped >> Yeah. >> beneath the level of awareness. And I'm curious as to what both of you think about the idea of Kubernetes not, I'm not saying it loses in the marketplace, I don't think that that is likely at all, but at what point do people not have to think about it any more and what does that future look like? >> Yeah, I mean one of our colleagues noticed yesterday that this conference particularly is not about Kubernetes any more. So, you hear more about all the ecosystem. A lot of projects around it. So it certainly grew up above the Kubernetes. And so you see all the talks about service meshes and things we try to do for the edge computing and things like that. So it's not just the Kubernetes any more. It's a whole ecosystem of the products and projects around it. I think, it's a big success. >> Yeah. And I mean I'll say, talking sort of a longer view is, I can remember compiling my own Linux kernels. I can remember doing it on a weekly basis. Because you honestly had to, right? If you wanted certain devices to work you had to actually compile your own kernel. Now on my various servers and stuff that I do for testing and demos and development, I can't even tell you what kernel version I'm running. Because I don't care, right? And for core Kubernetes, like I said, if we get to that point of not needing to care about it of only needing to care about it when we're developing something, then that looks like victory to me. >> Josh, is there anything in the core contributor team that they have milestones and say "Hey, by the time we get to 2.0 or 3.0, you know Kubernetes is invisible?" >> Yeah, well it's spoken of more in terms of GA and API stability >> Yeah. >> because really, if you're going to back off and you're going to say, "What is Kubernetes?" Well, Kubernetes is, what the definition of Kubernetes is, is a bag of APIs. A very large bag of APIs, we do a lot of APIs but a bag of APIs and the less those APIs change in the future the closer we're getting to maturity and stability, right? Because we want people building new stuff around the APIs, not modifying the APIs themselves. >> Yeah well, to that end, last night, here at Barcelona time, a blog post came out from AWS where they set out a formalized deprecation strategy for their EKS product to keep up with the releases of Kubernetes. Now, AWS generally does not turn things off ever, which means that 500 years from now, two trunkless legs of stone in a desert will be balanced by an ELB classic. And we're never going to be rid of anything they've ever built, but if nothing else, you've impacted them to formalize a deprecation strategy that follows upstream, which is awesome. It's great to start seeing a world where you don't have to support older versions of things as your user base and your community informs you. It's nice to see providers breaking from their model to respond to what the community has done. And I can't imagine, for you, that's anything other than an unqualified success. >> All right, so, Dejan. >> Yeah? >> When we talk about dispersion of technology, you know, there are few issues that get people as excited these days as edge computing. So, tell us a little bit about what you're doing and the community's doing in the IOTN edge space. >> Yeah. So, we noticed that more and more people want to try their workloads outside of the centralized, mon-centralized data clusters, so the big term for the last year was the hyper-cloud, but it's not just hyper-cloud. People coming also from the IOT user space wants to, you know, containerize their workloads, wants to put the processing closer and closer to the devices that they're actually producing and presuming those data in the users. And there's a lot of use cases which should be tackled in that way. And as you all said previously, like Kubernetes won developers' hearts and minds so APIs are stable, everybody's using them, it will be supported for decades so it's natural to try to bring all these tools and all these platforms that are already available to developers, try to tackle these new challenges. So that's why last year we formed Kubernetes IT edge working group, trying to, you know, start with simple questions because when people come to you and say edge, everybody thinks something different. For somebody it's an IOT gateway, for somebody it's a full blown, you know, Kubernetes cluster at some telco provider. So that's what they're trying to figure out, all these things, and try to form a community because as we saw in the previous sales for the IOT users space is that complex problems like this are never basically solved by a single company. You need open source, you need open standard, you need community around it so that people can pick and choose and build a solution to fit their needs. >> Yes, so as you said, right, there is that spectrum of offerings everything from that telco down to, you know, is this going to be something sitting on a tower somewhere or, you know, the vast proliferation of IOT which, you know, we spent lots of time. So are you looking at all of these or are you pointing "Okay, we already have a telco working group over here, and, you know, we're going to work on the IOT thing." You know, where are we? What are the answers and starting point for people today? >> Yes, so we have a single working group for now and we try to bring in to people that are interested in this topic in general. So it's, one of the guys said like "Edge is everything that's not running in the center crowd right, so, we have a couple of interesting things happening at a moment, so future way guys have a cubics project and there're presented at this conference. We have a couple of sessions on that. That's basically trying to tackle this device age kind of' space, how to, you know, put Kubernetes' workload on the constrained device and over to constrained network kind of' problem. And we have a people like coming from the rancher, which provide their own, again, resource-constrained Kubernetes deployments, and we see a lot of developments here, but it's still, I think, early age and that's why we have like a working group which is something that we can build our community and work over the time to shape things and find the appropriate reference, architectural blueprints for people that can follow in the future. >> Yeah, I think that there's been an awful lot of focus here on this show on Kubernetes, but it is KubeCon plus CloudNativeCon. I'm curious as far as what you're seeing with these conversations, something you eluded to as well is that there's now a bunch of other services that are factored in. I mean, it feels almost like this show is become, just from conversations, Kubernetes and friends; but, the level of attention that being paid to those friends is dramatically increasing. And I'm curious as to how you're seeing this evolve in the community particularly but also with customers and what you're seeing as this entire ecosystem continues to evolve. >> Yeah. Well, I mean part of it out of necessity, right, as when Kubernetes' move from Dev and experimental into production, you don't run Kubernetes by itself, right? And some of the things with Kubernetes is you can run with existing tooling, rank cloud providers, that sort of thing. But other things you discover that you want new tools. For example, one of the areas that we saw, expansion to start with, was the area of monitoring and telemetry because it turns out that monitoring telemetry that you build for a hundred servers does not work with twenty thousand pods. It's just a volume problem there. And so then we had new projects like Heapster and Prometheus and the new products from other companies like Sistic and that sort of thing, just looking at that space, right, in order to have that part of the tool because you can't be in production without monitoring and telemetry. One of my personal areas that I'm involved is storage, right, and so we've had the rook project here go from and pretty much a year and a half actually, go from being open sourced to being now a serious alternative solution if you don't want to be dependent on cloud provider storage. >> Please tell me you're giving that an award called Rookie of the Year. [laughs] >> I do not apologize for that one. One thing that does resonate with me though is the idea that you've taken, strategically, that instead of building all of this functionality into Kubernetes and turning it into, "You'll do it this way or you're going to be off in the wilderness somewhere," it's decoupled. I love that pattern. Was that always the design from day one or was this a contentious decision history? >> No, it wasn't. Kubernetes started out as kind of a monolith, right, because it was like the open source version of borg light, right, and, which was build as a monolith within Google 'cause there weren't options. They had to work with Google's stuff, right, if you're looking at borg, right, and so they're not worried about supporting all this other stuff, but from day one of Kubernetes being a project, it was a multi-company project, right, and if you look at, you know, open shift and open shift's users and open shift's stack, it's different from what Google uses for GKE. And, honestly, the easiest way to support sort of multiple stack layers is to decouple everything, right? And not how we started out, right? Cloud providers, like one of our problems cloud providers entry, storage entry, networking. Networking was the only thing that was separate from day one. You know but all this stuff was entry, and it didn't take very long for that to get unmaintainable, right? >> Well, I mean I think one of the, I've been following you and running into you in the conference circuit for years, and one of the talks I gave for a year and a half was Heresy in the Church of Docker where we don't know what your problem is but Docker, Docker, Docker, Docker, Docker, and I gave a list of twelve or thirteen different reasons and things that were not being handled by Docker. And now, I've sunset that talk largely because 1) no one talks about Docker and it feels a bit like punching down, but more importantly, Cooper Netties has largely solved almost all of those. There are still a few exceptions here and there 'cause it turns out "Sorry, nothing is perfect and we've not yet found containersation utopia. Surprise!" But it's really come a very long way in a very short period of time. >> Yeah, what a lot of it is is decoupling 'cause the thing is that you can take it two ways, right, one is that potentially as an ecosystem Kubernetes solves almost anything. Some things like IOT are, you know, a lot more alpha state than others. And then if you actually look at just core Kubernetes, it's like what you would get off the Kubernetes' Kubernetes repo if you compiled it yourself, Kubernetes solves almost nothing. Like by itself, you can't do much with it other than test your patches. >> Right, in isolation, the big problem it solves is "Room is limited to 'I want a buzz wort on my resume.'" >> Yes. >> There needs to be more to it than that. >> So, and I think that's true in general 'cause like, you know, if you look at "why did Linux become the default server OS, right?" It became the default server OS because it was adaptable, right, because you would compile in your own stuff because we define posics and kernel module API's to make it easy for people to build their own stuff without needing to commit to Lin EX Kernel. >> Alright, so I'd to get both your thoughts just on the storage piece there because, you know, 1) you know, storage is a complex, highly fragmented ecosystem out there. Red Hat has many options out there, and, boy, when I saw the key note this morning, I thought he did a really good job of laying out the options but, boy, there's, you know, it's a complex multi fragmented stack with a lot of different options out there, and edge computing, the storage industry as a whole without even Kubernetes is trying to figure out how that works, so Dejan, maybe we start with you, and yeah. >> So yeah. I don't have any particular answers for you for today in that area, but what I want, to emphasize what Josh said earlier is that these API's and these modelization that is done in Kubernetes, it's one of the big important things for edge's vow because people coming there and saying "We should do this. Should we invent things or should we just try to reuse what's a basically very good, very well designed system?" So that's a starting point, like why do we want to start using Kubernetes for the edge computing? But for the storage questions, I would hand over to Josh. >> So, your problem with storage is not anything to do with Kubernetes in particular, but the fact that, like you said, the storage sort of stack ecosystem is a mess. It's more vendor. Everything is vendor specific. Things don't work even semantically the same, let alone like the same by API. And so, all we can do in the world of Kubernetes is make enabling storage for Kubernetes not any harder than it would have been to do it in some other system. >> Right, and look, the storage industry'd say, "No no. It's not a mess. It's just that there's a prolifera of applications our there. There is not one solution to fit them all and that's why we have block, we have file, we have object, we have all these various ways of doing things, so you're saying storage is hard, but storage with Kubernetes is no harder today. We're getting to that point. >> I would say it's a little harder today. And we're working on making it not any harder. >> All right, excellent. Well, Josh and Dejan, thank you so much for the updates. >> Thank you guys. Always appreciative of the community contributions. Look forward to hearing more about the, of course, the contributors always and as the Edge and IOT groups mature. Look forward to hearing updates in the future. Thank you. >> Cool. >> Thank you guys. >> Alright, for Corey Quinn, I'm Stu Miniman back with lots more coverage hear from KubeCon CloudNativeCon 2019 in Barcelona, Spain. Thanks for watching theCube.