(Upbeat music) >> Hi everyone and welcome back to the Cube's coverage of Splunk.conf 2021, virtual. We are here, live in the Splunk studios here in Silicon valley. I'm John Furrier, host of the Cube. Spiros Xanthos VP of product management of observability with Splunk is here inside the cube, Spiros, thanks for coming on. Great to see you. [Spiros Xanthos]- John, thanks for having me glad to be here. >> We love observability. Of course we love Kubernetes, but that was before observability became popular. We've been covering cube-con since it was invented even before, during the OpenStack days, a lot of open source momentum with you guys with observability and also in the customer base. So I want to thank you for coming on. Give us the update. What is the observability story its clearly in the headlines of all the stories SiliconANGLE's headline is multi-cloud observability security Splunk doubling down on all three. >> Correct. >> Big part of the story is observability. >> Correct. And you mentioned CubeCon. I was there last week as well. It seems that those observability and security are the two most common buzzwords you hear these days different from how it was when we started it. But yeah, Splank actually has made the huge investment in observability, starting with the acquisition of Victor ops three years ago, and then with Omnition and Signalfx. And last year with Plumbr synthetics company called Rigor and Flowmill and a network monitoring company. And plus a lot of organic investment we've made over the last two years to essentially build an end-to-end observability platform that brings together metrics, traces, and logs, or otherwise infrastructure monitoring, log analytics, application monitoring. Visual experience monitoring all in one platform to monitor let's say traditional legacy and modern cloud native apps. >> For the folks that know SiliconANGLE, the Cube know we've been really following this from the beginning for signal effects, remember when they started they never changed their course. they've had the right They have the right history and from spot by spot, you guys, same way open source and cloud was poo-pooed upon, people went like, oh, it's not secure, they never were. Now it's the center of all the action. [Spiros Xanthos]- Yes >> And so that's really cool. And thanks for doing that. The other thing I want to get your point on is what does end-to-end observability mean? Because there's a lot of observability companies out there right now saying, Hey, we're the solution We're the utility, we're the tool, but I haven't seen a platform. So what's your answer to that? >> Yes. So observability, in my opinion, in the context of what you're describing means two things. One is that when, when we say internal durability, it means that instead of having, let's say multiple monitoring tools that are silent, let's say one for monitoring network, one for monitoring infrastructure, a separate one for monitoring APM that do not work with each other. We bring all of these telemetry in one place we connect it and exactly because actually applications and infrastructure themselves are becoming one. You have a way to monitor all of it from one place. So that's observability. But the other thing that observability also is because these environments tend to be a lot more complex. It's not just about connecting them, right? It's also about having enough data and enough analytics to be able to make sense out of those environments and solve problems faster than you could do in the past with traditional monitoring. >> That's a great definition. I've got to then ask you one of the things coming up that came out of CoopCon was clear, is that the personnel to hire, to run this stuff, it's not everyone can get the skills gap problem. At the same time, automation is at an all time high people are automating and doing AI ops, get outs. What do you want to call this a buzz word for that basically automating the data observability into the CICB pipeline, huge trend right now. And the speed of developers is fast now. They're coding fast. They don't want to wait. >> I agree. So, and that's exactly what's happening, right? We want essentially from traditional IT where developers would develop something a little bit deployed months later by some IT professional, of course, all of this coming together, But we're not stopping that as you say, right, that the shifting left is going earlier into the pipeline. Everyone expect, essentially let's say monitoring to happen at the speed of deployment. And I guess observability again, is this not, as a requirement. Observability is this idea. Let's say that I should be able to monitor my applications in real time and, you know, get information as soon as something happens. >> With the evolution of the shift left trend. I would say for the people don't know what shift left is you put security the beginning, not bolted on at the end and developers can do it with automation, all that good stuff that they have. But how, how real is that right now in terms of it happening? Can you, can you share some vision and ideas and anecdotal data on how, how fast shift left is, or is there still bottlenecks and security groups and IT groups? >> So there are bottlenecks for sure. In my opinion, we are aware with, let's say the shift left or the dev sec ops trend, whether IT and devs maybe a few years ago. And this is both a cultural evolution that has to happen. So security teams and developers have to come closer together, understand like, say the consensus of the requirements of each other so they can work better together the way it happened with DevOps and all sorts of tooling problem, right? Like still observability or monitoring solutions are not working very well with security yet. We at Splunk of course, make this a priority. And we have the platform to integrate all the data in one place. But I don't think is generally something that we'll have achieved as well as an industry yet. And including the cultural aspects of it. >> Is that why you think end to end is important to hit that piece there so that people feel like it's all working together >> I think end to end is important for two reasons. actually one is that essentially, as you say, you hit all the pieces from the point of deployment, let's say all the way to production, but it's also because I think applications and infrastructure, FMLA infrastructure with Kubernetes, microservices are in traditional so much more complexity that you need to step function improvement in the tooling as well. Right? So that you need keep up with the complexity. So bringing everything together and applying analytics on top is the way essentially to have this step function improvement in how your monitoring solution works so that it can keep up with the complexity of the underlying infrastructure and application. >> That is a huge, huge points Spiros. I got to double down on that with you and say, let's expand that because that's the number one problem, taming the complexity without slowing down. Right? So what is the best practice for that? What do people do? Cause, I mean, I know it's evolving, it's going faster than that, but it's still getting better, but not always there, but what can people do to go faster? >> So, and I will add that it's even more complex than just what the cloud, let's say, native applications introduced because especially large enterprises have to maintain their routine, that on-prem footprint legacy applications that are still in production and then still expand. So it's additive to what they have today, right? If somebody was to start from a clean slate, let's say started with Kubernetes today, maybe yes, we have the cloud native tooling to monitor that, but that's not the reality of most, most enterprises out there. Right? So I think our goal at Splunk at least is to be able to essentially work with our customers through their digital, digital transformation and cloud journey. So to be able to support all their existing applications, but also help them bring those to the cloud and develop new applications in a cloud native fashion, let's say, and we have the tooling, I think, to support all of that, right between let's say our original data platform and our metrics and traces platform that we develop further. >> That's awesome. And then one quick question on the customer side, if I'm a customer, I want observability, I want this, I want everything you just said. How do I tell the difference between a pretender and a player, the good solution and a bad solution? What are the signals that this is the real deal, that's a fake product >> Agreed. So, I mean, everyone obviously believes that original (laughing) I'm not sure if I will. >> You don't want to name names? Here's my, my perspective on what truly is a requirement for absorb-ability right? First of all, I think we have moved past the time where let's say proprietary instrumentation and data collection was a differentiator. In fact, it actually is a problem today, if you are deploying that because it creates silos, right? If I have a proprietary instrumentation approach for my application, that data cannot be connected to my infrastructure or my logs, let's say, right. So that's why we believe open telemetry is the future. And we start there in terms of data collection. Once we standardize, let's say data collection, then the problem moves to analytics. And that's, I think where the future is, right? So observability is not just about collecting a bunch of data and that bring it back to the user. It's about making sense out of this data, right? So the name of the game is analytics and machine learning on top of the data. And of course the more data you can collect, the better it is from that perspective. And of course, then when we're talking about enterprises, scale controls, compliance all of these matter. And I think real time matters a lot as well, right? We cannot be alerting people after minutes of a problem that has happened, but within a few seconds, if we wanted to really be pro-active. >> I think one thing I like to throw out there, maybe get your reaction to it, I think maybe one other thing might be enabling the customer to code on top of it, because I think trying to own the vertical stack as well as is also risky as a vendor to sell to a company, having the ability to add programming ability on top of it. >> I completely agree actually, You do? In general giving more control to the users and how, what do they do with their data, let's say, right? And even allowing them to use open source, whatever is appropriate for them, right? In combination, maybe with a vendor solution when they don't want to invest themselves. >> Build their own apps, build your own experience. That's the way the world works. That's software. >> I agree. And again, Splunk from the beginning was about that, right? Like we'll have thousands of apps built ontop of our platform >> Awesome. Well, I want to talk about open source and the work you're doing with open telemetry. I think that's super important. Again, go back even five, 10 years ago. Oh my God. The cloud's not secure. Oh my God, open source has got security holes. It turns out it's actually the opposite now. So, you know finally through the people woke up. No, but it's gotten better. So take us through the open telemetry and what you guys are doing with that. >> Yes. So first of all, my belief, my personal belief is that if there is no future where infrastructure is anything about open source, right? Because people do not trust actually close our solutions in terms of security. They prefer open source at this point. So I think that's the future. And in that sense, a few years ago, I guess our belief was that all data collection instrumentations with standards based first of all, so that the users have control and second should be open source. That's why we, at Omnition the company I co-founded that was acquired by Splunk. We we're one of the main tenders of open sensors and that we brought together open sensors and OpenTracing in creating open telemetry. And now , Open telemetry is pretty much the de facto. Every vendor supports it, its the second most active project in CNCF. And I think it's the future, right? Both because it frees up the data and breaks up the silos, but also because, has support from all the vendors. It's impossible for any single vendor to keep up with all this complexity and compete with the entire industry when we all come together. So I think it's a great success it's I guess, kudos to everybody, kudos to CNCF as well, that was able to actually create and some others. >> And props to CNCF. Yeah. CNC has done an amazing job and been going to all those events all the years and all the innovations has been phenomenal. I got to ask what the silos, since you brought it up, come multiple times. And again, I think this is important just to kind of put an exclamation point on, machine learning is based upon data. Okay. If you have silos, you have the high risk of having bad machine learning. >> Yes. >> Okay. That's you agree with that? >> Completely. >> So customers, they kind of understand this, right. If you have silos that equals bad future >> Correct >> because machine learning is baked into everything now. >> And I will add to that. So silos is the one problem, and then not being able to have all the data is another problem, right? When it comes to being able to make sense out of it. So we're big believers in what we call full fidelity. So being able to connect every byte of data and do it in a way that makes sense, obviously economically for the customer, but also have, let's say high signal to noise ratio, right? By structuring the data at the source. Overt telemetry is another contributor to that. And by collecting all the data and by having an ability, let's say to connect the data together, metrics, traces, logs, events, incidents, then we can actually build a little more effective tooling on top to provide answers back to the user with high confidence. So then users can start trusting the answers as opposed to they themselves, always having to figure out what the problem is. And I think that's the future. And we're just starting. >> Spiros I want to ask you now, my final question is about culture And you know, when you have scale with the cloud and data, goodness, where you have people actually know the value of data and they incorporate into their application, you have advantages. You have competitive advantages in some cases, but developers were just coding love dev ops because it's infrastructure as code. They don't have to get into the weeds and do the under the hood, datas have that same phenomenon right now where people want access to data. But there's certain departments like security departments and IT groups holding back and slowing down the developers who are waiting days and weeks when they want it in minutes and seconds for have these kinds of things. So the trend is, well there's, first of all, there's the culture of people aren't getting along and they're hating each other or they're not liking each other. >> Yes >> There's a little conflict, always kind of been there, but now more than ever, because why wait? >> I agree. >> How can companies shorten that cycle? Make it more cohesive, still decouple the groups because you've got, you got compliance. How do you maximize the best of a good security group, a good IT group and enables as fast as possible developers. >> I agree with you, by the way, this is primarily cultural. And then of course there is a tooling gap as well. Right. But I think we have to understand, let's say as a security group, instead of developers, what are the needs of each other, right. Why we're doing the things we're doing because everybody has the right intentions to some extent, right? But the truth is there is pain. We are me and myself. Like as we develop our own solutions in a cloud native fashion, we see that right. We want to move as fast as possible, but at the same time, want to be compliant and secure, right. And we cannot compromise actually on security or compliance. I mean, that's really the wrong solution here. So I think we need to come together, understand what each other is trying to do and provide. And actually we need to build better tooling that doesn't get into the way. Today, oftentimes it's painful to have, let's say a compliance solution or a secure solution because it slows down development. I think we need to actually, again, maybe a step function improvement in the type of tooling we'll have in this space. So it doesn't get into the way Right? It does the work it provides. Let's say the security, the security team requires, it provides the guarantees there, but doesn't get in the way of developers. And today it doesn't happen like this most of the time. So we have some ways to go. >> And Garth has mentioning how you guys got some machine learning around different products is one policy kind of give some, you know, open, you know, guardrails for the developers to bounce around and do things until they, until they have to put a new policy in place. Is that an answer automated with automation? >> Big time. Automation is a big part of the answer, right? I think we need to have tooling that first of all works quickly and provides the answers we need. And we'll have to have a way to verify that the answer are in place without slowing down developers.Splunk is, I mean, out of a utility of DevSecOps in particular is around that, right? That we need to do it in a way that doesn't get in the way of, of let's say the developer and the velocity at which they're trying to move, but also at the same time, collect all the data and make sure, you know, we know what's going on in the environment. >> Is AI ops and dev sec ops and GET ops all the same thing in your mind, or is it all just labels >> It's not necessarily the same thing because I think AI ops, in my opinion applies, let's say to even more traditional environments, what are you going to automate? Let's say IT workflows in like legacy applications and infrastructure. Getops in my mind is maybe the equivalent when you're talking about like cloud native solutions, but as a concept, potentially they are very close I guess. >> Well, great stuff. Great insight. Thanks for coming on the Cube. Final point is what's your take this year of the live we're in person, but it's virtual, we're streaming out. It's kind of a hybrid media environment. Splunk's now in the media business with the studios, everything great announcements. What's your takeaway from the keynote this week? What's your, you got to share to the audience, this week's summary. >> First of all, I really hope next year, we're all going to be in one place, but still given the limitations we had I think it was a great production and thanks to everybody who was involved. So my key takeaway is that we truly actually have moved to the data age and data is at the heart of everything we do. Right? And I think Splunk has always been that as a company, but I think we ourselves really embraced that and everything we do is everything. Most of the problems we solve are data problems, whether it's security, observability, DevSecOps, et cetera. So. >> Yeah, and I would say, I would add to that by saying that my observations during the pandemic now we're coming, hopefully to the end of it, you guys have been continuing to ship code and with real, not vaporware real product, the demos were real. And then the success on the open source. Congratulations. >> Thank you. >> All right. Thanks for coming on and we appreciate it >> Thanks alot _Cube coverage here at dot com Splunk annual conference. Virtual is the Cube. We're here live at the studios here at Splunk studios for their event. I'm John Farrow with the Cube. Thanks for watching. (joyful tune)

>> Narrator: From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Hi I'm Stu Miniman and this is theCUBE's coverage of KubeCon, CloudNativeCon the 2020 European show of course happening virtually and that has put some unique challenges for the people running the show, really happy to welcome to the program she is one of the co-chairs of this event, and she is also a Principal Software Engineer at Splunk, Constance Caramanolis thank you so much for joining us. >> Hi, thank you for having me, I'm really excited to be here, it's definitely an interesting time. >> Alright, so Constance we know KubeCon it's a great community, robust everybody loves to get together there's some really interesting hallway conversations and so much going on, we've been watching, the four or five years we've been doing theCUBE at this show, just huge explosion of the breadth and depth of the content and of course, great people there. Just, if we could start with a little bit, your background, as I mentioned you're the co-chair, you work for Splunk by way of an acquisition, of Omnition try saying that three times fast, and Omnition you were telling me is a company that was bought really before it came out of stealth, but when it comes to the community itself, how long have you been involved in this community? What kind of led you to being co-chair? >> Yeah, I guess I've been involved with the community since 2017, so, I was at Lyft before Omnition Splunk, and I was lucky enough to be one of the first engineers, on Envoy you might've heard of Envoy, sorry I laugh at my own jokes. (laughing) Like my first exposure to KubeCon and seeing the CNCF community was KubeCon Austin and the thing that I was amazed by was actually you said it the hallway tracks, right? I would just see someone and be like, "Hey, like, I think I've seen your code review can I say hi?" And that started back on me at least a little bit involved in terms of talking to more people then they needed people I would work on a PR or in some of the community meetings and that was my first exposure to the community. And so I was involved in Envoy pretty actively involved in Envoy all the way until from 2016 until mid 2018 and then I switched projects and turning it left and did some other stuff and I came back into CNCF community, in OpenTelemetry as of last year, actually almost exactly a year ago now to work on making tracing, I'm going to say useful and the reason why I say useful is that usually people think of tracing as, not as important as metrics and logs, but there is so much to tracing that we tend to undervalue and that's why I got involved with OpenTelemetry and Omnition, because there's some really interesting ways that you could view tracing, use tracing, and you could answer a lot of questions that we have in our day-to-day and so that's kind of that's how I got involved in the second-round community and then ended up getting nominated to be on the co-chair and I obviously said yes, because this is an amazing opportunity to meet more people and have more of that hallway track. >> Alright, so definitely want to talk about OpenTracing, but let's talk about the event first, as we were talking about. >> Yeah. >> That community you always love the speakers, when they finish a session, they get mobbed by people doing questions. When you walk through the expo hall, you go see people so give us a little bit of insight as to how we're trying to replicate that experience, make sure that there's I don't know office hours for the speakers and just places and spaces for people to connect and meet people. >> Yeah, so I will say that like, part of the challenge with KubeCone EU was that it had already been meant to be an in person event and so we're changing it to virtual, isn't going to be as smooth as a KubeCon or we have the China event that's happening in a few weeks or at Boston, right that's still going on, like, those ones are being thought out a lot more as a proper virtual event. So a little bit of the awkwardness of, now everything is going to be online, right? It's like you can't actually shake someone's hand in a hallway but we are definitely trying to be cognizant of when I'm in terms of future load, like probably less content, right. It's harder to sit in front of a screen and listen to everything and so we know that we know we have enough bandwidth we're trying to find, different pieces of software that allow for better Q and A, right? Exactly, like the mobbing after session is go in as a speaker and one as attendee is sometimes like the best part about conferences is you get to like someone might've said something like, "Hey, like this little tidbit "I need to ask you more questions about this." So we're providing software to at least make that as smooth, and I'm putting this in quotation and as you'll be able to tell anyone who's watching as I speak with my hands. Right, so we're definitely trying to provide software to at least make that initial interaction as smooth as possible, maybe as easy as possible we know it's probably going to be a little bit bumpy just because I think it's also our first time, like everyone, every conference is facing this issue so it's going to be really interesting to see how the conference software evolves. It is things that we've talked about in terms of maybe offering their office hours, for that it's still something that like, I think it's going to be really just an open question for all of us, is that how do we maintain that community? And I think maybe we were talking or kind of when I was like planting the seed of a topic beforehand, it's like it's something I think that matters like, how do we actually define community? 'Cause so much of it has been defined off that hallway track or bumping into someone, right? And going into someone's booth and be like, like asking that question there, because it is a lot more less intimidating to ask something in person than is to ask it online when everyone gets to hear your question, right. I know I ask less questions online, I guess maybe one thing I want to say is that for now that am thinking about it is like, if you have a question please ask questions, right? If recording is done, if there's a recording for a talk, the speakers are usually made available online during the session or a bit afterwards, so please ask your questions when things come up, because that's going to be a really good way to, at least have a bit of that question there. And also don't be shy, please, even when I say like in terms of like, when it comes to review, code reviews, but if something's unintuitive or let's say, think about something else, like interact with it, say it or even ask that question on Twitter, if you're brave enough, I wouldn't but I also barely use Twitter, yeah I don't know it's a big open question I don't know what the community is going to look like and if it's going to be harder. >> Yeah, well, one of the things I know every, every time I go to the show conferences, when the keynote when it's always like, okay, "How many people is this your first time at the show?" And you look around and it's somewhere, third or half people attending for the first time. >> Yeah. I know I'm trying to remember if it was year and a half ago, or so there was created a kind of one-on-one track at the show to really help onboard and give people into the show because when the show started out, it was like okay, it was Kubernetes and a couple of other things now you've got the graduated, the incubated, the dozens of sandbox projects out there and then even more projects out there so, cloud-native is quite a broad topic, there is no wrong way where you can start and there's so many paths that you can go on. So any tips or things that we're doing this time, to kind of help broaden and welcome in those new participants? >> Yeah so there's two things, one is actually the one to attract is official for a KubeCon EU so we do have like, there's a few good talks in terms of like, how to approach KubeCon it was meant to originally be for a person but at least helping people in terms of general terms, right? 'Cause sometimes there's so much terminology that it feels like you need to carry, cloud-native dictionary around with you, doing that and giving suggestions there, so that's one of the first talks that's going to be able to watch on KubeCon so I highly suggest that, This is actually a really tough question because a lot of it would have been like, I guess it would have been for me, would have been in person be like, don't be afraid to like, if you see someone that, said something really interesting in a talk you attended, like, even if it's not after the question, just be like, "Hey, I thought what you said was really cool "and I just want to say I appreciate your work." Like expressing that appreciation and just even if it isn't like the most thoughtful question in the world just saying thank you or I appreciate you as a really good way to open things up because the people who are speaking are just as well most people are probably just as scared of going up there and sharing their knowledge as probably or of asking a question. So I think the main takeaway from that is don't be shy, like maybe do a nervous dance to get those jitters out and then after (laughing) and then ask that question or say like, thank you it's really nice to meet you. It's harder to have a virtual coffee, so hopefully they have their own teapot or coffee maker beside them, but offered you that, send an email I think, one thing that is very common and I have a hard time with this is that it's easy to get overwhelmed with how much content there is or you said it's just like, I first feel small and at least if everyone is focusing on Kubernetes, especially like a few years ago, at least and you're like, maybe that there are a lot of people who are really advanced but now that there's so many different people like so many people from all range of expertise in this subject matter experts, and interests that it's okay to be overwhelmed just be like, I need to take a step back because mentally attending like a few talks a day is like, I feel like it's taking like several exams 'cause there's so much information being bombarded on you and you're trying to process it so understand that you can't process it all in one day and that's okay, come back to it, right. It's a great thing is that all of these talks are recorded and so you can watch it another time, and I would say probably just choose like three or four talks that you're really excited about and listen to those, don't need to watch everything because as I said we can't process it all and that's okay and ask questions. >> Some great advice there because right, if we were there in person it was always, attend what you really want to see, are there speakers you want to engage with? Because you can go back and watch on demand that's been one of the great opportunities with the virtual events is you can have access on demand, you can poke and prod, personally I love that a lot of them you can adjust the speed of them so, if it's something that it's kind of an intro talk, I can crank it up to one and a half or 2X speed and get through more content or I can pause it, rewind if I'm not getting it. And the other opportunity is I tell you the last two or three years, when I'm at an event, I try to just spend my time, not looking at my phone, talking to people, but now there's the opportunity, hey, if I can be of help, if anybody in the community has a question or wants to get connected to somebody, we know a lot of people I'm easily reachable on Twitter and I'm not sitting on a plane or in the middle of something that being like, so there is just a great robust community out there, online, and it were great be a part of it. So speaking of projects, you mentioned OpenTelemetry, which is what, your day job works on it's been a really, interesting topic of course for those that don't know the history, there were actually two projects that merged, it was a OpenTracing and OpenCensus created OpenTelemetry, so why don't you bring us up to speed as to where we are with the project, and what people should be looking at at the show and throughout the rest of 2020? >> OpenTelemetry is very exciting, we just did our first beta release so for anyone who's been on the fence of, is OpenTelemetry getting traction, or is it something that you're like at, this is a really great time to want to get involved in OpenTelemetry and start looking into it, if it's as a viable project, but I guess should probably take a step back of what is OpenTelemetry, OpenTelemetry as you mentioned was the merging or the marriage of OpenTracing-OpenCensus, right? It was an acknowledgement that so many engineers were trying to solve the same problem, but as most of us knows, right, we are trying to solve the same problem, but we had two different implementations and we actually ended up having essentially a lot of waste of resources because we're all trying to solve the same problem, but then we're working on two different implementations. So that marriage was to address that because, right it's like if you look at all of the major players, all of the players on OpenTelemetry, right? They have a wide variety of vendor experience, right even as of speaking from the vendor hat, right vendors are really lucky that they get to work with so many customers and they get to see all these different use cases. Then there's also just so many actually end users who are using it and they have very peculiar use cases, too, even with a wide set of other people, they're not going to obviously have that, so OpenTelemetry gets to merge all of those different use cases into one, or I guess not into one, but like into a wide set of implementations, but at least it's maintained by a larger group instead of having two separate. And so the first goal was to unify tracing tracing is really far ahead in terms of implementation,, or several implementations of libraries, like Go, Java, Python, Ruby, like on other languages right now but quite a bit of lists there and there's even a collector too which some people might refer to as an agent, depending on what background they have. And so there's a lot of ways to one, implement tracing and also metrics for your services and also gather that data and manipulate it, right? 'Cause for example, tracings so tracing where it's like you can generate a lot of traces, but sometimes missing data and like the collector is a really great place to add data to that, so going back to the state of OpenTelemetry, OpenTelemetry since we just did a beta release, right, we're getting closer to GA. GA is something that we're tracking for at some point this year, no dates yet but it's something that we're really pushing towards, but we're starting to have a very stable API in terms of tracing a metric was on its way, log was all something we're wrapping up on. It is a really great opportunity to, all the different ways that we are that, we even say like service owners, applications, even business rate that we're trying to collect data and have visibility into our applications, this is a really great way to provide one common framework to generate all that data, to gather all that data and generate all that data. So it was really exciting and I don't know, we just want more users and why we say that is to the earlier point is that the more users that we have who are engaged with community, right if you want to open an issue, have a question if you want to set up a PR please do, like we really want more community engagement. It is a great time to do that because we are just starting to get traction, right? Like hopefully, hopefully in a year or two, like we are one of those really big, big projects right up on a CNCF KubeCon and it's like, let's see how much has grown. And it's a great time to join and help influence a project and so many chances for ownership, I know it's really exciting, the company-- >> Excellent well Constance, it's really exciting >> Yeah. >> Congratulations on the progress there, I'm sure everybody's looking forward to as you said GA later this year, want to give you the final word, yourself and Vicky Cheung as the co-chairs for the event, what's your real goal? What do you hope the takeaway is from this instance of the 2020 European show? Of course, virtual now instead of Amsterdam. I guess like two parts one for the takeaway is that it's probably going to be awkward, right? Especially again going back to the community is that we don't have a lot of that in person things so this will be an awkward interaction, but it's a really great place for us to want to assess what a community means to us and how we interact with the community. So I think it's going to be going into it with an open mindset of just knowing like, don't set the expectations, like any other KubeCon because we just know it won't be right, we can't even have like the after hours, like going out for coffee or drinks and other stuff there so having that there and being open to that being different and then also if you have ideas share it with us, 'cause we want to know how we can make it better, so expect that it's different, but it's still going to provide you with a lot of that content that you've been looking for and we still want to make that as much of a welcoming experience for you, so know that we're doing our best and we're open to feedback and we're here for you. >> Excellent, well Constance thank you so much for the work that you and the team have been doing on. absolutely, one of the events that we always look forward to, thanks so much for joining us. >> Thank you for having me. >> Alright, lots more coverage of theCUBE at KubeCon-Cloud Native on Europe 2020, I'm Stu Miniman and thanks for watching. (soft music)

>> From theCUBE Studios in Palo Alto and Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. >> Hi, I'm Stu Miniman, and welcome to this CUBE Conversation. I'm coming to you from our Boston area studio. I'm happy to welcome to the program someone we've known for many years, but a first time on the program. Priyanka Sharma, thank you so much for joining us. >> Hi, Stu. Thank you so much for having me. >> All right, and Priyanka, let's not bury the lead or anything. The reason we're talking to you is the news. You've got a new job, but in an area that you know really well. So we've known you through the cloud native communities for a number of years. We see you at the shows. We see you online. So happy to share with our community you are now the general manager of the CNCF, so congratulations so much on the job. >> Thank you so much. I am so honored to have this opportunity, and I can't wait to work even more closely with the cloud native community than I have already. I mean, as you said, I've been involved for a long time. I actually just saw on my LinkedIn today that 2016 was when my conversation within the CNCF started. I was then working on the OpenTracing Project, which was the third project to join the foundation, and CNCF had started in 2015, so it was all very new. We were in conversations, and it was just such an exciting time, and that just kept getting bigger and bigger, and then with GitLab I served, I actually still serve, until the 31st, on the board. And now this, so I'm very, very excited. >> Yeah, well right. So you're a board member of the CNCF, but Priyanka, if you go back even further, we look at how did CNCF start. It was all around Kubernetes. Where did Kubernetes come from? It came from Google, and when I dug back far enough into your CV I found Google on there, too. So maybe just give us a little bit of your career arc, and what you're involved with for people that don't know you from all these communities and events. >> Sure, absolutely. So my career started at Google in Mountain View, and I was on the business side of things. I worked with AdSense products, and around that same time I had a bit of the entrepreneurial bite, so the bug bit me, and I first joined a startup that was acquired by GoDaddy later on, and then I went off on my own. That was a very interesting time for me, because that was when I truly learned about the power of opensource. One of the products that me and my co-founder were building was an opensource time tracker, and I just saw the momentum on these communities, and that's when the dev tools love started. And then I got involved with Heavybit Industries, which is an accelerator for dev tools. There I met so many companies that were either in the cloud space, or just general other kinds of dev tools, advised a few, ended up joining LightStep, where the founders, them and a few community members were the creators of the OpenTracing standard. Got heavily, heavily involved in that project, jumped into cloud native with that, was a project contributor, organizer, educator, documentarian, all kinds of things, right, for two-plus years, and then GitLab with the board membership, and that's how I saw, actually, the governance side. Until then it had all been the community, the education, that aspect, and then I understood how Chris and Dan had built this amazing foundation that's done so much from the governance perspective. So it's been a long journey and it all feels that it's been coming towards in this awesome new direction. >> Well, yeah. Congratulations to you, and right, CNCF, in their press release I see Dan talked about you've been a speaker, you've been a governing board member, you participate in this, and you're going to help with that next phase, and you teased out a little bit, there's a lot of constituencies in the CNCF. There's a large user participation. We always love talking at KubeCon about the people not only just using the technology, but contributing back, the role of opensource, the large vendor ecosystem, a lot there. So give us your thought as to kind of where the CNCF is today, and where it needs to continue and go in the future. >> Absolutely. So in my opinion the CNCF is a breakout organization. I mean, we're approaching 600 members, of which 142 are end users. So with that number the CNCF is actually the largest, has the largest end user community of all opensource foundations. So tremendous progress has been made, especially from those days back in 2016 when we were the third project being considered. So leaps and bounds, so impressive. And I think... If you think about what's the end user storyline right now, so the CNCF did a survey last year, and so 84% of the people surveyed were using containers in production, and 78% were using Kubernetes in production. Amazing numbers, especially since both are up by about 15, 20% year over year. So this move towards devops, towards cloud native, towards Kubernetes is happening and happening really strong. The project has truly established itself. Kubernetes has won, in my opinion, and that's really good. I think now when it comes to the second wave, it is my perspective that the end user communities and the... Just the momentum that we have right now, we need to build and grow it. We need deeper developer engagement, because if you think about it, there's not just one graduated project in CNCF. There are 10. So Kubernetes being one of them, but there's Prometheus, there's Envoy, Jaeger, et cetera, et cetera. So we have amazing technologies that are all gaining adoption. Being graduated means that they have fast security audits, they have diverse contributors, they have safe, good governance, so as an end user you can feel very secure adopting them, and so we have so much to do to expand on the knowledge of those projects. We have so much to make software just better every day, so that's my one vector in my opinion. The second vector, I would say it has been more opportunistic. As you know, we are all living in a very unprecedented time with a global pandemic. Many of us are sheltering in place. Many are... Generally, life is changed. You are in media. You know this much better than me, I'm sure, that the number of, the amount of digital consumption has just skyrocketed. People are reading that many more articles. I'm watching that many more memes and jokes online, right? And what that means is that more and more companies are reaching that crazy web scale that started this whole cloud native and devops space in the first time, first place with Google and Netflix being D-to-C companies just building out what eventually became cloud native, SRE, that kind of stuff. So in general, online consumption's higher, so more and more companies need to be cloud native to support that kind of traffic. Secondly, even for folks that are not creating content, just a lot of the workflows have to move online. More people will do online banking. More people will do ecommerce. It's just the shift is happening, and for that we, as the foundation, need to be ready to support the end users with education, enablement, certifications, training programs, just to get them across that chasm into a new, even more online-focused reality. >> Yeah, and I say, Priyanka, that tees up one of the ways that most people are familiar with the CNCF is through the event. So KubeCon and CloudNativeCon, really the signature event. Tremendous growth over the last few years. You actually had involvement in a virtual event, the Cloud Native Summit recently. For KubeCon-- >> Yes. >> The European show is announced virtual. We know that there's still some uncertainty when it comes to the North America show. Supposed to be in my backyard here in Boston, so we'd love for it to happen. If it happens-- >> Of course. >> If not, we'll be there virtually or not. Give us a little bit your experience with the Cloud Native Summit, and what's your thinking today? We understand, as you said, a lot of uncertainty as to what goes on. Absolutely, even when physical events come back in the future, we expect this hybrid model to be with us for a long time. >> I definitely hear that. Completely agree that everything is uncertain and things have changed very rapidly for our world, particularly when it comes to events. We're lucky at the CNCF to be working with the LF Events team, which is just best in class, and we are working very hard every day, them, doing a lot of the lion's share of the work of building the best experience we can for KubeCon, CloudNativeCon EU, which, as you said, went virtual. I'm really looking forward to it because what I learned from the Cloud Native Summit Online, which was the event you mentioned that I had hosted in April, is that people are hungry to just engage, to see each other, to communicate however they can in this current time. Today I don't think the technology's at a point where physical events can be overshadowed by virtual, so there's still something very special about seeing someone face-to-face, having a coffee, and having that banter, conversations. But at the same time there are some benefits to online. So as an example, with the Cloud Native Summit, really, it was just me and a few community folks who were sad we didn't get to go to Amsterdam, so we're like, "Let's just get together in a group, "have some fun, talk to some maintainers," that kind of thing. I expected a few hundred, max. Thousands of people showed up, and that was just mind blowing because I was like, "Wait, what?" (chuckling) But it was so awesome because not only were there a lot of people, there were people from just about every part of the globe. So normally you have US, Europe, that kind of focus, and there's the Asia-PAC events that cater to that, but here in that one event where, by the way, we were talking to each other in realtime, there were folks from Asia-PAC, there were folks from Americas, EU, also the African continent, so geo meant nothing anymore. And that was very awesome. People from these different parts of the world were talking, engaging, learning, all at the same time, and I think with over 20,000 people expected at KubeCon EU, with it being virtual, we'll see something similar, and I think that's a big opportunity for us going forward. >> Yeah, no, absolutely. There are some new opportunities, some new challenges. I think back to way back in January I got to attend the GitLab event, and you look at GitLab, a fully remote company, but talking about the benefits of still getting together and doing things online. You think of the developer communities, they're used to working remote and working across different timezones, but there is that need to be able to get together and collaborate, and so we've got some opportunities, we've got some challenges when remote, so I guess, yeah, Priyanka. Give me the final word, things you want to look forward to, things we should be expecting from you and the CNCF team going forward. I guess I'll mention for our audience, I guess, Dan Kohn staying part of Linux Foundation, doing some healthcare things, will still stay a little involved, and Chris Aniszczyk, who's the CTO, still the CTO. I just saw him. Did a great panel for DockerCon with Kelsey Hightower, Michelle Noorali, and Sean Connelly, and all people we know that-- >> Right. >> Often are speaking at KubeCon, too. So many of the faces staying the same. I'm not expecting a big change, but what should we expect going forward? >> That's absolutely correct, Stu. No big changes. My first big priority as I join is, I mean, as you know, coming with the community background, with all this work that we've put into education and learning from each other, my number one goal is going to be to listen and learn in a very diverse set of personas that are part of this whole community. I mean, there's the board, there is the technical oversight committee, there is the project maintainers, there's the contributors, there are the end users, potential developers who could be contributors. There's just so many different types of people all united in our interest and desire to learn more about cloud native. So my number one priority is going to listen and learn, and as I get more and more up to speed I'm very lucky that Chris Aniszczyk, who has built this with Dan, is staying on and is going to be advising me, guiding me, and working with me. Dan as well is actually going to be around to help advise me and also work on some key initiatives, in addition to his big, new thing with public health and the Linux Foundation. You never expect anything average with Dan, so it's going to be amazing. He's done so much for this foundation and brought it to this point, which in my mind, I mean, it's stupendous the amount of work that's happened. It's so cool. So I'm really looking forward to building on this amazing foundation created by Dan and Chris under Jim. I think that what they have done by not only providing a neutral IP zone where people can contribute and use projects safely, they've also created an ecosystem where there is events, there is educational activity, projects can get documentation support, VR support. It's a very holistic view, and that's something, in my opinion, new, at least in the way it's done. So I just want to build upon that, and I think the end user communities will keep growing, will keep educating, will keep working together, and this is a team effort that we are all in together. >> Well, Priyanka, congratulations again. We know your community background and strong community at the CNCF. Looking forward to seeing that both in the virtual events in the near term and back when we have physical events again in the future, so thanks so much for joining us. >> Thank you for having me. >> All right. Be sure to check out thecube.net. You'll see all the previous events we've done with the CNCF, as well as, as mentioned, we will be helping keep cloud native connected at KubeCon, CloudNativeCon Europe, the virtual event in August, as well as the North American event later in the year. I'm Stu Miniman, and thank you for watching theCUBE. (smooth music)

>> Live from Barcelona, Spain, it's theCUBE! Covering KubeCon and CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Welcome back. This is theCUBE's live coverage of KubeCon, CloudNativeCon 2019 here in Barcelona, Spain. 7,700 here in attendance, here about all the Cloud Native technologies. I'm Stu Miniman; my cohost to the two days of coverage is Corey Quinn. And to help us break down what's happening in this ecosystem, we've brought in Jason Bloomberg, who's the president at Intellyx. Jason, thanks so much for joining us. >> It's great to be here. >> All right. There's probably some things in the keynote I want to talk about, but I also want to get your general impression of the show and beyond the show, just the ecosystem here. Brian Liles came out this morning. He did not sing or rap for us this morning like he did yesterday. He did remind us that the dinners in Barcelona meant that people were a little late coming in here because, even once you've got through all of your rounds of tapas and everything like that, getting that final check might take a little while. They did eventually filter in, though. Always a fun city here in Barcelona. I found some interesting pieces. Always love some customer studies. Conde Nast talking about what they've done with their digital imprint. CERN, who we're going to have on this program. As a science lover, you want to geek out as to how they're finding the Higgs boson and how things like Kubernetes are helping them there. And digging into things like storage, which I worked at a storage company for 10 years. So, understanding that storage is hard. Well, yeah. When containers came out, I was like, "Oh, god, we just fixed it for virtualization, "and it took us a decade. "How are we going to do it this time?" And they actually quoted a crowd chat that we had in our community. Tim Hawken, of course one of the first Kubernetes guys, was in on that. And we're going to have Tim on this afternoon, too. So, just to set a little context there. Jason, what's your impressions of the show? Anything that has changed in your mind from when you came in here to today? Let's get into it from there. >> Well, this is my second KubeCon. The first one I went to was in Seattle in December. What's interesting from a big picture is really how quickly and broadly KubeCon has been adopted in the enterprise. It's still, in the broader scheme of things, relatively new, but it's really taking its place as the only container orchestrator anybody cares about. It sort of squashed the 20-or-so alternative container orchestrators that had a brief day in the sun. And furthermore, large enterprises are rapidly adopting it. It's remarkable how many of them have adopted it and how broadly, how large the deployment. The Conde Nast example was one. But there are quite a number. So we turned the corner, even though it's relatively immature technology. That's the interesting story as well, that there's still pieces missing. It's sort of like flying an airplane while you're still assembling it, which makes it that much more exciting. >> Yeah, one of the things that has excited me over the last 10 years in tech is how fast it takes me to go from ideation to production, has been shrinking. Big data was: "Let's take the thing that used to take five years "and get it down to 18 months." We all remember ERP deployments and how much money and people you need to throw at that. >> It still takes a lot of money and people. >> Right, because it's ERP. I was talking to one of the booths here, and they were doing an informal poll of, "How many of you are going to have Kubernetes "in production in the next six months?" Not testing it, but in production in the next six months, and it was more than half of the people were going to be ramping it up in that kind of environment. Anything architecturally? What's intriguing you? What's the area that you're digging down to? We know that we are not fully mature, and even though we're in production and huge growth, there's still plenty of work to do. >> An interesting thing about the audience here is it's primarily infrastructure engineers. And the show is aimed at the infrastructure engineers, so it's technical. It's focused on people who code for a living at the infrastructure level, not at the application level. So you have that overall context, and what you end up having, then, is a lot of discussions about the various components. "Here's how we do storage." "Here's how we do this, here's how we do that." And it's all these pieces that people now have to assemble, as opposed to thinking of it overall, from the broader context, which is where I like writing about, in terms of the bigger picture. So the bigger picture is really that Cloud Native, broadly speaking, is a new architectural paradigm. It's more than just an architectural trend. It's set of trends that really change the way we think about architecture. >> One interesting piece about Kubernetes, as well. One of the things we're seeing as we see Kubernetes start to expand out is, unlike serverless, it doesn't necessarily require the same level of, oh, just take everything you've done and spend 18 months rewriting it from scratch, and then it works in this new paradigm in a better way. It's much less of a painful conversion process. We saw in the keynote today that they took WebLogic, of all things, and dropped that into Kubernetes. If you can do it with something as challenging, in some respects, and as monolithic as WebLogic, then almost any other stack you're going to see winds up making some sense. >> Right, you mentioned serverless in contrast with Kubernetes, but actually, serverless is part of this Cloud Native paradigm as well. So it's broader than Kubernetes, although Kubernetes has established itself as the container orchestration platform of choice. But it's really an overall story about how we can leverage the best practices we've learned from cloud computing across the entire enterprise IT landscape, both in the cloud and on premises. And Kubernetes is driving this in large part, but it's bigger picture than the technology itself. That's what's so interesting, because it's so transformative, but people here are thinking about trees, not the forest. >> It's an interesting thing you say there, and I'm curious if you can help our community, Because they look at this, and they're like, "Kubernetes, Kubernetes, Kubernetes." Well, a bunch of the things sit on Kubernetes. As they've tried to say, it's a platform of platforms. It's not the piece. Many of the things can be with Kubernetes but don't have to be. So, the whole observability piece. We heard the merging of the OpenCensus, OpenTracing with OpenTelemetry. You don't have to have Kubernetes for that to be a piece of it. It can be serverless underneath it. It can be all these other pieces. Cloud Native architecture sits on top of it. So when you say Cloud Native architecture, what defines that? What are the pieces? How do I have to do it? Is it just, I have to have meditated properly and had a certain sense of being? What do we have to do to be Cloud Native? >> Well, an interesting way of looking at it is: What we have subtracted from the equation, so what is intentionally missing. Cloud Native is stateless, it is codeless, and it is trustless. Now, not to say that we don't have ways of dealing with state, and of course there's still plenty of code, and we still need trust. But those are architectural principals that really percolate through everything we do. So containers are inherently stateless; they're ephemeral. Kubernetes deals with ephemeral resources that come and go as needed. This is key part of how we achieve the scale we're looking for. So now we have to deal with state in a stateless environment, and we need to do that in a codeless way. By codeless, I mean declarative. Instead of saying, how are we going to do something? Let's write code for that, we're going to say, how are we going to do that? Let's write a configuration file, a YAML file, or some other declarative representation of what we want to do. And Kubernetes is driven this way. It's driven by configuration, which means that you don't need to fork it. You don't need to go in and monkey with the insides to do something with it. It's essentially configurable and extensible, as opposed to customizable. This is a new way of thinking about how to leverage open-source infrastructure software. In the past, it was open-source. Let's go in an monkey with the code, because that's one of the benefits of open-source. Nobody wants to do that now, because it's declaratively-driven, and it's configurable. >> Okay, I hear what you're saying, and I like what you're saying. But one of the things that people say here is everyone's a little bit different, and it is not one solution. There's lots of different paths, and that's what's causing a little bit of confusion as to which service mesh, or do I have a couple of pieces that overlap. And every deployment that I see of this is slightly different, so how do I have my cake and eat it, too? >> Well, you mentioned that Kubernetes is a platform of platforms, and there's little discussion of what we're actually doing with the Kubernetes here at the show. Occasionally, there's some talk about AI, and there's some talk about a few other things, but it's really up to the users of Kubernetes, who are now the development teams in the enterprises, to figure out what they want to do with it and, as such, figure out what capabilities they require. Depending upon what applications you're running and the business use cases, you may need certain things more than others. Because AI is very different from websites, it's very different from other things you might be running. So that's part of the benefit of a platform of platforms, is it's inherently configurable. You can pick and choose the capabilities you want without having to go into Kubernetes and fork it. We don't want 12 different Kubernetes that are incompatible with each other, but we're perfectly okay with different flavors that are all based on the same, fundamental, identical code base. >> We take a look at this entire conference, and it really comes across as, yes, it's KubeCon and CloudNativeCon. We look at the, I think, 36 projects that are now being managed by this. But if we look at the conversations of what's happening here, it's very clear that the focus of this show is Kubernetes and friends, where it tends to be taking the limelight of a lot of this. One of the challenges you start seeing as soon as you start moving up the stack, out through the rest of the stack, rather, and seeing what all of these Cloud Native technologies are is, increasingly, they're starting to be defined by what they aren't. I mean, you have the old saw of, serverless runs on servers, and other incredibly unhelpful sentiments. And we talk about what things aren't more so than we do what they are. And what about capabilities story? I don't have an answer for this. I think it's one of those areas where language is hard, and defining what these things are is incredibly difficult. But I see what you're saying. We absolutely are seeing a transformative moment. And one of the strangest things about it, to me at least, is the enthusiasm with which we're seeing large enterprises, that you don't generally think of as being particularly agile or fast-moving, are demonstrating otherwise. They're diving into this in fascinating ways. It's really been enlightening to have conversations for the last couple of days with companies that are embracing this new paradigm. >> Right. Well, in our perspective at Intellyx, we're focusing on digital transformation in the enterprise, which really means putting the customer first and having a customer-driven transformation of IT, as well as the organization itself. And it's hard to think in those terms, in customer-facing terms, when you're only talking about IT infrastructure. Be that as it may, it's still all customer-driven. And this is sometimes the missing piece, is how do we connect what we're doing on the infrastructure side with what customers require from these companies that are implementing it? Often, that missing piece centers on the workload. Because, from the infrastructure perspective, we have a notion of a workload, and we want workload portability. And portability is one of the key benefits of Kubernetes. It gives us a lot of flexibility in terms of scalability and deployment options, as well as resilience and other benefits. But the workload also represents the applications we're putting in front of our end users, whether they're employees or end customers. So that's they key piece that is like the keystone that ties the digital story, that is the customer-facing, technology-driven, technology-empowered story, with the IT infrastructure stories. How do we support the flexibility, scalability, resilience of the workloads that the business needs to meet its business goals? >> Yeah, I'm really glad you brought up that digital transformation piece, because I have two questions, and I want to make sure I'm allowing you to cover both of them. One is, the outcome we from people as well: "I need to be faster, and I need to be agile." But at the same point, which pieces should I, as an enterprise, really need to manage? Many of these pieces, shouldn't I just be able to consume it as a managed service? Because I don't need to worry about all of those pieces. The Google presentation this morning about storage was: You have two options. Path one is: we'll take care of all of that for you. Path two is: here's the level of turtles that you're going to go all the way down, and we all know how complicated storage is, and it's got to work. If I lose my state, if I lose my pieces there, I'm probably out of business or at least in really big trouble. The second piece on that, you talked about the application. And digital transformation. Speed's great and everything, but we've said at Wikibon that the thing that will differentiate the traditional companies and the digitally transformed is data will drive your business. You will have data, it will add value of business, and I don't feel that story has come out yet. Do you see that as the end result from this? And apologies for having two big, complex questions here for you. >> Well, data are core to the digital transformation story, and it's also an essential part of the Kubernetes story. Although, from the infrastructure perspective, we're really thinking more about compute than about data. But of course, everything boils down to the data. That is definitely always a key part of the story. And you're talking about the different options. You could run it yourself or run it as a managed service. This is a key part of the story as well, is that it's not about making a single choice. It's about having options, and this is part of the modern cloud storage. It's not just about, "Okay, we'll put everything in one public cloud." It's about having multiple public clouds, private clouds, on-premises virtualization, as well as legacy environments. This is what you call hybrid IT. Having an abstracted collection of environments that supports workload portability in order to meet the business needs for the infrastructure. And that workload portability, in the context of multiple clouds, that is becoming increasingly dependent on Kubernetes as an essential element of the infrastructure. So Kubernetes is not the be-all and end-all, but it's become an essentially necessary part of the infrastructure, to make this whole vision of hybrid IT and digital transformation work. >> For now. I mean, I maintain that, five years from now, no one is going to care about Kubernetes. And there's two ways that goes. Either it dries up, blows away, and something else replaces it, which I don't find likely, or, more likely, it slips beneath the surface of awareness for most people. >> I would agree, yeah. >> The same way that we're not sitting here, having an in-depth conversation about which distribution of Linux, or what Linux kernel or virtual memory manager we're working with. That stuff has all slipped under the surface, to the point where there are people who care tremendously about this, but you don't need to employ them at every company. And most companies don't even have to think about it. I think Kubernetes is heading that direction. >> Yeah, it looks like it. Obviously, things continue to evolve. Yeah, Linux is a good example. TCP/IP as well. I remember the network protocol wars of the early 90s, before the web came along, and it was, "Are we going to use Banyan VINES, "are we going to use NetWare?" Remember NetWare? "Or are we going to use TCP/IP or Token Ring?" Yeah! >> Thank you. >> We could use GDP, but I don't get it. >> Come on, KOBOL's coming back, we're going to bring back Token Ring, too. >> KOBOL never went away. Token Ring, though, it's long gone. >> I am disappointed in Corey, here, for not asking the question about portability. The concern we have, as you say: okay, I put Kubernetes in here because I want portability. Do I end up with least-common-denominator cloud? I'm making a decision that I'm not going to go deep on some of the pieces, because nice as the IPI lets things through, but we understand if I need to work across multiple environments, I'm usually making a trade-off there. What do you hear from customers? Are they aware that they're doing this? Is this a challenge for people, not getting the full benefit out of whichever primary or whichever clouds they are using? >> Well, portability is not just one thing. It's actually a set of capabilities, depending upon what you are trying to accomplish. So for instance, you may want to simply support backing up your workload, so you want to be able to move it from here to there, to back it up. Or you may want to leverage different public clouds, because different public clouds have different strengths. There may be some portability there. Or you may be doing cloud migration, where you're trying to move from on-premises to cloud, so it's kind of a one-time portability. So there could be a number of reasons why portability is important, and that could impact what it means to you, to move something from here to there. And why, how often you're going to do it, how important it is, whether it's a one-to-many kind of thing, or it's a one-to-one kind of thing. It really depends on what you're trying to accomplish. >> Jason, last thing real quick. What research do you see coming out of this? What follow-up? What should people be looking for from Intellyx in this space in the near future? >> Well, we continue to focus on hybrid IT, which include Kubernetes, as well as some of the interesting trends. One of the interesting stories is how Kubernetes is increasingly being deployed on the edge. And there's a very interesting story there with edge computing, because the telcos are, in large part, driving that, because of their 5G roll-outs. So we have this interesting confluence of disruptive trends. We have 5G, we have edge computing, we have Kubernetes, and it's also a key use case for OpenStack, as well. So it's like all of these interesting trends are converging to meet a new class of challenges. And AI is part of that story as well, because we want to run AI at the edge, as well. That's the sort of thing we do at Intellyx, is try to take multiple disruptive trends and show the big picture overall. And for my articles for SiliconANGLE, that's what I'm doing as well, so stay tuned for those. >> All right. Jason Bloomberg, thank you for helping us break down what we're doing in this environment. And as you said, actually, some people said OpenStack is dead. Look, it's alive and well in the Telco space and actually merging into a lot of these environments. Nothing ever dies in IT, and theCUBE always keeps rolling throughout all the shows. For Corey Quinn, I'm Stu Miniman. We have a full-packed day of interviews here, so be sure to stay with us. And thank you for watching theCUBE. (upbeat techno music)

>> 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. This is theCUBE's coverage of KubeCon, CloudNativeCon 2019. I'm Stu Miniman, my co-host for two days wall-to-wall coverage is Corey Quinn. Happy to welcome back to the program first Ben Sigelman, who is the co-founder and CEO of LightStep. And welcome to the program a first time Morgan McLean, who's a product manager at Google Cloud Platform. Gentlemen, thanks so much for joining us. >> Thanks for having us. >> Yeah. >> All right so, this was a last minute ad for us because you guys had some interesting news in the keynote. I think the feedback everybody's heard is there's too many projects and everything's overlapping, and how do I make a decision, but interesting piece is OpenCensus, which Morgan was doing, and OpenTracing, which Ben and LightStep were doing are now moving together for OpenTelemetry if I got it right. >> Yup. >> So, is it just everybody's holding hands and singing Kumbaya around the Kubernetes campfire, or is there something more to this? >> Well I mean, it started when the CNCF locked us in a room and told us there were too many projects. (Stu and Ben laughing) Really wouldn't let us leave. No, to be fair they did actually take us to a room and really start the ball rolling, but conversations have picked up for the last few months and personally I'm just really excited that it's gone so well. Initially if you told me six or nine months ago that this would happen, I would've been, given just the way the projects were going, both were growing very quickly, I would've been a little skeptical. But seriously, this merger's gone beyond my wildest dreams. It's awesome, both to unite the communities, it's awesome to unite the projects together. >> What has the response been from the communities on this merger? >> Very positive. >> Yeah. >> Very positive. I mean OpenTracing and OpenCensus are both projects with healthy user bases that are growing quickly and all that, but the reason people adopt them is to future-proof their own software. Because they want to adopt something that's going to be here to stay. And by having these two things out in the world that are both successful, and were overlapping in terms of their goals, I think the presence of two projects was actually really problematic for people. So, the fact that they're merging is net positive, absolutely for the end user community, also for the vendor community, it's a similar, it's almost exactly the same parallel thought process. When we met, the CNCF did broker an in-person meeting where they gave us some space and we all got together and, I don't know how many people were there, like 20 or 30 people in that room. >> They did let us leave the room though, yesterday, yeah that was nice. >> They did let us leave the room, that's true. We were not locked in there, (Morgan laughing) but they asked us in the beginning, essentially they asked everyone to state what their goals were. And almost all of us really had the same goal, which is just to try and make it easy for end users to adopt a telemetry project that they can stick with for the long haul. And so when you think of it in that respect, the merger seems completely obvious. It is true that it doesn't happen very often, and we could speculate about why that is. But I think in this case it was enabled by the fact that we had pretty good social relationships with OpenCensus people. I think Twitter tends to amplify negativity in the world in general, as I'm sure people, not a controversial statement. >> News alert, wait, absolutely the negatives are, it's something in the algorithm I think. >> Yeah, yeah. >> Maybe they should fix that. >> Yeah, yeah (laughs) exactly. And it was funny, there was a lot of perceived animosity between OpenTracing and OpenCensus a year ago, nine months ago, but when you actually talk to the principals in the projects and even just the general purpose developers who are doing a huge amount of work for both projects, that wasn't a sentiment that was widely held or widely felt I think. So, it has been a very kind of happy, it's a huge relief frankly, this whole thing has been a huge relief for all of us I think. >> Yeah it feels like the general ask has always been that, for tracing that doesn't suck. And that tends to be a bit of a tall order. The way that they have seemed to have responded to it is a credit to the maturity of the community. And I think it also speaks to a growing realization that no one wants to have a monoculture of just one option, any color you want so long as it's black. (Ben laughing) Versus there's 500 different things you can pick that all stand in that same spot, and at that point analysis paralysis kicks in. So this feels like it's a net positive for, absolutely everyone involved. >> Definitely. Yeah, one of the anecdotes that Ben and I have shared throughout a lot of these interviews is there were a lot of projects that wanted to include distributed tracing in them. So various web frameworks, I think, was it Hadoop or HBase was-- >> HBase and HDFS were jointly deciding what to do about instrumentation. >> Yeah, and so they would publish an issue on GitHub and someone from OpenTracing would respond saying hey, OpenTracing does this. And they'd be like oh, that's interesting, we can go build an implementation file and issue, someone from OpenCensus would respond and say, no wait, you should use OpenCensus. And with these being very similar yet incompatible APIs, these groups like HBase would sit it and be like, this isn't mature enough, I don't want to deal with this, I've got more important things to focus on right now. And rather than even picking one and ignoring the other, they just ignored tracing, right? With things moving to microservices with Kubernetes being so popular, I mean just look at this conference. Distributed tracing is no longer this kind of nice to have when you're a big company, you need it to understand how your app works and understand the cause of an outage, the cause of a problem. And when you had organizations like this that were looking at tracing instrumentation saying this is a bit of joke with two competing projects, no one was being served well. >> All right, so you talked about there were incompatible APIs, so how do we get from where we were to where we're going? >> So I can talk about that a little bit. The APIs are conceptually incredibly similar. And the part of the criteria for any new language, for OpenTelemetry, are that we are able to build a software bridge to both OpenTracing and OpenCensus that will translate existing instrumentation alongside OpenTelemetry instrumentation, and omit the correct data at the end. And we've built that out in Java already and then starting working a few other languages. It's not a tremendously difficult thing to do if that's your goal. I've worked on this stuff, I started working on Dapper in 2004, so it's been 15 years that I've been working in this space, and I have a lot of regrets about what we did to OpenTracing. And I had this unbelievably tempting thing to start Greenfield like, let's do it right this time, and I'm suppressing every last impulse to do that. And the only goal for this project technically is backwards compatibility. >> Yeah. >> 100% backwards compatibility. There's the famous XKCD comic where you have 14 standards and someone says, we need to create a new standard that will unify across all 14 standards, and now you have 15 standards. So, we don't want to follow that pattern. And by having the leadership from OpenTracing and OpenCensus involved wholesale in this new effort, as well as having these compatibility bridges, we can avoid the fate of IPv6, of Python 3 and things like that. Where the new thing is very appealing but it's so far from the old thing that you literally can't get there incrementally. So that's, our entire design constraint is make sure that backwards compatibility works, get to one project and then we can think about the grand unifying theory of a provability-- >> Ben you are ruining the best thing about standards is that there is so many of them to choose from. (everyone laughing) >> There's still plenty more growing in other areas (laughs) just in this particular space it's smaller. >> One could argue that your approach is nonstandard in its own right. (Ben laughing) And in my own experiments with distributed tracing it seems like step one is, first you have to go back and instrument everything you've built. And step two, hey come back here, because that's a lot of work. The idea of an organization going back and reinstrumenting everything they've already instrumented the first time. >> It's unlikely. >> Unless they build things very modularly and very portably to do exactly that, it's a bit of a heavy lift. >> I agree, yeah, yeah. >> So going forward, are people who have deployed one or the other of your projects going to have to go back and do a reinstrumentation, or will they unify and continue to work as they are? >> So, I would pause at the, I don't know, I would be making up the statistic, so I shouldn't. But let's say a vast majority, I'm thinking like 95, 98% of instrumentation is actually embedded in frameworks and libraries that people depend on. So you need to get Dropwizard, and Spring, and Django, and Flask, and Kafka, things like that need to be instrumented. The application code, the instrumentation, that burden is a bit lower. We announced something called SpecialAgent at LightStep last week, separate to all of this. It's kind of a funny combination, a typical APM agent will interpose on individual function calls, which is a very complicated and heavyweight thing. This doesn't do any of that, but it takes, it basically surveys what you have in your process, it looks for OpenTracing, and in the future OpenTelemetry instrumentation that matches that, and then installs it for you. So you don't have to do any manual work, just basically gluing tab A into slot B or whatever, you don't have to do any of that stuff which is what most OpenTracing instrumentation actually looks like these days. And you can get off the ground without doing any code modifications. So, I think that direction, which is totally portable and vendor neutral as well, as a layer on top of telemetry makes a ton of sense. There are also data translation efforts that are part of OpenCensus that are being ported in to OpenTelemetry that also serve to repurpose existing sources of correlated data. So, all these things are ways to take existing software and get it into the new world without requiring any code changes or redeploys. >> The long-term goal of this has always been that because web framework and client library providers will go and build the instrumentation into those, that when you're writing your own service that you're deploying in Kubernetes or somewhere else, that by linking one of the OpenTelemetry implementations that you get all of that tracing and context propagation, everything out of the box. You as a sort of individual developer are only using the APIs to define custom metrics, custom spans, things that are specific to your business. >> So Ben, you didn't name LightStep the same as your project. But that being said, a major piece of your business is going through a change here, what does this mean for LightStep? >> That's actually not the way I see it for what it's worth. LightStep as a product, since you're giving me an opportunity to talk about it, (laughs) foolish move on your part. No, I'm just kidding. But LightStep as a product is totally omnivorous, we don't really care where the data comes from. And translating any source of data that has a correlation ID and a timestamp is a pretty trivial exercise for us. So we do support OpenTracing, we also support OpenCensus for what it's worth. We'll support OpenTelemetry, we support a bunch of weird in-house things people have already built. We don't care about that at all. The reason that we're pursuing OpenTelemetry is two-fold, one is that we do want to see high quality data coming out of projects. We said at the keynote this morning, but observability literally cannot be better than your telemetry. If your telemetry sucks, your observability will also suck. It's just definitionally true, if you go back to the definition of observability from the '60s. And so we want high quality telemetry so our product can be awesome. Also, just as an individual, I'm a nerd about this stuff and I just like it. I mean a lot of my motivation for working on this is that I personally find it gratifying. It's not really a commercial thing, I just like it. >> Do you find that, as you start talking about this more and more with companies that are becoming cloud-native rapidly, either through digital transformation or from springing fully formed from the forehead of some God, however these born in the cloud companies tend to be, that they intuitively are starting to grasp the value of tracing? Or does this wind up being a much heavier lift as you start, showing them the golden path as it were? >> It's definitely grown like I-- >> Well I think the value of tracing, you see that after you see the negative value of a really catastrophic outage. >> Yes. >> I mean I was just talking to a bank, I won't name the bank but a bank at this conference, and they were talking about their own adoption of tracing, which was pretty slow, until they had a really bad outage where they couldn't transact for an hour and they didn't know which of the 200 services was responsible for the issue. And that really put some muscle behind their tracing initiative. So, typically it's inspired by an incident like that, and then, it's a bit reactive. Sometimes it's not but either way you end up in that place eventually. >> I'm a strong proponent of distributed tracing and I feel very seen by your last answer. (Ben laughing) >> But it's definitely made a big impact. If you came to conferences like this two years ago you'd have Adrian, or Yuri or someone doing a talk on distributed tracing. And they would always start by asking the 100 to 200 person audience, who here knows what distributed tracing is? And like five people would raise their hand and everyone else would be like no, that's why I'm here at the talk, I want to find out about it. And you go to ones now, or even last year, and now they have 400 people at the talk and you ask, who knows what distributed tracing is? And last year over half the people would raise their hand, now it's going to be even higher. And I think just beyond even anecdotes, clearly businesses are finding the value because they're implementing it. And you can see that through the number of companies that have an interest in OpenTracing, OpenTelemetry, OpenCensus. You can see that in the growth of startups in this space, LightStep and others. >> The other thing I like about OpenTelemetry as a name, it's a bit of a mouthful but that's, it's important for people to understand the distinction between telemetry and tracing data and actual solutions. I mean OpenTelemetry stops when the correct data is being omitted. And then what you do with that data is your own business. And I also think that people are realizing that tracing is more than just visualizing a single distributed trace. >> Yeah. >> The traces have an enormous amount of information in there about resource usage, security patterns, access patterns, large-scale performance patterns that are embedded in thousands of traces, that sort of data is making its way into products as well. And I really like that OpenTelemetry has clearly delineated that it stops with the telemetry. OpenTracing was confusing for people, where they'd want tracing and they'd adopt OpenTracing, and then be like, where's my UI? And it's like well no, it's not that kind of project. With OpenTelemetry I think we've been very clear, this is about getting >> The name is more clear yeah. >> very high quality data in a portable way with minimal effort. And then you can use that in any number of ways, and I like that distinction, I think it's important. >> Okay so, how do we make sure that the combination of these two doesn't just get watered-down to the least common denominator, or that Ben just doesn't get upset and say, forget it, I'm going to start from scratch and do it right this time? (Ben laughing) >> I'm not sure I see either of those two happening. To your comment about the least common denominator, we're starting from what I was just commenting about like two years ago, from very little prior art. Like yeah, you had projects like Zipkin, and Zipkin had its own instrumentation, but it was just for tracing, it was just for Zipkin. And you had Jaeger with its own. And so, I think we're so far away, in a few years the least common denominator will be dramatically better than what we have today. (laughs) And so at this stage, I'm not even remotely worried about that. And secondly to some vendor, I know, because Ben had just exampled this, >> Some vendor, some vendor. >> that's probably not, probably not the best one. But for vendor interference in this projects, I really don't see it. Both because of what we talked about earlier where the vendors right now want more telemetry. I meet with them, Ben meets with 'em, we all meet with 'em all the time, we work with them. And the biggest challenge we have is just the data we get is bad, right? Either we don't support certain platforms, we'll get traces that dead end at certain places, we don't get metrics with the same name for certain types of telemetry. And so this project is going to fix that and it's going to solve this problem for a lot of vendors who have this, frankly, a really strong economic incentive to play ball, and to contribute to it. >> Do you see that this, I guess merging of the two projects, is offering an opportunity to either of you to fix some, or revisit if not fix, some of the mistakes, as they were, of the past? I know every time I build something I look back and it was frankly terrible because that's the kind of developer I am. But are you seeing this, as someone who's probably, presumably much better at developing than I've ever been, as the opportunity to unwind some of the decisions you made earlier on, out of either ignorance or it didn't work out as well as you hoped? >> There are a couple of things about each project that we see an opportunity to correct here without doing any damage to the compatibility story. For OpenTracing it was just a bit too narrow. I mean I would talk a lot about how we want to describe the software, not the tracing system. But we kind of made a mistake in that we called it OpenTracing. Really people want, if a request comes in, they want to describe that request and then have it go to their tracing system, but also to their metric system, and to their logging stack, and to anywhere else, their security system. You should only have to instrument that once. So, OpenTracing was a bit too narrow. OpenCensus, we've talked about this a lot, built a really high quality reference implementation into the product, if OpenCensus, the product I mean. And that coupling created problems for vendors to adopt and it was a bit thick for some end users as well. So we are still keeping the reference implementation, but it's now cleanly decoupled. >> Yeah. >> So we have loose coupling, a la OpenTracing, but wider scope a la OpenCensus. And in that aspect, I think philosophically, this OpenTelemetry effort has taken the best of both worlds from these two projects that it started with. >> All right well, Ben and Morgan thank you so much for sharing. Best of luck and let us know if CNCF needs to pull you guys in a room a little bit more to help work through any of the issues. (Ben laughing) But thanks again for joining us. >> Thank you so much. >> Thanks for having us, it's been a pleasure. >> Yeah. >> All right for Corey Quinn, I'm Stu Miniman we'll be back to wrap up our day one of two days live coverage here from KubeCon, CloudNativeCon 2019, Barcelona, Spain. Thanks for watching theCUBE. (soft instrumental music)

>> Live, from Barcelona Spain, it's theCube! Covering, KubeCon CloudNativeCon Europe 2019: Brought to you by RedHat, the Cloud Native Computing Foundation and the Ecosystem Partners. >> Hi, and welcome back. this is theCube's coverage of KubeCon CloudNativeCon 2019 here in Barcelona, Spain. We're at the end of day one of two days of live, wall-to-wall coverage. I'm Stu Miniman, and at the end of the day, what we try to do always is do our independent analysis and say what we really think. And joining me is someone that usually has no problem telling you exactly what he thinks online. So, I've challenged Mr. Corey Quinn. Cloud economist, of the Duckbill Group. and the curator, author, Last Week in AWS. To tell us what he actually thinks. >> Well, Stu, you know what your problem is. All the best feedback starts off that way. Now, this has been a fascinating experience for me. This is the first time I've ever been to KubeCon. I didn't quite know what to expect- >> It's KubeCon, not Koob-Con. Come on. It is in GitHub, how you have to make the pronunciation correct. >> We are on theCube. We would think that we would be subject matter experts on this. >> CNCF will be cracking down on you if I don't correct you on this. >> I still maintain we're in Barcelona, Italy. But that's a whole separate argument to have with other people. >> Yes, well, most Americans are geographically challenged. And we understand you have some challenges too. >> Exactly, most Americans need to learn geography, we go to war. (chuckling) >> All right, so, Corey, I guess the first question for you is, you usually go to mostly AWS shows. Most of the customers we've talked to have been AWS customers. So is this feeling much different from the usual show you go to? >> The focus of the conversations is different, and to be clear, I'm not much of a cloud partisan myself. I deal with AWS primarily because, not for nothing, that's where my customers are. That tends to be exactly where the expensive problems tend to live. For better or worse. If that changes, so will I. >> So, you're saying yet that the other cloud providers don't have their customers big enough bills, or they just haven't figured out how you might be able to help them in the future? >> To be very honest with you. Yes, is the short answer. Right now on aggregate, my customers spend about a billion dollars a year on AWS. I don't see the same order of magnitude on other providers, but it's coming. It is very clearly coming. None of these providers are shrinking as far as size goes. It's largely a matter of time. >> Alright. But Corey, I hope at least you've understood that Kubernetes at the center for all things. And that multi-cloud is the way that we are today and will always be in the future. And we should all hold hands and sing along, that we all get along. Is that what you've learned so far? >> I think that's absolutely what I've learned so far. It comes down to religion and it's perfectly name for it. I mean, Kubernetes was the Greek God of spending money on cloud services. >> All right. But seriously. Corey, I think one of the things that I really liked is. We talk to customers and there were some interesting things at least I heard when you talked about they see huge value in what they're doing with Kubernetes. Many of them only have one cloud provider today. Yet they are choosing to lay on Kubernetes either with AWS or with another solution there. What's been your take of what you've heard about. Kind of the why and what they're doing? >> There've been a few different reasons on it. One that resonated with me did validate what I talked about at the beginning of the day. Which was, that by trying to position yourself to be strategically amenable to any potential provider you might want to use in the future. You are sacrificing velocity. And you're gaining agility, losing velocity to do that. Is that trade off worth it? I don't think I'm qualified to judge. I think that's a decision every business has to make on its own. My argument has always been that if that's the decision you make, do it knowingly. And I don't think we've talked to anyone who's made that unknowingly today. >> Yeah. I think that's a really good point. What is it, you know, surprised you or interest you that we've heard so far? >> I have to be honest. I have a long and storied history in open source. I was staff at the Freenode IRC network for about a decade. Which was an interesting time. And I've seen a lot of stuff, but I don't think I've ever seen two open source projects merge before. The fact that we saw that today is still swirling around in my head for better or worse. >> Yeah. And it was OpenCensus and OpenTracing coming together. Open Telemetry. So, definitely check out Ben Siegelman. and it was Morgan McLean from a Google cloud. You know, really interested in discussion. I don't think we're sharing too much when we say off camera. There were like, look, it's like, yes, they got us in a room and we worked, but we'll try not to throw punches here on the set and everything like that. We understand that look, there are people that put these things together and you have smart people that build things the way that it should be done. And these were not like two very similar projects going in the same direction, they were built with different design principles and therefore there'll be somethings that they all need to reconcile to be able to go forward. But yeah, very interesting. >> And everyone we spoke to today was very focused on what the needs of their customers, whoever they happen to be and how to meet those customers and their business requirements. There's no one that we spoke to that was sitting here saying, oh, this is the right answer because it is technically correct. The answer is we're always of the form. This is what we need to do in order to serve customers. And it's very hard to argue against that strategy. >> All right, but none of this really matters because Serverless, right Corey? >> Oh, absolutely. Serverless is the way and the light of the future and to some extent I believe that. >> But they're not doing Serverless. I'm pretty sure they're half a step behind you. Yes, it tends to be, it's easy to make go ahead and die and say, Oh, if you're not running the absolute latest bleeding edge thing, you're behind, you're backwards, etc. And I don't get that all the sense that that is reality. I think that there's, if you're building something greenfield today, you are fundamentally going to make different choices, than if you have something you're trying to carry forward. And I don't just mean carrying forward a technical sense. I mean carrying it forward in terms of process, in terms of culture, in terms of existing business units that need to modernize. People are moving in the same general direction. The question that I think is still on answered is, today, there's a perception rightly or wrongly, that Containers are slightly behind Serverless. I don't know that that necessarily holds true. I think that they are aligned towards the same business value. I think, judge either one of them by today's constraints in the context of longer term strategy is a mistake. I'm curious to see what happens. >> Corey, I love. So we had Jeff Brewer from Intuit and they were like look, we're doing Serverless, we're doing a lot of Containerless stuffs and I'd love it for my developer not to have to worry about. And they've had been moved down that path. So, we know one of the truisms out there is everything in IT is always additive. When you talk to them and say, oh, well I'm going into cloud wait, I still have some stuff that, running on my main frame or my eyes series. And that we'll probably be running there when I've retired. We were talking offline. It's like, well, there's been a little resurgence in COBOL. Just because it did not die after Y2K and so did these things always come back and it's always additive and the longer you've been in business as a company, the more legacy you need to be able to maintain and extend and connect to where you want to go with the future. >> It's almost a sawtooth curve. As complexity continues to rise it becomes to a point where it's untenable. There's something that comes out that abstracts that away and you're back down to a level a human being might actually be able to understand. And you take it a step further and you start to see it again and again and again, and then it collapses down. Docker and a lot of the handbuilt orchestration systems were like that. And then Kubernetes came out. Initially it was fairly simple and then things have been added to it now. And I think we're climbing that sawtooth curve again. Whether or not that maintains? Whether or not that simplifies again? I find that history rhymes particularly in tech. >> Well yeah and I always worry sometimes when you talk about the abstraction layer you got to be really careful what you're abstracting. What we see here a lot, is a lot of times it's people, how can I just consume that? I want to buy it as a service and somebody take care of that not, it hides the complexity for me but some of the complexity is still there. >> Right. So our site is now intermittently slow what do you plan to do? Its update my resume immediately cause we're never untangling that Gordian knot of an infrastructure. That's not a great answer but it is an honest one in some shops. >> I've talked to, we know that there was, for a long time people outsourced what they were doing. And we need to make sure that when you're buying something as a service that you haven't outsourced, That you understand what's important to your business, what happens when things go wrong. We had some discussion today about, networking and observability that we need to be able to go down that rabbit hole, at least turn to somebody who can. Because just because I can't touch that gear doesn't mean my next not on the line, If something goes wrong. >> You can outsource a lot of work. You can't outsource responsibility. I put slightly more succinctly, the line I've always liked was you own your own availability. If you have a provider that you've thrown a lot of these things over to and they go down, well sure you're going to have loud angry phone calls and maybe a few bucks back from an SLA credit. We your customers we're down and we're suffering. So the choices you made impact your businesses perception in the market and your customer's happiness. So as much as fun as it is to be able to throw things over the wall for someone else to deal with, you're still responsible. And I think that people forget that at their own peril. >> One of the things I like. I've got a long history in open source to. If there are things that aren't perfect or things that are maturing. A lot of times we're talking about them in public. Because there is a roadmap and people are working on it and we can all go to the repositories and see where people are complaining. So at a show like this, I feel like we do have some level of transparency and we can actually have realism here. What's been your experience so far? >> I think that people have been remarkably transparent about the challenges that they're facing in a way that you don't often get at a vendor show. Where you have a single vendor, you're at their show, regardless of who that might be. You're not going to be invited back if you wind up with a litany of people coming on a video show or a podcast or screaming and sobbing in the bathroom, however you want to, whatever your media is. Just have a litany of complaints the entire time or make that provider look bad. I don't sense that there's any of that pressure. And for some reason, and this is my first coop gone, so maybe this is just the way this culture it works. Everyone, regardless of who they worked for or what they're working on or what their experience has been, seems happy. I can only assume there's something in the water. >> All right. Well, I've just been informed that the CNCF had asked me to remove Corey because he refuses to say KubeCon. But, Corey. Since this might be your last time on the program, any other final words that you have for it or I will let you do something very rare and if you have any questions for me. Love on my way. >> Absolutely. What did you find today that you didn't expect to find? >> The one that jumps out for me really is two things. One, we discussed it already is the, the observability piece coming together. The other one is. You talk about that maturation of where Amazon fits in this ecosystem. And we had lovely conversation, with Abby fuller. But not just that one. We talked to the users and how they think about it. Which is what really matters is, there's so much talk about, who contributes more code and who does the most here. But look, we're talking cloud. Most of these customers are using AWS as if not the cloud, one of the clouds. I've set it on theCube many times. When you live in a hybrid and multi-cloud world and the public cloud, AWS is the far leader. There's no debating that. So they are participating here. They are doing plenty for what their customers want and they give choice and they listen to the feedback. So that was interesting to me that maturation of where that sits because when I come into the show and many times it is, it is the open source in this whole ecosystem, trying to prevent Amazon from taking over the world. And look, we want a good robust ecosystem out there. >> We absolutely do. >> While I have many friends that work for Amazon. We probably don't want to all be working for a single company down the road. >> I certainly don't. >> We like a nice robust ecosystem where there is choice out there and that keeps its (mumbles). So that maturation of where they are on has been interesting to me so far, especially from the user stand point. >> Very much so. I don't think that anyone wants to look back and say, wow, I'm sure glad we have only one option in this entire space that does anything useful. And then a whole bunch of could have the didn't. And for better or worse, I don't think that the future is nearly as clear cut as the past of cloud. Historically, AWS has been the 800 pound gorilla. I think that we hearing fascinating things from GCP and from Azure. I don't necessarily think that the future is preordained. I do think right now it is AWS game to lose, but I'm starting to see a lot of other players in his face start to make a lot of very interesting and arguably very correct moves. >> All right. Well, we know you as our audience have lots of places where you can turn to find your information and we are always pleased that when you turn to us to watch theCube. if you have any feedback for ourselves, Corey Quinn and myself, Stu Miniman. Reach out on Twitter. We are easy to reach on that. And we have lots of posts. So if you're like, Hey, tired of looking at this mug here. Let us know. But hopefully we're asking the questions and digging into the areas that you want and we'll help your businesses going forward. So we are at the end of day one, Two days live coverage here at KubeCon CloudNativeCon. This is the cube. You're a leader in live tech coverage. Thanks for watching. (music)

(upbeat music) >> Narrator: Live from the Seattle, Washington, it's the Cube on the ground, covering KubeCon 2016. Brought to you by the Linux Foundation and Red Hat. Here's your host, John furrier. >> Hello, everyone. Welcome to the Cube special on the ground coverage of KubeCon or CloudNativeCon, this is an event. Seattle booming with attendance, great growth from last year, and we are here in Seattle covering it all. And my next guest is Dan Kohn, who's the executive director of the CNCF, which stands for the Cloud Native Computing Foundation. It's a mouthful, but it's super important part of the Linux foundation. Welcome. >> Thanks so much, really glad to be here. >> Yeah, so big fan of what's happening here. One, the event's awesome. Great uptake from last attendance from last year. >> Yeah, unfortunately, maybe a little too much. We're a little crowded in the foyer and a little bumping on the way into getting in the restroom and everything, but it's one of the challenges of fast growing technology space is trying to figure out a year ahead of time, what size space to get? >> And how many people to squeeze in without getting the fire marshal on your back. >> Exactly. >> Certainly this is going to be a great one because the hallway conversation has been spectacular, and normally the excitement's pretty strong at tech events like this because they're developers, so there's a lot of collaboration going on. But you have a kind of an air of really forward-thinking entrepreneurial kind of thinking going on here. And I haven't seen that in a while and I think that's one of the main things that we're seeing that came out of the containers, Kubernetes. I would say the unveiling and the clarity of at least a path. >> Yes, absolutely. >> And the importance of that. So that's been super important to (indistinct) community. Now making that a part of a foundation, an open source, has challenges. So that's what you're doing. So give us the plan, what's the strategy? >> Sure, so I'm actually relatively new to the space. I just became an executive director five months ago, and this is somewhat of a coming out party. This is the first big event that we've run as the first CloudNativeCon. And it's really just been extraordinary. I'm thrilled to see the range where we're getting some of the biggest companies in the world of the Cisco's, and Wallway's, and IBM's, Red Hat's and such. And then tons of startups, and a lot of real diversity in the end-users as well. Of startups looking at Kubernetes, massive companies, just saw a great presentation from Ticketmaster, about them having 50 year old technology that they're moving forward and putting into containers. >> So in the growth of the market, one of the challenges is to kind of, you know, not so much be a chess player, but be a gardener if you will, kind of like let the flowers bloom, if you will. And that's a challenge cause opensource is very opinionated, but there's also a lot of passion involved. So how do you look at, what's your philosophy on establishing kind of a rules of engagement? How do you foster the innovation? Certainly the market drivers are for more growth, but people have inhibitors on the enterprise that we hear about, support and these things of that nature. So how do you enable that? What's your strategy and what's your view? >> Sure, so CNCF is a very new organization. And my goal on it is to look at a lot of the giants that have come before us of like the Internet Engineering Task Force and the Apache Software Foundation and OpenStack. And my goal is to try and learn from them and ideally to try and make entirely new and different mistakes as opposed to the ones that they may have made in the past. So one of the things that's a little unusual in our setup is that we very much separate all of the technology decisions from the business decisions. We have a governing board of a bunch of the biggest technology companies in the world, the ones I mentioned, plus Google and Samsung just joined, which we're very excited about, a number of others. But they can't actually adopt projects in. So we have a separate group called the technical oversight committee, which is some of the top architects in the cloud space. So we have folks like Ben Hindman of Mesosphere, and Solomon Hykes of Docker, Brian Gantt of Google, and six others, and that's the group that looks at new projects and evaluates them and talks to them and decides whether to adopt them into CNCF or not. And we feel that that separation is really critical so that the technology decisions are not being biased by the business one. >> Yeah, it's always hard to foster growth in the innovation around business models, conflicting with the technology enablement, that's really key. Great to see that decoupling. So on the business model side, thoughts on things that you've learned and observed, learnings that you've had in your past career and applying that now, I mean, the Bait, the rage is on, Open Core to Apache, GPL, you saw some things going on there. So there's like all kinds of different approaches. Are there any thoughts of the winds blowing any which way or the other? >> Sure, I was previously the chief operating officer at the Linux Foundation between '06 and '10, and I definitely think you can, CNCF as part of the Linux Foundation, we took that model of saying, "the technology decisions "need to be separate from business ones." One thing that's interesting to me is that when I was last in this space 10 years ago, people were perfectly fine. Linux Journals, GPL, people were fine with free licenses like MIT and BSD. Since then, and for this group, there is an enormous focus on the Apache license. And the reason why, is the fear of submarine patents. And so the whole goal of CNCF is for us to be an intellectual property no fly zone. That you can have all of these companies that compete very hard in the marketplace, but they can come together and collaborate and share their ideas and their technology without the belief that a couple years later, someone's going to be able to trick someone else in with a lawsuit, and win that. And the Apache license is really the industry consensus right now for best practices. >> It's interesting cause that no fly zone gives the freedom for the creation and the invention side of it. The patent thing is always worrisome, but in general, there's also the business model down the road kind of approach. Which is, "let's go innovate." Apache has done great on packaging. Have someone get some traction. It fosters the community aspect as well as a startup. Maybe not thinking about packaging. >> No, we have an advantage that we're not, unlike OpenStack as an example, we're not trying to come up with the projects ourself. What we're actually doing is scouring the Cloud Native landscape, talking to different groups and saying, "Oh, what do we think is "the best in class project out there?" And in some cases it's more than one, but today we just announced the fourth project that's added to the CNCF. So we have Kubernetes, we have Prometheus, which is a monitoring application. OpenTracing is a tracing, and then today we just added Fluentd, which is a logging solution. And this is the idea that if you have dozens or hundreds of different applications and projects that are each producing a log stream, and then you have a perhaps dozens of other applications that are consuming it, you don't want to have an M times N problem of creating adapters for all of them. Instead, you can plug them all into Fluentd, it has over 300 adapters for different solutions out there. And that provides one comprehensive approach. But what's interesting is that we don't need to win over the community and say, "Oh, here's this project you may not have heard of." There's actually over 2000 users of that today. But by having them here at CNCF, showing how it plugs into other technologies of ours, we think we can hope-- >> You're cross-pollinating? >> Dan: Exactly. >> You're letting it bubble up and you're not being a-- >> Dan: That's exactly the metaphor. >> (laughs) A dictator. Okay, and back to the project side, this is awesome. So you have some gravity around these projects. Is there any cadence or expectation, or is it free for all in terms of the velocity of adoption of projects that the technical committee will oversight? >> We would love to be at the pace of one a month. And I don't know that we'll quite get that fast. One big change that we're hoping to make in the next month or two. When our first two projects were Kubernetes and Prometheus, those are two of the fastest growing best respected projects on GitHub right now. We didn't want to have such a high milestone for every other project we considered. So we're adopting what we think we're going to call an inception stage of earlier projects that we're going to sort of try out, but they have to essentially prove themselves within 12 months. And hopefully that'll allow us to keep a pretty good velocity where we think there's a fantastic number of projects, we think as a community, we can-- >> Yeah, let people fight it out, surface stuff and let people kick the tires, right? That's the incubation period basically. What about the forking and all the battle cage matches that go on, how do you want to handle that or you just let nature take its course? Is that philosophy there? >> Thankfully, when we look at the space and this is really coming out of the Linux Space as well, anyone can fork, and of course it has a slightly different connotation now with GitHub, where when you make a change, you fork it, but there's also just a massive centripetal force pushing people together. And when you have a really high velocity of changes, the idea of forking and you would lose out on that, becomes a lot less appealing. And so, so far thankfully, all of our members and everyone in the community has really been on board on having a single head on working together to have that consultation. >> We just had Richard Kaufman on from, I think Robert Kaufman, I mean, from Samsung, he was talking about that the number two contributor is other. >> Dan: Yes. >> Which is a nice balance to the whole critical mass. >> It's an incredible accomplishment cause for Google to pull in enough people that they're no longer the majority contributor, is something that we're thrilled with. >> Yeah, it's great to see you have Richard Kaufman. Google is the number one contributor, are you worried about that? Maybe, they've been certainly good actors in the community. I mean, they had MapReduce and let Cloudera run with it, look at what happened with that? So, we kind of all know this backstory of Kubernetes, they're kind of letting it bloom on its own. That's consistent with their current posturing? >> Well, I don't think they want to have another Cloudera. >> Which is why they embraced Kubernetes. >> But I definitely don't think it's fair to say that they're doing it on their own. They're still the largest contributor of any one company and they have a massive amount of resources, and I think they see it as a really key technology, it's something they mentioned-- >> What I was referring to is that Cloudera kind of took MapReduce under their wing and made a commercial venture out. >> Dan: Oh yeah, absolutely. >> I think Google didn't want that. >> No, and they, I mean, the way I think about it is, they had this technology a few years ago. This is definitely oversimplified. They could have kept it as a proprietary in the house thing, like Amazon Elastic Container Service. They could have made it an internal open source project, like Go, or they could have just created a Kubernetes foundation that allowed other people in, but they still controlled it. But instead they were really interested in working with the Linux Foundation and creating this Cloud Native Computing Foundation that was always designed to be much more than just Kubernetes. And that really was about trying to push the project out of the nest. But I will say that my understanding is they're still see that as an absolutely core for their business. >> Yeah, I got to give Google props out there for that because they did do the right thing there. they put it out in the open, they did a line, and they could have land grabbed that, in a different way, I mean, certainly not the way that one was above. Final question on this event, KubeCon or KubernetesCon, KubeCon, it's KubeCon, however people call it. Not to confuse with the Cube, this Cube product which is seven years and might be trademark infringement but yeah, we'll get that later. >> Dan: With a K. (both laughing) >> It's still causing a lot of confusion. But that aside, CloudNativeCon also is in conjunction, this is part of the expansion you were mentioning. Talk about the vision for the events, you got one in Berlin coming up, and certainly you could have had probably at least a few more thousand people here for sure. >> Oh well, certainly a few more hundred. And we do feel a little bad that we didn't quite aim high enough. So our vision going forward is that we have CloudNativeCon that represents all of our projects, and that KubeCon represents the biggest part of CloudNativeCon. So it's multiple tracks. It's what a ton of folks go for but we think that it also gives us a chance to expose those people to our other projects, and by the time we get to Berlin, we're certainly hoping that we have another two or three or more projects-- >> And the date on Berlin? >> It's March 29th and 30th. And then we also announced that we're going to be in Austin, in early December. And I'll say that for both of those events, we're tripling the capacity from what we had last year. So we're hoping not to be so crowded. >> I was talking to Andy Jassy last night, we had a one-on-one with him and he's talking about the first Reinvent, he didn't think he can get 4,000 people there as packed. I think you might be, having to look at more capacity potentially. I mean, at this pace. >> It's the hard question is we'd actually like to be signing contracts for 2018, and it's just really hard to predict what the right size is to get for that, because I feel terrible about the fact that we did turn people away, especially end-users that we'd like to be introducing to this space. >> Yeah, well, I can attest people watching this, definitely a fire marshal issue, because it's really packed. That's why we're in a separate room here. There was sunlight in the background earlier. Normally, we're on the show floor with the Cube, but yeah, every space is taken, hallways are jamming. >> The other thing I'll mention though, is that we are also interested in going out and reaching customers and vendors where they are. So we're going to have a booth at AWS Reinvent, and we're looking at other conferences that we can be at to help spread the Cloud Native word. >> We're certainly going to be able to have a hundred events this year, so let us know where you're at, we'll certainly bring you guys on. Let me give you the final word. Tell the folks why Kubernetes is so important. Why is this movement, why are people so excited here? For the folks that couldn't make it, what's the vibe, why is it important, and what's the impact to customers in the industry? >> So the belief is that if you're deploying a new modern software application that, putting into containers, using an orchestration platform like Kubernetes, dividing your app up into microservices is a really such a benefit in terms of optimizing your resources, and tying into a whole rapid development process, continuous integration, continuous deployment, that not doing it almost makes it impossible to compete. And so we think there's just a ton of momentum around containerization and orchestration. >> And the speed of the innovation is one of those things if you're not on it, you fall further behind and it takes more energy to catch up if you try to do it by yourself. That's the benefit of the collective communities and it highlights open source. >> Right. >> Big time in terms of successes. Dan, thanks so much for coming on, sharing the perspective, congratulations and sorry for the folks who couldn't make it, hopefully this video will help. This is the Cube here in Seattle for special coverage of CloudNativeCon and KubeCon, here in Seattle. Thanks for watching, I'm John furrier. >> Dan: Thanks. (upbeat music)