Juraci Paixão Kröhling of Grafana Labs geeks out with Adriana Villela on all things OpenTelemetry! As an early contributor to OpenTelemetry haling from the pre-OTel days of OpenTracing, Juraci reflects on how much the project has changed and evolved. He also talks about his role on the OpenTelemetry Governance Committee (GC) and how the GC serves the OTel community at large, and about his continued involvement in the OpenTelemetry Collector. Juraci closes by sharing his passion for contributing to diversity in tech through Outreachy, highlighting his commitment to enriching the technology community.
About our guest:
Juraci Paixão Kröhling is a seasoned software engineer, a Governance Committee member for the OpenTelemetry project, and an emeritus maintainer of the Jaeger project. With a strong focus on observability and open-source development, Juraci has delivered talks at conferences such as KubeCon EU, KubeCon NA, OpenSource Summit, Devoxx Belgium, FOSDEM, and various DevOpsDays. With deep expertise in distributed tracing and observability, Juraci empowers software engineers to optimize their applications and build reliable observability pipelines. Currently working at Grafana Labs, Juraci continues to shape the future of observability tools while passionately contributing to the open-source software engineering community. Outside of work, Juraci is a proud parent of three kids and finds solace in the hobby of sleeping, albeit occasionally interrupted by the delightful chaos of parenting responsibilities.
Find our guest on:
Find us on:
Show Links:
Additional Links:
Transcript:
ADRIANA: Hey y'all, welcome to geeking out. The podcast about all geeky aspects of software delivery DevOps, observability, reliability and everything in between. I'm your host Adriana Villela. Coming to you from Toronto, Canada and geeking out with me today is Jurassi. Welcome Judasi.
JURACI: Thank you very much. And I'm surprised always when speaking English, people have a trouble speaking my name. That's not the case with you. You were perfect.
ADRIANA: Oh, thank you! So, Juraci, where are you calling from today?
JURACI: I'm calling from Berlin, Germany. Yeah, I'm freshly moved from Brazil back to Germany to Berlin. I'm here since 9 August, so I'm here less than a month now.
ADRIANA: Very cool. I've been to Berlin once when I was working in Munich, I took a train to the Love Parade.
JURACI: That's nice, that's wonderful.
ADRIANA: This was back in 2000.
JURACI: Okay, yeah, that's nice.
ADRIANA: I'd never been to the Love Parade. I was like, wow, it is an experience. It was a fun experience. So that's my experience with Berlin. I hope someday to actually see Berlin properly.
JURACI: Well, almost nothing here can top Love Parade. So you've experienced Berlin on its best.
ADRIANA: Awesome. So before we get going with the main content, I have a few lightning round questions that I like to ask all my guests. So don't worry, they're painless and they're fun. So let's get started. So first question, are you left handed or right handed?
JURACI: Oh, I'm left handed.
ADRIANA: Me too. I'm so excited to meet left handed people! Yay. Left handed and Brazilian. Best combo ever. I'm slightly biased. Next question. IPhone or Android?
JURACI: Oh, Android, that's easy. Open source? Well not so much, but yeah.
ADRIANA: Cool. Next one, do you prefer Mac, Linux or Windows?
JURACI: That's also easy. Linux.
ADRIANA: Awesome. Hardcore. Die hard, very cool. Okay, favorite programming language?
JURACI: Oh that's tough. I don't know, I'm using Go most of the time now, but Ruby still has a place in my heart. But I was a Java developer for so long, so I don't know, I mean a mix of Java, Ruby and Go now.
ADRIANA: Nice. Most of my career was as a Java developer. Sixteen years. So I have a love hate relationship with Java.
JURACI: I guess that's why I like Ruby so much, because Java provides you the security in so many aspects and Ruby is just like this nice language that is beautiful to read and it's fun to write. It might not be a perfect fit for everything, but it is a fresh view of the programming world for a Java programmer.
ADRIANA: Yes, very true, very true. Actually I know a lot of people who love Ruby because I think they describe it as being like a very simple, very elegant language.
JURACI: It is. Not only the language itself is very nice, but what you can do with that, you can build very beautiful DSLs with Ruby. And they really feel like DSLs, like domain specific languages. And when you build a DSL in Java, for instance, it still feels like Java. Right. But there are some DSLs in Ruby that you cannot tell it is Ruby. You really think that it's a new language built on purpose for that specific domain? I think that's what makes Ruby beautiful.
ADRIANA: That's very cool. Next question. Prefer Dev or ops?
JURACI: Dev.
ADRIANA: All right.
JURACI: I've been operating my own servers since like ever. And I love doing that. I ran my mail server for more than a decade now. I stopped a couple of years ago. I decided not to continue doing that for my own sanity.
ADRIANA: That's a lot of work.
JURACI: It is, but that side of operations is really very close to my heart. But still, I'm a developer.
ADRIANA: I feel you. All right, next one. JSON or YAML?
JURACI: Oh no. None?
ADRIANA: That's a fair answer.
JURACI: Well, if I have to pick one, then YAML, of course. But yeah, no...I don't know.
ADRIANA: Yeah, I prefer YAML over JSon. JSON's too garbly for me. Too much happening. It gives me Java vibes like so many curly braces.
JURACI: Yeah, and double quotes everywhere. In YAML you can just choose when to place it and when not to place it. And comments, I mean, you can place comments on YAML, you cannot with JSON.
ADRIANA: Oh yeah, that's true. Score for YAML. Okay, next question is, do you prefer to consume content through video or text?
JURACI: Okay, I'm still a text consumer, so books, articles. But I am on this verge of consuming more and more media in podcasts or presentations, like recorded presentations from conferences and so on. I find that. I think the best balance right now is a mix of all of them. There are some great content that has been provided in forms of tutorials and presentations at Kubecons for instance.
ADRIANA: Yeah.
JURACI: That you cannot find written anywhere, so you have to go and watch them at the same time. I find good old books very pleasant to read.
ADRIANA: Yeah, I definitely have to agree with you. Text is my default. I love a good podcast, especially like when I'm doing, running errands, walking, doing housework. It just gives my brain something to do. But yeah, I agree with you that there are some cases now where video is the only way to consume the content. So you kind of have to just power through.
JURACI: Had some, I don't know, I had some like, oh, YouTube. YouTubers. No, I refuse to do that. But then I think we are past that now. People are producing great. I mean, look at Prometheus, right? So Julius Volz is creating great videos on Prometheus and there is no one better, or there is almost no one better in the world that can talk about Prometheus. No bigger authority than Prometheus and him than Julius. And it's only in video.
JURACI: Of course he does have his courses and some written content, but the videos are just great.
ADRIANA: That's awesome. Good to know. Good to know. And final question in our lightning round, what is your superpower?
JURACI: Oh, getting my kids in bed. I can do that better than anyone else. I just get them there and they fell asleep in a few minutes.
ADRIANA: Yeah, that is very impressive. I just have the one daughter and when she was little, oh my God, the excuses, the excuses.
JURACI: And I'm leveling up. I take care of two now because my youngest one is too young for me, I cannot breastfeed her. So mom still has to get her to sleep. But we are now transitioning also to no breastfeeding anymore. So in the future it's not going to be two kids, but three to get in bed.
ADRIANA: So then you'll really put your superpower to work. Amazing. Well, awesome. Thanks for playing along with the lightning round questions. So now onto the good stuff. So OpenTelemetry...I want to talk to you about...because you are one of the OpenTelemetry maintainers, right? What's your specific role in the OpenTelemetry community?
JURACI: I wear quite a few hats actually, but two of them are really big. And perhaps the biggest hat that I have right now in the OpenTelemetry community is on the Collector SIG. So I'm a code owner for a few components of OpenTelemetry Collector, especially around the contrib repository. So things like the tail sampling processor or the load balancing exporter, or routing processor and routing connector now and a few other things. And of course Grafana specific components like the Loki receiver and exporter. I'm also part of the Governance Committee or the Governance Board for OpenTelemetry. So I think that's my second biggest hat there. But I'm around in a making...I don't know...creating confusion in other SIGs as well.
JURACI: I guess that's what I can describe.
ADRIANA: Awesome. I don't know if you heard that sound. Yeah. So there is in Toronto right now, we call it like the Canadian National Exhibition. It's basically like, I don't know, like a two week fair amusement park thing. And this time of year they have like fighter jets, they do like an aerial show. And even though we're not that close to where it's at, I want to say it's about. Probably about 4 km away from where I am, but it's freaking loud.
ADRIANA: And they practice around this time. And I think the air show is this weekend because Labor Day weekend. Yeah. Anyway, that's where that horrid sound came from. That was super freaking loud. So one of the things I wanted to ask in your OpenTelemetry role, so what does the governance committee do?
JURACI: Right, that's a great question. In the best case scenario, we don't do anything, but we are effectively the maintainers from the CNCF's perspective. So we are the ones taking the decisions on behalf of the project, especially when it comes to official decisions. So if there are any resource requests, especially involving money, that needs to go through the CMCF, then it has to go through the Governance Committee, the Governance Board, and we wouldn't take a look at those requests and we decide, oh, it does make sense, or it is good for the project, or it is not very nice for the project to do that. So this is the very bureaucratic view of the government. So we sign the request and things like that. Practically, in practical terms, what we do is we take care of organizing our events for KubeCon, for instance. So we apply for specific places, for specific talks at the maintenance track, for instance, or the contribfest.
JURACI: We applied for this KubeCon, but we also mediate conflicts. And this is, I think, the most important part of the GB, the governance board or the GC. The Governance Committee, as we usually call it, the GC. And that is whenever we see something that can negatively impact the OpenTelemetry community, it is our duty to act on it. So there was a case a year or so ago where at the beginning of the year, where there were some concerns about one specific thing. And as a GC member, we have to go and see those allegations and go and see what is behind it. And is there any concern for OpenTelemetry as a community because of that? And if there is, we have to act on. But it is our ultimate responsibility to take care of OpenTelemetry as a project and as a community.
JURACI: I think that's mainly how I see the OpenTelemetry role. Of course, we also have a say, so not the say, but we have a say in the roadmap so we try to build or establish a roadmap for the project. But because the way that we structure the project, every SIG is independent, and every person collaborating in the project or with the project has the freedom to do whatever they want. We cannot just go to the Collector contributor and say, hey, Juraci, you have to work on this receiver here. That's not how it works. We have to plan ahead. Of course, as part of the GC, we have to think about it and think, when do we want to do AGA for the project as a whole? Do we want to graduate or not? What do we want for the future? And once we know that, once we have that kind of vision, project wide vision, we try to get the message out and tell other maintainers. So this is where we think the project should be going.
JURACI: So can we try to make a concerted effort to get there as a project? Most of the time we fail, but I guess that it is useful nonetheless. We were able to get a focus on metrics for a few months, and then we got metrics out, and we also got a concerted effort around logs, and logs are now also out. So for the most part. So I think it does work, but it is a fair question because it's not very clear when we are out what the GC should be doing.
ADRIANA: Well, it sounds like GC wears a lot of hats. There's a lot going on in the GC.
JURACI: Well, we got to meet every week for about an hour, and that's pretty much all of the time that we have. So we can say that we have 1 hour of work per week. Most of the time, we discuss the whole hour. So we have quite a few things to talk about, but most of them are, I have to admit, they're kind of mundane. Right? So like a company, X wants to assess whether it makes sense to have a set of features for a specific platform, right? So then we go around and ask people, does that make sense? Does that not make sense for us?
ADRIANA: So then how do you communicate, since the GC does, I guess, has a hand in the overall vision for OpenTelemetry, how do you communicate that information to the different SIGs to make sure that things move in that direction, even if you're not successful, but to at least communicate the idea, even if it doesn't necessarily get implemented, or maybe not implemented in the way that was originally envisioned?
JURACI: Yeah, that's a good question. We have a diverse set of GC members. We have two people from the collector SIG. We have people that are not part of any other SIGs. We have two people who are part of the TC, the technical committee as well. We have people who are users of OpenTelemetry in ODIC. So what we do today is we use the other hats for the GC members so that information can spread around. So we have the Collector folks bringing information into the Collector SIG, but we also have GC members joining the Monday's maintainers call.
JURACI: So we have a call every Monday for maintainers of OpenTelemetry. So we have a GC member joining that call and bringing the updates to that group. We also have a monthly GC plus TC call where we have a discussion between the two committees discussing things that are relevant for the project as a whole, but also making sure that information flows basically. And the TC is then responsible for ensuring that the technical direction of the project is set and followed by the individual.
ADRIANA: Okay. Okay. Yeah, that makes a lot of sense. Cool. So now, taking a step back, my question is, how did you get involved in OpenTelemetry in the first place?
JURACI: I like to say that I'm part of OpenTelemetry since it was not OpenTelemetry. Right. I mean, I was part of the OpenTracing group back then.
ADRIANA: Oh, very cool.
JURACI: I was actually part of perhaps the first KubeCon where OpenTelemetry had an appearance. And it was actually here in Berlin in 2017. I think it was KubeCon Europe was very small back then, I think not even like 1000 people.
ADRIANA: Oh, my God.
JURACI: Yeah. Comparing now, like with Amsterdam. It's a totally different vibe.
ADRIANA: That was outrageously huge. And I think Chicago is going to be even bigger, I think.
JURACI: So, yeah. I'm really looking forward to it. But back then in 2017, we had a, I think it was a tutorial. Me, Priyanka Sharma, who is now executive director of the CNCF, and Ted Young, your colleague, Ted Young. We were there doing an OpenTracing tutorial back then, and it was really fun. I mean, we had a 90 minutes session there, people trying to instrument their applications using Go and OpenTracing and facing all sorts of problems. And things were working, but barely, but it was fun. So I joined back then and things just evolved from there.
JURACI: Right. So we got, in 2019, perhaps, we joined forces with OpenCensus, then we formed OpenTelemetry in perhaps a little bit later than 2019, but then here we are. And I started contributing with the Collector when we joined forces, because I thought the Collector was a really cool technology back then it was part of OpenCensus service, so it was already getting our attention at RedHat back then, we thought this is a cool piece of technology that can really free up people. Not free up, but to liberate people from vendors if they want to do so. Right. So people can start using the service to make translations and they can decide at the service, OpenCensus service. Back then they can decide where to send their data. For a company like RedHat, that made a lot of sense because RedHat was not, and is not, as far as I know, interested in a backend for telemetry.
JURACI: But at the same time they were and still are, probably interested in getting telemetry data out of their OpenShift clusters or Kubernetes clusters. So it does make sense to have a support for a service of some sort, like OpenCensus service. When we had a disfusion of OpenTracing and OpenCensus, then I continued working on...well then I officially started working on the OpenTelemetry Collector. It was renamed, and that prevailed until today. I continued focusing on OpenTelemetry. And a few years ago Grafana got in touch with me and know we are highly interested in OpenTelemetry and we need someone who's already in the community to help us navigate this community and understand what's going on and bring what's new inside the company and help the company provide also support for the project in whatever way makes sense for the company.
ADRIANA: Oh, that's so awesome. That's so awesome. It's nice to have your work recognized like that, where a company comes to you and they're like, hey, I like what you're doing, it's wonderful.
JURACI: Yeah, I can say that I'm really blessed to work with what I really like. I really like the project OpenTelemetry. I like what I do on a daily basis. I like of course, the Collector. I like writing new components and so on and so forth. But I also enjoy the community side of it. And I think that's a huge part of what I do nowadays is building bridges. It's making connections between people and it is also empowering other people.
JURACI: So helping people achieve what they want, both in terms of community and their professional goals as well. I think I'm very blessed to be where I am right now.
ADRIANA: I love that so much because I think it's so important. People really underestimate the power of connections and community. And I completely agree with you. One of my favorite things is being able to connect people. And sometimes you'll have a conversation with Person A, and then you'll have a conversation with Person B, and maybe the stuff that you're talking about, it's like peripherally interesting. But then person A and person B have the thing in common and you know both of them now you can connect them. And I think it's so cool to be able to make those kinds of connections and make introductions and see the sparks fly. I think that's so amazing.
JURACI: I love that. And I love seeing the results a few months later as well. And then you look back and you see, oh, something came out of that and that's really cool. So I love that as well.
ADRIANA: Yeah, amazing. I just want to turn back to the OTel Collector because I'm very intrigued. I had no idea that the Collector was actually like a component of OpenTracing that got ported over to, sorry, OpenCensus that got ported over to OpenTelemetry. That's so cool. When I first got wind of the OTel Collector, immediately I decided that was like my favourite thing about OpenTelemetry. I don't know why I think it's so cool what it can do. I don't know. I love this idea where especially because so many Observability back ends, they all have their different agents, and the OTel Collector is basically the vendor agnostic agent that will do all the things and will ingest the data from different sources.
ADRIANA: And then my absolute favourite is being able to send it to different simultaneous sources and to be able to see, like if you're evaluating a particular vendor, you can see how the same information ends up being rendered differently by the different vendors, and then that becomes the differentiating factor between the vendors. I think that's so cool because then the vendors don't have to compete on the data format itself. Really what's distinguishing is what do they do with the data to make it useful to you to troubleshoot. And I think that's so, so awesome.
JURACI: Yeah, I think that's beautiful also for the Collector, of course. But I'm looking back the industry a decade ago, right, we see that vendors were fighting for the instrumentation. So they were saying, oh, you want the best of your services, you want the best telemetry data out of your systems, then you install my agent here. And then another vendor would just come and say, oh, you should use mine. And if you wanted both, you couldn't just use both agents. They would conflict and one would very likely have troubles with the other. They cannot run at the same time. If they did, it was not on purpose.
JURACI: On any issues, any problems, you would call one vendor and they would point fingers to each other. Now the situation has changed drastically today, so today, I like to say that instrumentation is commoditized. It is not where is not where the fight is right now. Of course, there are still vendors offering their own agents and whatnot, but it's not really where the differentiation is. And it's not the collector either. Or it's not the infra that helps a data from A to B. It is really on the back end. It is really how you build a scalable back end for metrics, logs, traces, profiles, and RUM and so on and so forth.
JURACI: And that's where innovation is. That's where the differentiation is right now. And I think the Collector helps people who are still on the old way of doing things, and they want to get into the new way of doing things. And it is the part that you just drop into your infra without changing anything. You just drop it there and it just works. And it will just help you achieve something today right now. So you can certainly keep using your current vendor, but you can also multiplex or send out or send the same data to another vendor. And as you said, just compare the same data visualized in different ways.
JURACI: I think that's why the Collector is so it gets a lot of attention or gets our attention, right, because it is such a powerful and yet easy to implement solution that allows people to get started really quick. I mean, for instrumentation, it's nice that I can follow a tutorial on a website and learn how to instrument things and learn how to apply like Java agent or the Go auto-instrumentation and so on and so forth. But the practical results on my daily routine, they take longer to reflect than the Collector. I think that's what makes the Collector very special. And it is also the versatility of the Collector right now. I mean, just today someone was mentioning, oh, I'm playing with the tail sampling processor, and I'm applying span metrics after that. And of course, we know this is a problem, right? And the person came to that realization that it is a problem, because now I'm doing metrics only on 10% of my traces. So how do I solve that? And then with the Collector, in like five or ten minutes, I was able to get into a configuration where we have connectors and we have traces going in and connectors sending the same data to two different pipelines.
JURACI: And one of them is with the span metrics, the other one with the tail sampling, and that's it. Voilà. It's like a chef of the cuisine that would just get a recipe there for a very nice and tasty dish there. So I think that's what I like about the Collector as well, its versatility.
ADRIANA: Yeah, absolutely. And it's so cool to also see the different because there are so many different receivers available for the Collector now where it can ingest from so many different data formats, which is awesome. So then it's like exactly what you said. You can just drop it in. You don't have to disrupt your existing system. I think I've heard some scenarios where people were using statsd and it's like, great. You can just drop a Collector there to ingest the data from statsd until you're ready to remove that part. You can just keep it running business as usual, which is really nice.
ADRIANA: And then the other thing that I find interesting and not necessarily a Collector thing, but an overall OTel thing, that when OTel started, I think there were very few vendors that used to ingest data in the OTLP format. And so there were different exporters for these different vendors. But it's been really cool to see many, many vendors now being able to support the native OTLP format, basically rendering these exporters obsolete, which is amazing, right? Because it just goes to show how many vendors are actually taking OpenTelemetry seriously.
JURACI: Absolutely, yes. And it is a quite different view of the road from a few years ago. Right? I mean, a few years ago we still had vendors wondering if this OpenTelemetry thing is here to stay or not. And can I just perhaps rename my monitoring pages to Observability and be done with it? Can I ignore OpenTelemetry altogether? They realize it's not the case, so it's not enough. And they have to at least ingest or accept that OpenTelemetry exists. They don't have to be part of the community, so we don't have this requirement. They can just live on their own island. They can ingest OTLP.
JURACI: That's fine. Their customers are requesting them to ingest OTLP. So that's why we are doing our customers, all of our customers, they do want to generate, know, commoditize instrumentation that we talked about before, and now they want to send data to you because you are providing a very nice solution there. And if you don't, they're not going to give you another chance. They're going to go to another vendor. And I think that's how it is today and I think it's beautiful where we are right now.
ADRIANA: Yeah, I really love it. When I first started learning about OpenTelemetry, I want to say it was around 2021 and I was working at Tucows and I was running an Observability practices team there and traces had not even been in GA yet. And I'm like sitting there telling no, no, this is going to be a big thing, you just wait. And I'm so so happy to see how much it's grown since then. And now we're at a point where metrics, I believe are in GA. I think logs are stable, right? I think at this point?
JURACI: The data model is. We don't have a logs API and we're not going to have one, right?
ADRIANA: Right. Right.
JURACI: Of course we realized, I think it was clear to everyone since the beginning, but there is an official realization that it doesn't make sense for us to come up with a new logging API. Logging is the older of all of the telemetry signals people have since they started writing code. So it doesn't make sense to try to come up with a new logging API and hope for people to use our APIs in the future. Coming from a Java road and you too, you can probably name more than five logging APIs there and logging frameworks, and we don't want that. We don't want to deal with that kind of problem at the OpenTelemetry level. So what we are doing is we have the Logs Bridge API and that is something that we can implement in every language, or almost every language, and interoperate with the instrumentation that people have today. So if they have SLF4J, for instance for Java, we can have an implementation of that for OpenTelemetry. So users still use the SLF4J API if they want and they have an OpenTelemetry implementation or the new slog library for Go.
JURACI: So we can implement a handler for that. And users are just going to use slog libraries for their code. But during the initialization of the logging library we can configure that to spit out OTLP, right?
ADRIANA: So basically for every, or I guess the goal at least is for every logging library out there, there's going to be like a logs bridge API that basically is that connector between taking that existing logging library and converting it to OTLP.
JURACI: Of course all of the libraries out there is a little bit too much, but...
ADRIANA: I guess the more popular ones I would imagine.
JURACI: And I guess that goes into a nice other side discussion that should that belong to OpenTelemetry, should that kind of work belong to OpenTelemetry? Or do we expect the logging framework implementers to provide such a bridge? Right, the same for instrumentation. So do we expect database client developers to integrate directly with OpenTelemetry or do we expect the OpenTelemetry community to provide instrumentation libraries for those database drivers, database lines?
ADRIANA: Yeah, that's actually a really excellent question. Has it been answered yet, or is it still under debate?
JURACI: Well, it is something that we did talk about during our OpenTelemetry Leadership Summit earlier this year. And the long term vision is of course that OpenTelemetry would become so successful and so pervasive that people are going to use OpenTelemetry everywhere. And we don't need to do the instrumentation on our side. People who are domain experts and coding experts on their side, they can do the instrumentation with OpenTelemetry libraries better than we can do it. And that free us up from the burden of the burden. Burden is probably the wrong word, but the burden of creating instrumentation libraries, so.
JURACI: We have to maintain them.
JURACI: So we have so many instrumentation libraries out there for Java, for go, it's impossible for the limited amount of maintainers that we have to keep them all up to date across all of the versions of all of the libraries. So it's a huge amount of work, and even if things work today, we are not sure they are going to work tomorrow.
ADRIANA: Yeah, that's a really excellent point. And I think it goes back to a piece of feedback that I heard in one of our OTel End User Working Group sessions from earlier this year, which is basically like, you've already got folks worrying about the API and SDK for each language, right? And that sucks a fair amount of time. But then now also having to deal with the third party libraries and not necessarily being an expert in that library, and you're having to rely on the goodwill of the community in some cases to be able to instrument those libraries, which is awesome that that sort of thing exists, but that is a massive, massive undertaking.
JURACI: Yeah, it is something that we have to think about for the future. We can start thinking about that today. And there are examples of projects doing that today, like using OpenTelemetry natively. But until Open Telemetry is like the winner or the perceived winner for all of the signals, or at least for metrics as well, then it is not going to be adopted by other projects natively. So if I'm a maintainer of a project that is starting right now, and perhaps it's becoming huge success in the future, do I really want to tie my users to this library here or to that library there? And if there are no clear winners for that right now, I should probably stay out. And it's perfectly understandable. I mean, for traces it's clear. We have OpenTracing, we have OpenCensus.
JURACI: They're now both OpenTelemetry. What about metrics? So I think perhaps there is a discussion to have in the future, seeing how we progress. But at least for traces, we are there. So we can start that conversation now for traces.
ADRIANA: Yeah, and that's really good. Interesting point that you made on metrics, because it's a question that I've had for a while, because OpenMetrics also exists. So then what's the relationship between OpenMetrics and OpenTelemetry? Do you have any insight into that?
JURACI: Yeah. So OpenMetrics, we have the Prometheus working group as part of OpenTelemetry, and I think it fits there. So we have folks from the OpenMetrics project joining the Prometheus WG for OpenTelemetry. And our idea is that we should...so OpenTelemetry should be compatible or interoperable with OpenMetrics and Prometheus. So OpenMetrics is the format, is the exposition format for Prometheus, basically. So if we want to expose data in Prometheus format, we use an OpenMetrics, or we should use OpenMetrics specification for that. I think it is the other part of the project that is the acknowledgement that we are not alone and we're not alone there.
JURACI: So we have to play with the other players, we have to be interoperable with the other solutions. We have to have Zipkin, Jaeger, OpenCensus receivers for the Collector. They're not going to get away. They're not going to go away, and we don't want them to go away. It's part of a healthy ecosystem to have multiple implementations of the same solution. Same with metrics. So we want very good support for not only Prometheus, but for other metrics solutions out there as well.
ADRIANA: Yeah, right. Yeah. And that's a really great point, is acknowledging that there are people still using other protocols, other tools out there, and so being able to basically welcome them into open telemetry and playing nice in the sandbox is definitely an important message to give. Now, we are just about to wrap up, but before we do that, I did want to ask if there's anything that you're working on that you would like to promote and share with folks. Absolutely. I would love to share that here.
JURACI: Yes, absolutely. So one thing that I'm particularly passionate about is our participations in the Outreachy program. So, Outreachy is an internship that allows people coming from an underrepresented background in our industry in it. It allows them to get in a paid internship to work on open source projects. And since 2017, back with Jaeger and OpenTracing. I try to be part of this project. And this week we got a confirmation from the CNCF that we can have one intern working. So people who are in the industry, and if you know anyone who's having trouble getting into our industry because they are part of an underrepresented group of people, spread the word and help me find those people.
JURACI: And we are being part of this program once again. So the internships should start in December and finish in March, and we are going to have projects related to OpenTelemetry there.
ADRIANA: Amazing. And I also want to add that you have a weekly show in Portuguese called "Dose de Telemetria" which, if you're a Portuguese speaker, definitely check it out. I'll include it in the show notes. And also to congratulate Juraci on getting a speaking spot at KubeCon, North America in...oh my God, it escapes me. Contrib fest.
JURACI: Yes, that's right.
ADRIANA: Yes. Congrats. And also that Jurassi is a fellow CNCF ambassador, so wanted to throw that out. Great. Well, thank you so much, Jurassi, for geeking out with me today. Y'all. Don't forget to subscribe. Be sure to check out the show notes for additional resources and to connect with us and our guests on social media.
ADRIANA: Until next time, peace out and geek out. Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento me slash geeking out.
ADRIANA: Hey y'all, welcome to geeking out. The podcast about all geeky aspects of software delivery DevOps, observability, reliability and everything in between. I'm your host Adriana Villela. Coming to you from Toronto, Canada and geeking out with me today is Jurassi. Welcome Judasi.
JURACI: Thank you very much. And I'm surprised always when speaking English, people have a trouble speaking my name. That's not the case with you. You were perfect.
ADRIANA: Oh, thank you! So, Juraci, where are you calling from today?
JURACI: I'm calling from Berlin, Germany. Yeah, I'm freshly moved from Brazil back to Germany to Berlin. I'm here since 9 August, so I'm here less than a month now.
ADRIANA: Very cool. I've been to Berlin once when I was working in Munich, I took a train to the Love Parade.
JURACI: That's nice, that's wonderful.
ADRIANA: This was back in 2000.
JURACI: Okay, yeah, that's nice.
ADRIANA: I'd never been to the Love Parade. I was like, wow, it is an experience. It was a fun experience. So that's my experience with Berlin. I hope someday to actually see Berlin properly.
JURACI: Well, almost nothing here can top Love Parade. So you've experienced Berlin on its best.
ADRIANA: Awesome. So before we get going with the main content, I have a few lightning round questions that I like to ask all my guests. So don't worry, they're painless and they're fun. So let's get started. So first question, are you left handed or right handed?
JURACI: Oh, I'm left handed.
ADRIANA: Me too. I'm so excited to meet left handed people! Yay. Left handed and Brazilian. Best combo ever. I'm slightly biased. Next question. IPhone or Android?
JURACI: Oh, Android, that's easy. Open source? Well not so much, but yeah.
ADRIANA: Cool. Next one, do you prefer Mac, Linux or Windows?
JURACI: That's also easy. Linux.
ADRIANA: Awesome. Hardcore. Die hard, very cool. Okay, favorite programming language?
JURACI: Oh that's tough. I don't know, I'm using Go most of the time now, but Ruby still has a place in my heart. But I was a Java developer for so long, so I don't know, I mean a mix of Java, Ruby and Go now.
ADRIANA: Nice. Most of my career was as a Java developer. Sixteen years. So I have a love hate relationship with Java.
JURACI: I guess that's why I like Ruby so much, because Java provides you the security in so many aspects and Ruby is just like this nice language that is beautiful to read and it's fun to write. It might not be a perfect fit for everything, but it is a fresh view of the programming world for a Java programmer.
ADRIANA: Yes, very true, very true. Actually I know a lot of people who love Ruby because I think they describe it as being like a very simple, very elegant language.
JURACI: It is. Not only the language itself is very nice, but what you can do with that, you can build very beautiful DSLs with Ruby. And they really feel like DSLs, like domain specific languages. And when you build a DSL in Java, for instance, it still feels like Java. Right. But there are some DSLs in Ruby that you cannot tell it is Ruby. You really think that it's a new language built on purpose for that specific domain? I think that's what makes Ruby beautiful.
ADRIANA: That's very cool. Next question. Prefer Dev or ops?
JURACI: Dev.
ADRIANA: All right.
JURACI: I've been operating my own servers since like ever. And I love doing that. I ran my mail server for more than a decade now. I stopped a couple of years ago. I decided not to continue doing that for my own sanity.
ADRIANA: That's a lot of work.
JURACI: It is, but that side of operations is really very close to my heart. But still, I'm a developer.
ADRIANA: I feel you. All right, next one. JSON or YAML?
JURACI: Oh no. None?
ADRIANA: That's a fair answer.
JURACI: Well, if I have to pick one, then YAML, of course. But yeah, no...I don't know.
ADRIANA: Yeah, I prefer YAML over JSon. JSON's too garbly for me. Too much happening. It gives me Java vibes like so many curly braces.
JURACI: Yeah, and double quotes everywhere. In YAML you can just choose when to place it and when not to place it. And comments, I mean, you can place comments on YAML, you cannot with JSON.
ADRIANA: Oh yeah, that's true. Score for YAML. Okay, next question is, do you prefer to consume content through video or text?
JURACI: Okay, I'm still a text consumer, so books, articles. But I am on this verge of consuming more and more media in podcasts or presentations, like recorded presentations from conferences and so on. I find that. I think the best balance right now is a mix of all of them. There are some great content that has been provided in forms of tutorials and presentations at Kubecons for instance.
ADRIANA: Yeah.
JURACI: That you cannot find written anywhere, so you have to go and watch them at the same time. I find good old books very pleasant to read.
ADRIANA: Yeah, I definitely have to agree with you. Text is my default. I love a good podcast, especially like when I'm doing, running errands, walking, doing housework. It just gives my brain something to do. But yeah, I agree with you that there are some cases now where video is the only way to consume the content. So you kind of have to just power through.
JURACI: Had some, I don't know, I had some like, oh, YouTube. YouTubers. No, I refuse to do that. But then I think we are past that now. People are producing great. I mean, look at Prometheus, right? So Julius Volz is creating great videos on Prometheus and there is no one better, or there is almost no one better in the world that can talk about Prometheus. No bigger authority than Prometheus and him than Julius. And it's only in video.
JURACI: Of course he does have his courses and some written content, but the videos are just great.
ADRIANA: That's awesome. Good to know. Good to know. And final question in our lightning round, what is your superpower?
JURACI: Oh, getting my kids in bed. I can do that better than anyone else. I just get them there and they fell asleep in a few minutes.
ADRIANA: Yeah, that is very impressive. I just have the one daughter and when she was little, oh my God, the excuses, the excuses.
JURACI: And I'm leveling up. I take care of two now because my youngest one is too young for me, I cannot breastfeed her. So mom still has to get her to sleep. But we are now transitioning also to no breastfeeding anymore. So in the future it's not going to be two kids, but three to get in bed.
ADRIANA: So then you'll really put your superpower to work. Amazing. Well, awesome. Thanks for playing along with the lightning round questions. So now onto the good stuff. So OpenTelemetry...I want to talk to you about...because you are one of the OpenTelemetry maintainers, right? What's your specific role in the OpenTelemetry community?
JURACI: I wear quite a few hats actually, but two of them are really big. And perhaps the biggest hat that I have right now in the OpenTelemetry community is on the Collector SIG. So I'm a code owner for a few components of OpenTelemetry Collector, especially around the contrib repository. So things like the tail sampling processor or the load balancing exporter, or routing processor and routing connector now and a few other things. And of course Grafana specific components like the Loki receiver and exporter. I'm also part of the Governance Committee or the Governance Board for OpenTelemetry. So I think that's my second biggest hat there. But I'm around in a making...I don't know...creating confusion in other SIGs as well.
JURACI: I guess that's what I can describe.
ADRIANA: Awesome. I don't know if you heard that sound. Yeah. So there is in Toronto right now, we call it like the Canadian National Exhibition. It's basically like, I don't know, like a two week fair amusement park thing. And this time of year they have like fighter jets, they do like an aerial show. And even though we're not that close to where it's at, I want to say it's about. Probably about 4 km away from where I am, but it's freaking loud.
ADRIANA: And they practice around this time. And I think the air show is this weekend because Labor Day weekend. Yeah. Anyway, that's where that horrid sound came from. That was super freaking loud. So one of the things I wanted to ask in your OpenTelemetry role, so what does the governance committee do?
JURACI: Right, that's a great question. In the best case scenario, we don't do anything, but we are effectively the maintainers from the CNCF's perspective. So we are the ones taking the decisions on behalf of the project, especially when it comes to official decisions. So if there are any resource requests, especially involving money, that needs to go through the CMCF, then it has to go through the Governance Committee, the Governance Board, and we wouldn't take a look at those requests and we decide, oh, it does make sense, or it is good for the project, or it is not very nice for the project to do that. So this is the very bureaucratic view of the government. So we sign the request and things like that. Practically, in practical terms, what we do is we take care of organizing our events for KubeCon, for instance. So we apply for specific places, for specific talks at the maintenance track, for instance, or the contribfest.
JURACI: We applied for this KubeCon, but we also mediate conflicts. And this is, I think, the most important part of the GB, the governance board or the GC. The Governance Committee, as we usually call it, the GC. And that is whenever we see something that can negatively impact the OpenTelemetry community, it is our duty to act on it. So there was a case a year or so ago where at the beginning of the year, where there were some concerns about one specific thing. And as a GC member, we have to go and see those allegations and go and see what is behind it. And is there any concern for OpenTelemetry as a community because of that? And if there is, we have to act on. But it is our ultimate responsibility to take care of OpenTelemetry as a project and as a community.
JURACI: I think that's mainly how I see the OpenTelemetry role. Of course, we also have a say, so not the say, but we have a say in the roadmap so we try to build or establish a roadmap for the project. But because the way that we structure the project, every SIG is independent, and every person collaborating in the project or with the project has the freedom to do whatever they want. We cannot just go to the Collector contributor and say, hey, Juraci, you have to work on this receiver here. That's not how it works. We have to plan ahead. Of course, as part of the GC, we have to think about it and think, when do we want to do AGA for the project as a whole? Do we want to graduate or not? What do we want for the future? And once we know that, once we have that kind of vision, project wide vision, we try to get the message out and tell other maintainers. So this is where we think the project should be going.
JURACI: So can we try to make a concerted effort to get there as a project? Most of the time we fail, but I guess that it is useful nonetheless. We were able to get a focus on metrics for a few months, and then we got metrics out, and we also got a concerted effort around logs, and logs are now also out. So for the most part. So I think it does work, but it is a fair question because it's not very clear when we are out what the GC should be doing.
ADRIANA: Well, it sounds like GC wears a lot of hats. There's a lot going on in the GC.
JURACI: Well, we got to meet every week for about an hour, and that's pretty much all of the time that we have. So we can say that we have 1 hour of work per week. Most of the time, we discuss the whole hour. So we have quite a few things to talk about, but most of them are, I have to admit, they're kind of mundane. Right? So like a company, X wants to assess whether it makes sense to have a set of features for a specific platform, right? So then we go around and ask people, does that make sense? Does that not make sense for us?
ADRIANA: So then how do you communicate, since the GC does, I guess, has a hand in the overall vision for OpenTelemetry, how do you communicate that information to the different SIGs to make sure that things move in that direction, even if you're not successful, but to at least communicate the idea, even if it doesn't necessarily get implemented, or maybe not implemented in the way that was originally envisioned?
JURACI: Yeah, that's a good question. We have a diverse set of GC members. We have two people from the collector SIG. We have people that are not part of any other SIGs. We have two people who are part of the TC, the technical committee as well. We have people who are users of OpenTelemetry in ODIC. So what we do today is we use the other hats for the GC members so that information can spread around. So we have the Collector folks bringing information into the Collector SIG, but we also have GC members joining the Monday's maintainers call.
JURACI: So we have a call every Monday for maintainers of OpenTelemetry. So we have a GC member joining that call and bringing the updates to that group. We also have a monthly GC plus TC call where we have a discussion between the two committees discussing things that are relevant for the project as a whole, but also making sure that information flows basically. And the TC is then responsible for ensuring that the technical direction of the project is set and followed by the individual.
ADRIANA: Okay. Okay. Yeah, that makes a lot of sense. Cool. So now, taking a step back, my question is, how did you get involved in OpenTelemetry in the first place?
JURACI: I like to say that I'm part of OpenTelemetry since it was not OpenTelemetry. Right. I mean, I was part of the OpenTracing group back then.
ADRIANA: Oh, very cool.
JURACI: I was actually part of perhaps the first KubeCon where OpenTelemetry had an appearance. And it was actually here in Berlin in 2017. I think it was KubeCon Europe was very small back then, I think not even like 1000 people.
ADRIANA: Oh, my God.
JURACI: Yeah. Comparing now, like with Amsterdam. It's a totally different vibe.
ADRIANA: That was outrageously huge. And I think Chicago is going to be even bigger, I think.
JURACI: So, yeah. I'm really looking forward to it. But back then in 2017, we had a, I think it was a tutorial. Me, Priyanka Sharma, who is now executive director of the CNCF, and Ted Young, your colleague, Ted Young. We were there doing an OpenTracing tutorial back then, and it was really fun. I mean, we had a 90 minutes session there, people trying to instrument their applications using Go and OpenTracing and facing all sorts of problems. And things were working, but barely, but it was fun. So I joined back then and things just evolved from there.
JURACI: Right. So we got, in 2019, perhaps, we joined forces with OpenCensus, then we formed OpenTelemetry in perhaps a little bit later than 2019, but then here we are. And I started contributing with the Collector when we joined forces, because I thought the Collector was a really cool technology back then it was part of OpenCensus service, so it was already getting our attention at RedHat back then, we thought this is a cool piece of technology that can really free up people. Not free up, but to liberate people from vendors if they want to do so. Right. So people can start using the service to make translations and they can decide at the service, OpenCensus service. Back then they can decide where to send their data. For a company like RedHat, that made a lot of sense because RedHat was not, and is not, as far as I know, interested in a backend for telemetry.
JURACI: But at the same time they were and still are, probably interested in getting telemetry data out of their OpenShift clusters or Kubernetes clusters. So it does make sense to have a support for a service of some sort, like OpenCensus service. When we had a disfusion of OpenTracing and OpenCensus, then I continued working on...well then I officially started working on the OpenTelemetry Collector. It was renamed, and that prevailed until today. I continued focusing on OpenTelemetry. And a few years ago Grafana got in touch with me and know we are highly interested in OpenTelemetry and we need someone who's already in the community to help us navigate this community and understand what's going on and bring what's new inside the company and help the company provide also support for the project in whatever way makes sense for the company.
ADRIANA: Oh, that's so awesome. That's so awesome. It's nice to have your work recognized like that, where a company comes to you and they're like, hey, I like what you're doing, it's wonderful.
JURACI: Yeah, I can say that I'm really blessed to work with what I really like. I really like the project OpenTelemetry. I like what I do on a daily basis. I like of course, the Collector. I like writing new components and so on and so forth. But I also enjoy the community side of it. And I think that's a huge part of what I do nowadays is building bridges. It's making connections between people and it is also empowering other people.
JURACI: So helping people achieve what they want, both in terms of community and their professional goals as well. I think I'm very blessed to be where I am right now.
ADRIANA: I love that so much because I think it's so important. People really underestimate the power of connections and community. And I completely agree with you. One of my favorite things is being able to connect people. And sometimes you'll have a conversation with Person A, and then you'll have a conversation with Person B, and maybe the stuff that you're talking about, it's like peripherally interesting. But then person A and person B have the thing in common and you know both of them now you can connect them. And I think it's so cool to be able to make those kinds of connections and make introductions and see the sparks fly. I think that's so amazing.
JURACI: I love that. And I love seeing the results a few months later as well. And then you look back and you see, oh, something came out of that and that's really cool. So I love that as well.
ADRIANA: Yeah, amazing. I just want to turn back to the OTel Collector because I'm very intrigued. I had no idea that the Collector was actually like a component of OpenTracing that got ported over to, sorry, OpenCensus that got ported over to OpenTelemetry. That's so cool. When I first got wind of the OTel Collector, immediately I decided that was like my favourite thing about OpenTelemetry. I don't know why I think it's so cool what it can do. I don't know. I love this idea where especially because so many Observability back ends, they all have their different agents, and the OTel Collector is basically the vendor agnostic agent that will do all the things and will ingest the data from different sources.
ADRIANA: And then my absolute favourite is being able to send it to different simultaneous sources and to be able to see, like if you're evaluating a particular vendor, you can see how the same information ends up being rendered differently by the different vendors, and then that becomes the differentiating factor between the vendors. I think that's so cool because then the vendors don't have to compete on the data format itself. Really what's distinguishing is what do they do with the data to make it useful to you to troubleshoot. And I think that's so, so awesome.
JURACI: Yeah, I think that's beautiful also for the Collector, of course. But I'm looking back the industry a decade ago, right, we see that vendors were fighting for the instrumentation. So they were saying, oh, you want the best of your services, you want the best telemetry data out of your systems, then you install my agent here. And then another vendor would just come and say, oh, you should use mine. And if you wanted both, you couldn't just use both agents. They would conflict and one would very likely have troubles with the other. They cannot run at the same time. If they did, it was not on purpose.
JURACI: On any issues, any problems, you would call one vendor and they would point fingers to each other. Now the situation has changed drastically today, so today, I like to say that instrumentation is commoditized. It is not where is not where the fight is right now. Of course, there are still vendors offering their own agents and whatnot, but it's not really where the differentiation is. And it's not the collector either. Or it's not the infra that helps a data from A to B. It is really on the back end. It is really how you build a scalable back end for metrics, logs, traces, profiles, and RUM and so on and so forth.
JURACI: And that's where innovation is. That's where the differentiation is right now. And I think the Collector helps people who are still on the old way of doing things, and they want to get into the new way of doing things. And it is the part that you just drop into your infra without changing anything. You just drop it there and it just works. And it will just help you achieve something today right now. So you can certainly keep using your current vendor, but you can also multiplex or send out or send the same data to another vendor. And as you said, just compare the same data visualized in different ways.
JURACI: I think that's why the Collector is so it gets a lot of attention or gets our attention, right, because it is such a powerful and yet easy to implement solution that allows people to get started really quick. I mean, for instrumentation, it's nice that I can follow a tutorial on a website and learn how to instrument things and learn how to apply like Java agent or the Go auto-instrumentation and so on and so forth. But the practical results on my daily routine, they take longer to reflect than the Collector. I think that's what makes the Collector very special. And it is also the versatility of the Collector right now. I mean, just today someone was mentioning, oh, I'm playing with the tail sampling processor, and I'm applying span metrics after that. And of course, we know this is a problem, right? And the person came to that realization that it is a problem, because now I'm doing metrics only on 10% of my traces. So how do I solve that? And then with the Collector, in like five or ten minutes, I was able to get into a configuration where we have connectors and we have traces going in and connectors sending the same data to two different pipelines.
JURACI: And one of them is with the span metrics, the other one with the tail sampling, and that's it. Voilà. It's like a chef of the cuisine that would just get a recipe there for a very nice and tasty dish there. So I think that's what I like about the Collector as well, its versatility.
ADRIANA: Yeah, absolutely. And it's so cool to also see the different because there are so many different receivers available for the Collector now where it can ingest from so many different data formats, which is awesome. So then it's like exactly what you said. You can just drop it in. You don't have to disrupt your existing system. I think I've heard some scenarios where people were using statsd and it's like, great. You can just drop a Collector there to ingest the data from statsd until you're ready to remove that part. You can just keep it running business as usual, which is really nice.
ADRIANA: And then the other thing that I find interesting and not necessarily a Collector thing, but an overall OTel thing, that when OTel started, I think there were very few vendors that used to ingest data in the OTLP format. And so there were different exporters for these different vendors. But it's been really cool to see many, many vendors now being able to support the native OTLP format, basically rendering these exporters obsolete, which is amazing, right? Because it just goes to show how many vendors are actually taking OpenTelemetry seriously.
JURACI: Absolutely, yes. And it is a quite different view of the road from a few years ago. Right? I mean, a few years ago we still had vendors wondering if this OpenTelemetry thing is here to stay or not. And can I just perhaps rename my monitoring pages to Observability and be done with it? Can I ignore OpenTelemetry altogether? They realize it's not the case, so it's not enough. And they have to at least ingest or accept that OpenTelemetry exists. They don't have to be part of the community, so we don't have this requirement. They can just live on their own island. They can ingest OTLP.
JURACI: That's fine. Their customers are requesting them to ingest OTLP. So that's why we are doing our customers, all of our customers, they do want to generate, know, commoditize instrumentation that we talked about before, and now they want to send data to you because you are providing a very nice solution there. And if you don't, they're not going to give you another chance. They're going to go to another vendor. And I think that's how it is today and I think it's beautiful where we are right now.
ADRIANA: Yeah, I really love it. When I first started learning about OpenTelemetry, I want to say it was around 2021 and I was working at Tucows and I was running an Observability practices team there and traces had not even been in GA yet. And I'm like sitting there telling no, no, this is going to be a big thing, you just wait. And I'm so so happy to see how much it's grown since then. And now we're at a point where metrics, I believe are in GA. I think logs are stable, right? I think at this point?
JURACI: The data model is. We don't have a logs API and we're not going to have one, right?
ADRIANA: Right. Right.
JURACI: Of course we realized, I think it was clear to everyone since the beginning, but there is an official realization that it doesn't make sense for us to come up with a new logging API. Logging is the older of all of the telemetry signals people have since they started writing code. So it doesn't make sense to try to come up with a new logging API and hope for people to use our APIs in the future. Coming from a Java road and you too, you can probably name more than five logging APIs there and logging frameworks, and we don't want that. We don't want to deal with that kind of problem at the OpenTelemetry level. So what we are doing is we have the Logs Bridge API and that is something that we can implement in every language, or almost every language, and interoperate with the instrumentation that people have today. So if they have SLF4J, for instance for Java, we can have an implementation of that for OpenTelemetry. So users still use the SLF4J API if they want and they have an OpenTelemetry implementation or the new slog library for Go.
JURACI: So we can implement a handler for that. And users are just going to use slog libraries for their code. But during the initialization of the logging library we can configure that to spit out OTLP, right?
ADRIANA: So basically for every, or I guess the goal at least is for every logging library out there, there's going to be like a logs bridge API that basically is that connector between taking that existing logging library and converting it to OTLP.
JURACI: Of course all of the libraries out there is a little bit too much, but...
ADRIANA: I guess the more popular ones I would imagine.
JURACI: And I guess that goes into a nice other side discussion that should that belong to OpenTelemetry, should that kind of work belong to OpenTelemetry? Or do we expect the logging framework implementers to provide such a bridge? Right, the same for instrumentation. So do we expect database client developers to integrate directly with OpenTelemetry or do we expect the OpenTelemetry community to provide instrumentation libraries for those database drivers, database lines?
ADRIANA: Yeah, that's actually a really excellent question. Has it been answered yet, or is it still under debate?
JURACI: Well, it is something that we did talk about during our OpenTelemetry Leadership Summit earlier this year. And the long term vision is of course that OpenTelemetry would become so successful and so pervasive that people are going to use OpenTelemetry everywhere. And we don't need to do the instrumentation on our side. People who are domain experts and coding experts on their side, they can do the instrumentation with OpenTelemetry libraries better than we can do it. And that free us up from the burden of the burden. Burden is probably the wrong word, but the burden of creating instrumentation libraries, so.
JURACI: We have to maintain them.
JURACI: So we have so many instrumentation libraries out there for Java, for go, it's impossible for the limited amount of maintainers that we have to keep them all up to date across all of the versions of all of the libraries. So it's a huge amount of work, and even if things work today, we are not sure they are going to work tomorrow.
ADRIANA: Yeah, that's a really excellent point. And I think it goes back to a piece of feedback that I heard in one of our OTel End User Working Group sessions from earlier this year, which is basically like, you've already got folks worrying about the API and SDK for each language, right? And that sucks a fair amount of time. But then now also having to deal with the third party libraries and not necessarily being an expert in that library, and you're having to rely on the goodwill of the community in some cases to be able to instrument those libraries, which is awesome that that sort of thing exists, but that is a massive, massive undertaking.
JURACI: Yeah, it is something that we have to think about for the future. We can start thinking about that today. And there are examples of projects doing that today, like using OpenTelemetry natively. But until Open Telemetry is like the winner or the perceived winner for all of the signals, or at least for metrics as well, then it is not going to be adopted by other projects natively. So if I'm a maintainer of a project that is starting right now, and perhaps it's becoming huge success in the future, do I really want to tie my users to this library here or to that library there? And if there are no clear winners for that right now, I should probably stay out. And it's perfectly understandable. I mean, for traces it's clear. We have OpenTracing, we have OpenCensus.
JURACI: They're now both OpenTelemetry. What about metrics? So I think perhaps there is a discussion to have in the future, seeing how we progress. But at least for traces, we are there. So we can start that conversation now for traces.
ADRIANA: Yeah, and that's really good. Interesting point that you made on metrics, because it's a question that I've had for a while, because OpenMetrics also exists. So then what's the relationship between OpenMetrics and OpenTelemetry? Do you have any insight into that?
JURACI: Yeah. So OpenMetrics, we have the Prometheus working group as part of OpenTelemetry, and I think it fits there. So we have folks from the OpenMetrics project joining the Prometheus WG for OpenTelemetry. And our idea is that we should...so OpenTelemetry should be compatible or interoperable with OpenMetrics and Prometheus. So OpenMetrics is the format, is the exposition format for Prometheus, basically. So if we want to expose data in Prometheus format, we use an OpenMetrics, or we should use OpenMetrics specification for that. I think it is the other part of the project that is the acknowledgement that we are not alone and we're not alone there.
JURACI: So we have to play with the other players, we have to be interoperable with the other solutions. We have to have Zipkin, Jaeger, OpenCensus receivers for the Collector. They're not going to get away. They're not going to go away, and we don't want them to go away. It's part of a healthy ecosystem to have multiple implementations of the same solution. Same with metrics. So we want very good support for not only Prometheus, but for other metrics solutions out there as well.
ADRIANA: Yeah, right. Yeah. And that's a really great point, is acknowledging that there are people still using other protocols, other tools out there, and so being able to basically welcome them into open telemetry and playing nice in the sandbox is definitely an important message to give. Now, we are just about to wrap up, but before we do that, I did want to ask if there's anything that you're working on that you would like to promote and share with folks. Absolutely. I would love to share that here.
JURACI: Yes, absolutely. So one thing that I'm particularly passionate about is our participations in the Outreachy program. So, Outreachy is an internship that allows people coming from an underrepresented background in our industry in it. It allows them to get in a paid internship to work on open source projects. And since 2017, back with Jaeger and OpenTracing. I try to be part of this project. And this week we got a confirmation from the CNCF that we can have one intern working. So people who are in the industry, and if you know anyone who's having trouble getting into our industry because they are part of an underrepresented group of people, spread the word and help me find those people.
JURACI: And we are being part of this program once again. So the internships should start in December and finish in March, and we are going to have projects related to OpenTelemetry there.
ADRIANA: Amazing. And I also want to add that you have a weekly show in Portuguese called "Dose de Telemetria" which, if you're a Portuguese speaker, definitely check it out. I'll include it in the show notes. And also to congratulate Juraci on getting a speaking spot at KubeCon, North America in...oh my God, it escapes me. Contrib fest.
JURACI: Yes, that's right.
ADRIANA: Yes. Congrats. And also that Jurassi is a fellow CNCF ambassador, so wanted to throw that out. Great. Well, thank you so much, Jurassi, for geeking out with me today. Y'all. Don't forget to subscribe. Be sure to check out the show notes for additional resources and to connect with us and our guests on social media.
ADRIANA: Until next time, peace out and geek out. Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento me slash geeking out.