 Hello, everyone, and welcome to the Open Telemetry Colo Day at KubeCon Cloud Native Con North America 2020. I'm Priyanka Sharma, and I'm the general manager of the Cloud Native Computing Foundation, or our beloved CLCF. And I'm so thrilled to be here today to speak with the lead maintainers of Open Telemetry Project. I personally have a special place in my heart for all things observability, my own journey in Cloud Native began with the Open Tracing Project, where I worked very closely with Ted over here and also hung out with Morgan. So I'm just excited to see all the momentum that has happened over the years and the great progress we have made till date. So without further ado, let's get started and learn more about Open Telemetry. So first things first, Ted and Morgan, please introduce yourself. Ted, do you wanna go first? Sure, yeah, my name's Ted Young, Ted Sewo Online. If you've shown up to almost any Open Telemetry call, I'm sure you've seen me around. My background was I've been working in really Cloud Native Computing for a long time. It was containers and container scheduling before this, but that led me into observability because I just felt like I did not have the tools that I needed to really manage and debug these like mission-critical control planes that we were building. And we needed something that was flexible and could connect to a lot of systems and the Open Tracing Project seemed like the ideal, the ideal tool that we were missing at the time. So that's what sort of grew me in to this world of observability. And I loved it so much that I went full-time on it. And the rest is history. Yeah. Sorry, God. I'm Morgan McLean, I work at Google. My history dates back to our Cloud Trace product and later Open Census, which was around the same time as Open Tracing. And I've been involved with Open Census since the beginning and certainly with a merger of Open Census and Open Tracing into Open Telemetry. And like Ted, if you've joined basically any call for any of the Open Telemetry sigs, you've probably seen my face and heard my voice. And so it's great to talk about it today. Awesome, awesome. So to kick us off, for the benefit of the audience, I think it'll be helpful if you can tell us exactly what Open Telemetry is today. Yeah. Ted, do you want me to take that? Yeah, do it. Yeah, so Open Telemetry provides the components that you need to capture observability signals from your applications. And I realize, I appreciate that's a mouthful. What it really means is we provide the SDKs and or agents that capture traces and metrics and eventually other signals from your application. And they'll then send that data to various backends for processing and analytics. Nice. Yeah. So you set metrics as well as traces, so. Correct, yeah, we capture both. Yeah, and I mean, I don't want to dilute the conversation too much. We're also working on blogs, that'll ship far later midway through next year, but our ambition is to get as many signal types as we can. Yeah. Yeah, I would say like at a meta level, it's not just all of the implementations, but it's sort of like a language for being able to describe how distributed systems work focused on looking at them from a transactional point of view. And the point of view that we tend to wanna have when we're trying to debug these massive systems. So that's part of what makes it, I think, a little bit distinct in this area from other prior projects. I feel like that's so beautifully said, a language for describing distributed systems from a transactional point of view. That should be on your website. Free marketing advice. No, this really brings me back in my head to the open tracing days where really we were trying to talk about how do you understand your system, which at a certain level of complexity, no single human being can. And so what would be really helpful is to understand exactly how open telemetry is different from open tracing as well as open census. Yeah, I can take a first pass at this. So I feel like it was sort of like two halves of the same thing. That was what made the merger so interesting. On the open tracing side, it was really focused on having the interfaces. The main thing we were looking at trying to share was all of the instrumentation. When you go out there and you try and maintain one of these big observability systems, the instrumentation is just a huge amount of work to keep up with. And as software has diversified over time, it's just becoming just more and more software that means more and more different kinds of instrumentation. There's a certain point where it just becomes untenable for anyone to maintain all of that on their own on top of trying to build some kind of analysis tool. So what we really wanted to do was figure out a way that we could share all of this instrumentation and be able to have that instrumentation ideally be native within software rather than plugins and then be able to plug in any kind of analysis tool on the back end. And so that was where the direction of open tracing came at it. You wanna talk about open census, Morgan? Yeah, so open census was similar and yet different, right? So open tracing was very focused on the interfaces and capturing, as Ted mentioned, capturing as much instrumentation as it could. Open census was very focused on providing a great out-of-box experience. And so open census included the entire implementation, the tracer, context propagation, everything else was just there in your language specific SDK. And open census additionally also focused on metrics which was a big difference from open tracing which was, as its name suggests, very focused on tracing. And I think open telemetry brings the best of both of each of these, right? You have in open telemetry you have APIs that don't include the implementation much like open tracing which makes it really easy for framework maintainers to bind against this framework. That was a challenge in open census, it was a drawback. You had to bring the whole implementation with you. And open telemetry also provides the full SDK as a separate component that you can pull down much like what open census had. And it also includes metrics. And so really it's just the ultimate marriage of both projects into one. And plus on top of that it brings a vastly larger community than either open census or open tracing ever had. I think I ran the numbers a few months ago, it's like 20 times bigger than open census and open tracing combined in terms of number of committers. The last few months we've been the second largest or second most active CNCF project in terms of commits and committers, which is huge. Like if you told me that like last year I wouldn't have believed you. And so that's another sort of non-technical thing that the project brings is like huge support from the industry and end users, which is fantastic. Wow, that is amazing. I mean, 20,000 contributors it's- Well, not 20,000 contributors, sorry, 20 times the size, 20 times the previous number. That's like 2,000% growth, right? Something like that if I did my math, right? No, it's fantastic. I mean, it's kind of mind boggling when we look at the CNCF dev stats and go like, that's us really? That's you guys. But I think it speaks to the hunger that's existed in the industry for this solution. And I mean, certainly I know at Google and certainly Ted for yourself at LightStep and all the contributors from all the other vendors have mentioned you get on customer calls and they see the value immediately. And that's why you have, I think, so many end users like Shopify and others and MailChimp and Postmates and the whole group making their own contributions and putting teams on this because they see the value. Yeah, and that's ultimately why we decided to merge the projects. Normally it's fine to have like a bunch of separate projects in the same space. It's no big deal, but there is something about, I think in particular distributed tracing aspect of it, but really everyone was asking for there to be one standard for doing this. And so we were getting a lot of community pressure to merge the projects, you know, kind of from the get go. People were like, I don't really want to pick between these two things. Why are we having this XKCD comic experience? Now there were 11 standards. Yeah, but it was like totally validating because when we merged them, so we actually maybe like the one group to actually reduce the number of potential standards out there by going from two to one. And when we did that, that was what made everyone get involved because that was ultimately the thing people were looking for was just agreement on how we were gonna do this. Yes. Absolutely, I think you have truly found product market fit. And in this case, it's standard market fit. Let's maybe we'll call it that. But it's, I think, as you folks said, right? This is a merger and then some because your community has grown 20X at least. You have so much more momentum and that tells you the sum is greater than the parts. And that's just a beautiful, beautiful story. I think one thing you folks have been saying, one thread you folks have been talking about is around standards and how there's like always more and more because everyone, I think to quote something Marion said, similar but different. And that's sort of how I think N plus one happens. Why does this happen so much in standards? Standards are hard. It's ultimately about organizing people and finding agreement. And when there's less people around, it's easier to find agreement. That's just one of the things about having a diverse coalition is you have to do the work. It's real work to actually come up with something that makes everyone happy and satisfied. And that's always going to be slower than just kind of going off on your own and taking a shot at it. So it's always going to be a longer process. And we certainly saw open telemetry, I think probably doing this merger probably added a year onto our timeline at least. But that's just why standards end up taking time. Even simple standards, like it's technically a separate standard, separate project. But if you look at W3C Trace context, which is basically all the same participants as open telemetry, but it's just for the HTTP header that's used to propagate trace context. That's it, very simple, just a little string. That took about, like we'd had sort of drafts going between like Google and Zipkin for a while. And then we brought it into W3C or actually it was Dynatrace who helped us bring it in. And once that happened, progress did slow, not in a bad way, but just because, yeah, everybody's there. Like you need to meet everyone's requirements now. That just naturally takes a lot of time. It's good, it's bad because it slows things down, but it's good because in the end, now everyone's gonna support it, right? And it actually meets everyone's needs. And that's just the nature of the beast when it comes to standards. Yeah, I think you're absolutely right. A standard is just different because it's very opinionated and very specific. And if that hasn't, I don't think the difference in pace is by any means a bad thing. As you said, you added time to your roadmap, but now you've come out with something stronger that people really love. And something actually used, like used and useful, right? Yeah, exactly, actually useful. And so that's just like, it seems like observability is that kind of space that needed this type of effort. I have actually had my own brush with standards lately because we're working on an inclusive naming initiative for all of, not just the NCF, but leveraging the Kubernetes projects work in removing problematic language and code. And the clear knowledge, a clear thing we were told, you have to work with standards because there are aspects of software that have to be determined in that way. And then you went to talk to them, it was like, oh yeah, a very fast thing will be like probably two years. And it's like, wait, what? That's like to be kicked off. And these are the software standards. Like I feel for people who do standards in like the electrical or mechanical engineering or civil engineering, that takes way longer. Yeah. I know. So you guys are blazing fast as a saying. Yeah. The fastest turtle. Yep, exactly, exactly. So amazing stuff. I think myself, I and the audience has learned a lot about the history of open telemetry, all the value that it's brought. I think now we would like to learn from you about where is, what is your latest update from open telemetry to end users potential contributors out there? Yeah. So I can speak to that a bit. So we recently had an announcement that the tracing specification has reached release candidate status. And so the SDKs are all working away right now on building their own release candidates for tracing. Obviously the SDKs include tracing and metrics and other things, but the tracing part of each of these SDKs once they hit release candidate status will be RC and will have the intense and I think we'll meet this of ensuring there are no breaking changes between that release candidate and the final GA version. After that, or actually in parallel to that, we're working on achieving a release candidate specification for metrics, followed by then the SDKs, achieving release candidate status for tracing and metrics together, at which point we'll declare the project to be release candidate status. Following that, then we'll work very hard towards getting to GA. That's mostly like bug fixes, productionization, testing, documentation. And so we're expecting pretty broad adoption once the project hits RC for both tracing and metrics. And what's the timeline for RC and GA? No one's gonna hold you to it. Yeah, we've been very optimistic earlier this year. I'm probably more guilty than anyone about that. I'm hoping we can get RC for both by the end of this year. We'll see, that's not a guarantee. Both as in both tracing and metrics. Yeah, you're gonna see release candidate SDKs for tracing in the next few weeks. Like that's well out of the way. The RC release of the tracing spec, I think it's hopefully probably achievable this year. We're gonna push really hard towards that. The RC release for tracing and metrics, both in the SDKs is possibly achievable this year. Again, we're gonna push really hard to try and get that. We may or may not. We'll see. It's debatable. GA would definitely be available this year. Yeah, GA is in the next year. Okay, so you folks are saying and that by next KubeCon year, you will have a GA product. Did I get that one? Yes. I really hope so. It will be done next year. If not GA. You'll get his RC. Yes, exactly. So it will definitely have RCs well before KubeCon EU. The RCs, I expect to be used a lot of places in production. Like I'm curious how many vendors are gonna certified. I'm guessing a lot of them will. But GA hopefully by next year, but to be blunt for most users, that probably won't matter because I'm expecting pretty broad adoption of the RCs. Just given the amount of contributions we've seen from end users. Great. One imagines they're not gonna make all those contributions and then sit and wait for a label to tell them they can use it. Yeah. And I would add there is actually an important timeframe right now, which is because the tracing spec is now frozen and we have not yet issued a release candidate. Now is the time to really dog food and try this out. So getting involved and making sure that it feels ergonomic, that everything is working properly, that we don't wanna make any changes on the individual language levels. This is the time to be doing that work. So I would encourage anyone who's watching this to give open telemetry a try now and start giving us feedback before those RCs come out. Amazing. And so the call to action here is go check out the open telemetry libraries for various languages and give feedback because the RC is coming soon. And one thing I think would be helpful just for first time attendees as well as some end users and contributors is to really understand what you mean when you say RC is coming, it's great. I think that would help them feel more comfortable going forward before GA. So would you please explain that one of you? Sure, RC just means release candidate. So what we wanna do is lockdown in particular the public API. So open telemetry differentiates between the APIs that end users use to instrument their code versus what's happening under the hood and SDK framework API. So we have, you know, typical framework stuff around lifecycle hooks and things of that nature. But the stuff that really needs to remain stable and backwards compatible very, very strictly are the public APIs. Because if you look at the amount of code that's going to be written against those APIs that is just monstrous compared to the amount of code that would be written against, say, you know, our framework APIs. And that code has to be stable because if we break that in some way we're going to be breaking a lot of code. And so we wanna have a strict long-term support guarantee around that public API. So that's the part we really, really wanna nail. And that's, to my mind, like the heart of what the release candidates in GA is about. It's saying like, this has reached a stability point where we think we're just going to leave it this way and we might add things to it later but we're not gonna break this. So that's why it's so important for people to give their shot right now. Awesome. So go out there and try this out and give them feedback. They've organized a whole colo for you to get you to do that. So speaking of colos, there's a lot of stuff happening, right? KubeCon is so full of energy and excitement. And I'm proud to say actually compared to our first rep with the virtual event this time, I think people have been able to work with the virtual event and made it strategic for themselves. They're having colos like this. We're doing inclusive naming meetings, et cetera, et cetera. So people, the demands on people's time is high. What would you recommend folks who are watching this right now to definitely attend in order to build their understanding of cloud data systems? Well, definitely attend Open Telemetry Community Day. So you've already checked that box. You already have. But yeah, stay tuned. We do have, after this, we're going to be going into workshops, like unconference style conversations. And so that's a great way to really get out there and get your questions answered because we have a lot of maintainers and community members here. And I love unconferences. That's the part I'm most excited about. Morgan, do you have anything beyond that? You think it's- We have some cool talks also occurring. I mean, it's a single track. So if you're here and don't change the channel, I assume you're going to stick around. There's definitely a few talks where I read the summary and they look pretty interesting. So I'm excited to listen to them. And a number of them are by actual end users who are using Open Telemetry in production. And so you can understand even from their experience in the beta, how things have gone, pitfalls they've ran into and how the project has improved and evolved since then. Oh, that's amazing. I mean, if the end users telling their stories, that's the way to go. And I'm so proud to hear that you have that. I also think you have amazing maintainers and collaborators on your project. One of whom is Constance. I always say her last name wrong, so I'm not gonna try. But Constance is actually co-chair for all of KubeCon this time round. And she's a part of the hotel community. And she's going to do her keynote as a co-chair on Wednesday, November 18, 1.51 PM Eastern Time. And so you can listen to her as well as one of the hardworking collaborators on Open Telemetry. With all that said, just final question folks. Obviously we've learned a lot. We know about the history of Open Telemetry to some degree. We know about the release candidate that's coming soon. But I'm sure lots of folks have questions. Where can they find you? And I have trained you to give the right answer on this one. Let's do that. So during the conference, you can find us and I think any conference attendees and Priyanka on Slack, on the CNCF Slack specifically. I do know like Open Telemetry, we actually tend to use Gitter. Okay, that's great for the long term. Yes, you can do the long term. There's been debates about switching to Slack internally there too. But for the purposes of this conference, it sounds like there will be a lot of conversations on Slack and we'll be participating there. Generally, so beyond KubeCon this year, then we're active on Gitter. Like I said, that might be moving to Slack but eventually there'll be an announcement about that when it happens on GitHub and during the weekly special interest group meetings. To be honest, like if you really want to get involved and understand the pace of the project rather, then the weekly SIG meetings, which are in our public calendar, are they're open to anyone? I really recommend joining. There's great discussions that happen there. And on the weekly maintainers meeting, we go over the project status every Monday morning. And so that's the fastest and easiest way both to introduce yourself to the participants in the community and become active in it. Yeah. Yeah, we try to keep all of the actual work on the project strictly in GitHub. Yes. So you can also find publishing issues and PRs if you want to get a sense of where the project is. We have various burn down charts and projects there. But please do come to the calls. I think people can be maybe a little shy or they're like, oh, I'm not like a core person but we really welcome participation in those calls. And it's a great way to get your questions answered synchronously because you'll have all the maintainers there. So do show up and say hi. What is the website for open telemetry? It's openslometry.io. Okay, gotcha because that could be a one-stop shop for people to probably learn. Absolutely. All the information's like there. The calendar for the meeting invites get everything else is there. And also you can use the open telemetry blog to also keep appraised of the project's activity. Amazing. Okay, yeah. So folks, if you want to hang out with these folks now when you have learned about this topic then go to the CNCF Slack. There's lots of other KubeCon attendees over there and we're doing lots of like fun stuff like polls and this and that. And you can find them in channels about the event or you could even DM them. So those are two options. And then for long-term engagement, definitely find them on open telemetry.io. Go to their GitHub repos and show up to the meetings. You don't need to know anything to show up. Everyone can contribute and you really should. And a contribution just showing up, you did it. Check. So highly encourage you all to participate in this wonderful community. Thank you so much, Ken and Morgan, for telling us about the awesome project, your progress, your end user love. Very excited for you. And to the attendees, I say, go have fun, live learn and enjoy yourself. Thank you so much. Thank you, Priyanka. Thank you.