>> 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)

>> 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)

>> Live from San Francisco, it's The Cube, covering Google Cloud Next 2018. Brought to you by, Google Cloud and its ecosystem partners. >> Hello everyone, welcome back this is The Cube, live in San Francisco for Google Cloud's big event. It's called Google Next for 2018, it's their big cloud show. They're showcasing all their hot technology. A lot of breaking news, a lot of new tech, a lot of new announcements, of course we're bringing it here for three days of wall-to-wall coverage live. It's day two, our next guest is Tim Kelton, co-founder of Descartes Labs, doing some amazing work with imagery and data science, AI, TensorFlow, using the Google Cloud platform to analyze nearly 15 petabytes of data. Tim, welcome to The Cube. >> Thanks, great to be here >> Thanks for coming on. So we were just geeking out before we came on camera of the app that you have, really interesting stuff you guys got going on. Again, really cool, before we get into some of the tech, talk to me about Descartes Labs, you're co-founder, where did it come from? How did it start? And what are some of the projects that you guys are working on? >> I think, therefore I am. >> Exactly, exactly. Yeah, so we're a little different story than maybe a normal start-up. I was actually at a national research laboratory, Los Alamos National Laboratory, and there was a team of us that were focused on machine learning and using datasets, like remotely sensing the Earth with satellite and aerial imagery. And we were working on that from around 2008 to 2014 and then we saw just this explosion in things like, use cases for machine learning and applying that to real world use cases. But then, at the same time, there was this explosion in cloud computing and how much data you could store and train and things like that. So we started the company in late 2014 and now here we are today, we have around 80 employees. >> And what's the main thing you guys do from a data standpoint, where does the data come from? Take a minute to explain that. >> Yeah, so we focus on kind of a lot of often geospatial-centric data, but a lot of satellite and aerial imagery. A lot of what we call remote sensing, sensors orbiting the Earth or at low aerial over the Earth. All different modalities, such as different bands of light, different radio frequencies, all of those types of things. And then we fuse them together and have them in our models. And what we've seen is there's not just the magic data set that gives you the pure answer, right? It's fusing of a lot of these data sets together to tell you what's happening and then building models to predict how those changes affect our customers, their businesses, their supply chain, all those types of things. >> Let's talk about, I want to riff on something real quick, I know I want to get to some of the tech in a second. But my kids and I talk about this all the time, I got four kids and they're now, two in high school, two in college and they see Uber. And they see Uber remapping New York City every five minutes with the data that they get from the GPS. And we started riffing on drones and self-driving cars or aerial cars, if we want to fly in the air with automated helicopters or devices, you got to have some sort of coordinate system. We need this geospatial, and so, I know it's fantasy now, but what you guys are kind of getting at could be an indicator of the kind of geospatial work that's coming down later. Right now there's some cool things happening but you'd need kind of a name space or coordinates so you don't bump into something or are these automated drones don't fly near airports, or cell towers, or windmills, wind farms. >> Yeah, and those are the types of problems we solve or we look to solve, change is happening over time. Often it's the temporal cadence that's almost the key indicator in seeing how things are actually changing over time. And people are coming to us and saying, "Can you quantify that?" We've done things like agriculture and looking at crops grown, look at every single farm all over the whole U.S. and then build that into our models and say how much corn is grown at this field? And then test it back over the last 15 years and then say, as we get new imagery coming in, just daily flooding in through our Cloud Native platform, then just rerunning those models and saying, are we producing more today or less today? >> And then how is that data used, for example, take the agriculture example and that's used to say, okay, this region is maybe more productive than this region? Is it because of weather? Is it because of other things that they're doing? >> You can go back through all different types of use cases, everything from maybe if you're insuring that crop, you would might want to know if that's flooded more on the left side of the road or the right side of the road, as a predictive indicator. You might say, this is looking like a drought year. How have we done in drought years of 2007 and-- >> You look at irrigation trends. >> And you were talking off-camera about the ground truth, can you use IOT to actually calibrate the ground truth? >> Yeah and that's the sensor infusion we're seeing, everywhere around us we're seeing just floods and floods of sensors, so we have the sensors above the Earth looking down, but then as you have more and more sensors on the ground, that's the set of ground truth that you can train and calibrate. You could go back and train and train over again. It's a lot harder problem than, is this a cat or a dog? >> Yeah that's why I was riffing on the concept of a name space, the developer concept around, this is actually space. If you want to have flying drones deliver packages to transportation, you're going to need to know, some sort of triangulation, know what to do. But I got to ask you a question, so what are some of the problems that you're asked to look at, now that you have, you have the top-down view geospace, you got some ground truth sensor exploding in with more and more devices at the network, as a instrument anywhere it can have the IP or whatnot. What are some of the problems that you guys get asked to look at, you mentioned the agriculture, what else are you guys solving? >> Any sort of land use or land classification, or facilities and facility monitoring. It could be any sort of physical infrastructure that you're wanting to quantify and predict how those changes over time might impact that business vertical. And they're really varied, they're everything from energy and agriculture, and real estate, and things like that. Just last Friday, I was talking with, we have a two parts to our company. We have from the tech side, we have the engineering side which is normal engineering, but then we also have this applied science, where we have a team of scientists that are trying to build models often for our customers. 'Cause they're not, this is geospatial and machine learning, that's a rare breed of person. >> You don't want to cross pollinate. >> Yeah, and that's just not everywhere. Not all of our customers have that type of individual. But they were telling me, they were looking at the hurricane season coming up this Fall, and they had a building detector and they can detect all the buildings. So in just a couple hours, they ran that over all of the state of Florida and identified every building in the whole state of Florida. So now, as the seasons come in, they have a way to track that. >> They can be proactive and notify someone, hey you're building might need some boards on it or some sort of risk. >> Yeah and the last couple years look at all the weather events. In California we've had droughts and fires, but then you have flooding and things like that. And you're even able to start taking new types of sensors that are coming out, like the European Space Agency has a sensor that we ingest and it does synthetic aperture radar, where it's sending a radar signal down to the Earth and capturing it. So you can do things like water levels in reservoirs and things like that. >> And look at irrigation for farming, where is the droughts going to be? Where is the flooding going to be? So, for the folks watching, go to descarteslabs.com/search they got a search engine there, I wish we could show it on screen here but we don't have the terminal for it on this show. But it's a cool demo, you can search and find, you can pick an area, football field, and irrigation ditch, anything, cell tower, wind farm, and find duplicates and it gives you a map around the country. So the question is, is that, what is going on in the tech? 'Cause you got to use Cloud for this, so how do you make it all happen? >> Yeah, so we have two real big components to our tech space the first is, obviously we have lots and lots of satellite and aerial imagery, that's one of the biggest and messiest data sets and there's all types of calibration workloads that we have to do. So we have this ingest pipeline that processes it, cleans it, calibrates it, removes the clouds, not as in cloud computing infrastructure, but as in clouds over the head and then the shadows they emit down on the Earth. And we have this big ingestion process that cleans it all. And then finally compresses it and then we use things like GCS as an infinitely scalable object store. And what we really like on the GCS side is the performance we get 'cause we're reading and pulling in and out that compressed imagery all day long. So every time you zoom in or zoom out, like we're expanding it and removing that, but then our models, sometimes what we've done is, we'll want to maybe we're making a model in vegetation and we just want to look at the infrared bands. So we'll want to fuse together satellites from many different sources, fuse together ground sources, sensor sources, and just maybe pull in just one of those bands of light, not pull the whole files in. So that's what we've been building on our API. >> So how do you find GCP? What do you like? We've been all the users this week, what are the strengths? What are some of the weaknesses? What's on their to-do list? Documentation comes up a lot, we'd like to see better documentation, okay that's normal but what's your perspective? >> If you write code or develop, you always want something, you know it's always out of feature parody and stuff. From our perspective, the biggest strengths of GCP, one of the most core strengths is the network. The performance we've been able to see from the network is basically on par with what used to have, when we were at national laboratories we'd have access to high performance, super computing, some of the biggest clusters in the world. And in the network, in GCS and how we've been able scale linearly, like our ingest pipelines, we processed a petabyte of data on GCP in 16 hours through our processing pipeline on 30,000 cores. And we'll just scale that network bandwidth right up. >> Do you tap the premium network service or is it just the standard network? >> This is just stock. That was actually three years ago that we got to our bandwidth. >> How many cores? >> That was 30,000. >> Cause Google talked this morning about their standard network and the premium network, I don't know if you saw the keynote, with you get the low latency, if you pay a little bit more, proximate to your users, but you're saying on the standard network, you're getting just incredible... >> That was early 2015, it's just a few people in our company scaling up our ingest pipeline. We look at that, from then that was 40 years of imagery from NASA's Landsat program that we pulled in. And not that far off in the future, that petabyte's going to be a daily occurrence. So we wanted our ingest to scale and one of our big questions early on is actually, could the cloud actually even handle that type of scale? So that was one of the earliest workloads on things like-- >> And you feel good now about right? >> Oh yeah, and that was one of the first workloads on preemptible instances as well. >> What's on the to-do list? What would make your life better? >> So we've been working a lot with Istio that was shown here. So we actually gave a demo, we were in a couple talks yesterday on how we leverage and use Istio on our microservices. Our APIs are all built on that and so is our multi tenant SAS platform. So our ML team, when they're building models, they're all building models off different use cases, different bands of light, different geographic regions, different temporal windows. So we do all of that in Kubernetes and so those are all-- >> And what does Istio give you guys? What's the benefit of Istio? >> For us, we're using it on a few of our APIs and it's things like, really being able to see when you've start splitting out these microservices that network and that node-to-node or container-to-container latency and where things break down. Being about to do circuit retries or being able to try a response three different times before I return back a 500 or rate limit some of your APIs so they don't get crushed or you can scale them appropriately. And then actually being able to make custom metrics and to be able to fuse that back into how GKE scales on the node pools and stuff like that. >> So okay, that's how you're using it. So you were talking about Istio before, there's things that you'd like to see that aren't there today? More maturity or? >> Yeah I think Istio's like a very early starting point on all of this types of tools. >> So you want more? >> Oh yeah, definitely, definitely but I love the direction they're going and I love that it's open and if I ever wanted to I could build it on prem. But we were built basically native in the cloud so all of our infrastructure's in the cloud. We don't even have a physical server. >> What does open do for you, for your business? Is it just a good feeling? Do you feel like you're less locked in? Does it feel like you're giving back to the community? >> We read the Kubernetes source code. We've committed changes. Just recently, there's Google's open source, the OpenCensus library for tracing and things like that. We committed PRs back into that last week. We're looking for change. Something that doesn't quite work how we want, we can actually go.. >> Cause you're upstream >> Add value... >> For your business. >> We get in really hard problems, you kind of need to understand that code sometimes at that level. Build Tools, where Google took their internal tool, Blaze and opened source that bezel and so we're been using that. We're using that on our monorepos to do all of our builds. >> So you guys take it downstream, you work on it, and then all upstream contributions, is that how it works? >> Sometimes. >> Whenever you need to. >> Even Kubernetes, we've looked, if nothing else we've looked at the code multiple times and say, "Oh, this is why that autoscaler is behaving this way." Actually now I can understand how to change my workload a little bit and alter that so that the scaler works a little bit more performantly or we extract that last 10% of performance out to try and save that last 10%. >> This is a fascinating, I would love to come visit you guys and check out the facilities. It's the coolest thing ever. I think it's the future, there's so much tech going on. So many problems that are new and cool. You got the compute to boot behind it. Final question for you, how are you using analytics and machine learning? What's the key things you're using from Google? What are you guys building on your own? If anything, can you share a quick note on the ML and the analytics, how you guys are scaling that up? >> We've been using TensorFlow since very early days that geovisual search that you were saying, where we user TensorFlow models in some of those types of products. So we're big fans of that as well. And we'll keep building out models where it's appropriate. Sometimes we use very simple packages. You're just doing linear regression or things like that. >> So you're just applying that in. >> Yeah, it's the right tool for the right problem and always picking that and applying that. >> And just quick are you guys are for-profit, non-profit? What's the commercial? >> Yeah, we're for-profit, we're a Silicon Valley VC-backed company, even though we're in the mountains. >> Who's in the VCs? Which VCs are in? >> CrosslinK Capital is one our leading VCs, Eric Chin and that team down there and they've been great to work with. So they took a chance in a crazy bunch of scientists from up in the mountains of New Mexico. >> That sounds like a good VC back opportunity. >> Yeah and we had a CEO that was kind of from the Bay Area, Mark Johnson, and so we needed kind of both of those to really be successful. >> I mean I'm a big believer you throw money at great smart people and then merging markets like this. And you got a mission that's super cool, it's obvious that it's a lot to do and there's opportunities as well. >> Tremendous opportunities. Congratulations, Tim. Thanks for coming on The Cube. Tim Kelton, he's the co-founder at Descartes Labs. Here in The Cube, breaking down, bringing the technology, they got applied physicists, all these brains working on the geospatial future for The Cube. We are geospatial here in The Cube, in Google Next in San Francisco, I'm John Furrier, Dave Vellante, stay with us, for more coverage after this short break.