I Heart 💗 Observability with Iris Dyrmishi of FARFETCH

About the guest:

Iris Dyrmishi is a Tech Platform Engineer at FARFETCH. She is passionate about building systems that leverage Observability to ensure their performance, scalability and reliability. Recently, she has been working with OpenTelemetry and exploring how her organization can use it to improve our observability platform. 

Find our guest on:

Find us on:

Show Links:

Transcript:

ADRIANA: Hey, y'all. Welcome to On-Call Me Maybe, the podcast about DevOps, SRE, observability principles, on-call, and everything in between. I am your host, Adriana Villela, and with me, my awesome co-host...

ANA: Ana Margarita Medina.

ADRIANA: And today, we have Iris Dyrmishi, who is an Infrastructure Engineer at FARFETCH. Welcome, Iris. 

IRIS: Thank you. 

ADRIANA: So first things first, we're switching things up a little bit today. We'd like to know where you're calling in from.

IRIS: I'm calling in from Porto, Portugal. [laughs]

ADRIANA: Awesome.

IRIS: I think that's pretty far away from where you're at, Adriana. Where are you calling in from?

ADRIANA: I'm in Toronto, Canada. And Ana?

ANA: I'm here in the San Francisco Bay Area, California.

ADRIANA: So we are spanning three time zones today. [laughter] I love it. That's one thing I like about the show is that we get to talk to folks from all across the globe. Classic On-Call Me Maybe question for you, Iris, is what are you drinking?

IRIS: Today I'm drinking a caramel boba with rainbow toppings, so I'm very happy with my drink. [laughter]

ANA: You said the magic words. You said boba. [laughter] And I also love that it's rainbow toppings, like, [laughter] hell yeah.

ADRIANA: Rainbows make the world go round. [laughs] How about you, Ana, what are you drinking?

ANA: Today, I decided to pick up one of the Starbucks strawberry refreshers. And I do have a long day of work, so I just ordered a trenta-sized drink which is bigger than my face. [laughter]

ADRIANA: It's a big drink. [laughs] I don't think I've ever known anyone ordering one of those. That's cool. [laughs]

ANA: I will only do it for the teas. Like, if I know I need to hydrate and want a flavorful, sugary drink, I was like, it's worth the money.

ADRIANA: Yeah. Can you imagine that much coffee? [laughs] You can be jittery by the end of the day. [laughs]

ANA: I actually think they don't sell coffee drinks in trenta size. I think I looked into it once because it's like a heart attack waiting to happen.

ADRIANA: Yeah, I feel like I'm feeling a heart attack without even having had that. [laughter]

ANA: What are you drinking, Adriana?

ADRIANA: Today, I had the presence of mind to make myself a matcha green tea. So I'm very excited to have something a little bit different other than water. [laughter]

ANA: Yums. Always got to stay cozy.

ADRIANA: Yeah, totally. It's kind of a coldish day in Toronto. We're supposed to be expecting a big blizzard later today. [laughs] So this is my pre-emptive coziness.

ANA: [laughs] Blizzards are never fun. And, I mean, I think that's kind of been the interesting part where we have all these weird climates going on right now. Everyone is kind of in some form of storm around the world; it seems like.

ADRIANA: Yeah, it's true. How's the weather in Porto?

IRIS: Well, it's pretty sunny but also very chilly because of the Northern stream. It's always very windy here. 

ADRIANA: Oh.

IRIS: So the temperature might be around 12-13 degrees, but it feels very cold because of the wind.

ADRIANA: It's like a windy San Francisco day. [laughter]

ANA: Sounds very normal to my life. [laughter]

IRIS: There is no beach for us. That's for sure. [laughter]

ANA: Well, Iris, the first question that we wanted to ask you for today's podcast is, how did you get started in technology?

IRIS: It's actually a very interesting story because, okay, I've been a tech nerd, let's say, since I was a little girl when I got my first computer at 9. I loved taking computers apart, [laughs] breaking them, fixing them.

ANA: Hell yeah.

IRIS: And when I was about to go to university, I had my mindset that I was going to study computer science. I come from Albania, actually, the other part of Europe. And I applied for university, but then I received a scholarship in another university in Bulgaria, [laughs] so I decided to go there. And I said, okay, computer science is too hard, so I'm not going to be able to maintain a good GPA. I'm going to go for something easier. And economics was the first thing that came to my mind, so I switched from a tech person to economics. 

And then I had this very good friend I have actually, and she gave me the pep talk: never forget your dreams [laughs] no matter how hard it is. And it actually worked. [laughs] So I enrolled in computer science classes, and I never looked back. I'm very happy that she convinced me. [laughs] And I did keep my GPA, fortunately, so yeah, there were no issues there. [laughs]

ANA: That is awesome. It's always nice when you have people that kind of give you that push of like; you can do this, like, you are capable of it.

IRIS: Yeah. And, for me, you know, there are some people that say that "Oh, if I didn't have to earn more money or if it wasn't difficult to get a job in another area, I will probably be doing that." It's not like that. For me, it's technology. My passion is technology, and I'm actually doing it. So it's amazing. [laughs] It's a great combination.

ADRIANA: Oh my goodness, living the dream. That's so awesome. So with your computer science degree, how did it lead you to your current career path?

IRIS: Actually, in university, I majored in computer science with a background in software engineering. So I worked for three months as a back-end developer. [laughs] And then the company that I was working for needed people to switch to DevOps and to train them, so I was like, okay, [laughs] so I went there. And yeah, that's how it started for me. 

We were doing small work in different customer companies setting up monitoring for them. And that's when I started becoming very curious and liking that sort of thing. And then, I switched to the job that I'm currently at. And we're actually creating our own platform. And it just got from the small pleasures of setting up small monitoring here and there to building a full observability platform. So yeah, [laughs] that's how it started, and that's how it's going. [laughs]

ADRIANA: Wow, that is super exciting. And you got into...so it sounds like you got into DevOps pretty early into your career, too, which is cool.

IRIS: Yes. In my university, surprisingly, usually, in computer science degrees, DevOps is not really taught. So when I entered, I was like, what is this? [laughs] Like, what are these things that I never heard about? [laughs] So it was scary. But it's a good thing that I started when I was uncomfortable in the field altogether. I wasn't confident enough in software engineering either. [laughs] So I got into that pretty easily, and it was just a matter of learning.

ADRIANA: Very cool. It's interesting you mentioning that your university didn't teach anything about DevOps. And I think we've had similar conversations with other guests about there are certain things that you do out in the real world once you get your degree in computer science, computer engineering, whatever [laughs], but you're not taught this stuff in school. I think we've had a guest recently, Michael, who one of his first jobs out of school was SRE, which is kind of mind-blowing when you realize the fact that the only way to learn SRE is by doing it. And similarly, [laughs] for you, the only way to learn DevOps is by doing it. 

IRIS: Exactly. [laughs]

ANA: It's definitely an interesting trend because I do think we're starting to see universities pick up on people are not coming to our colleges because the education they get in computer science does not place them in a job right out of school because we know the interview loops for these jobs tend to be pretty tedious. And I think we're starting to see a lot more schools start to realize, like, we actually need to fill in that gap.

ADRIANA: Yeah, yeah. I really do hope to see more of that gap being filled in real life because we're definitely, yeah, we're still hurting. Circling back to a point that you made earlier when you were talking about building up a platform at your current workplace and getting to dig deeper into observability, can you tell us a little bit more about your observability journey?

IRIS: Let me start from the beginning. So my observability journey, as I said, started with just setting up. AWS was my weapon of choice. [laughs] That's where I practiced my first observability and basically just collecting metrics and in cloud setting up dashboards, setting up alerts. That's how it started. Then it progressed to building a full platform, basically orchestrating applications, building the infrastructure to actually scrape the metrics, collect the traces, and basically the logs as well. 

I don't know if I'm explaining myself properly in explaining the platform. But it went from actually using what we had, what was already generated by default, to building a platform that allows the teams to set up their own metrics and basically building tools to allow every team to be able to set up observability for their own application because they know it best. And what we do is we provide all the support that they need for infrastructure wise and all the guidance when it comes to metrics or traces, the guidelines about configurations, and stuff like that.

ADRIANA: Nice. I love to hear that because I've always been railing on people who are asking the teams who are not involved in the development to instrument their code. And I get so mad because it's like, [laughter] it makes no sense. I don't know your code. How can I instrument this? [laughter] It's very nice to hear that your team is providing guidelines but not doing the work for them because it's not really how it's supposed to work.

IRIS: Yeah. I believe observability is a responsibility of everyone. It's not just, for example, five people setting up everything for everyone. Every engineer has to do their part. We, of course, have to provide the tools to make that happen and to make that very easy so engineers are not spending all their hours in a day to set up monitoring and observability but that should be their responsibility as well. 

ADRIANA: Yeah, yeah, absolutely.

ANA: And it also just makes you a stronger engineer. I'm learning that skill set of being able to know how to instrument your code, how to be aware of the resources that it's actually taking up, to knowing that if you want to move up the career ladder and switch jobs or anything like that, that this is actually something that you are aware of. And you're not in that space where you're just throwing it up against the wall and hoping that it works and your customers are happy.

IRIS: And, at the same time, troubleshooting is a lot faster if you are the one who has set up the monitoring and observability for your application because if someone else did it for you, you will, of course, have to go to them for help to help you figure out your own application and your own code, what it is causing and why [laughs] it's breaking. So that's not ideal. [laughs]

ANA: It's like you and your team are going to know what functions you deployed in the last release versus the SRE team that has to manage ten services for the entire platform to work. Like, [laughs] why is there an increase in HTTP 400 errors for this one service that just got recently rolled out? [laughs] So, since you've been working in the space of observability for a bit, what do you say is one of the things you enjoy the most or your favorite?

IRIS: One of the things that I love the most is how fast the area of observability is moving. I feel like it's one of the areas with the most modern technologies. It's always building, always improving. For example, I work a lot with Prometheus. There are always new features coming, and currently, I'm working with OpenTelemetry, which I am in love with. 

ANA: Yay. [laughs]

IRIS: And you can imagine it's the most modern technology. You get your hands on some of the best things out there. So that's one of the things I love about observability right now. I don't know what's going to happen in five years. [laughs] I hope it continues the same.

ADRIANA: That's awesome. OpenTelemetry is near and dear to my heart. I got involved, I guess, more heavily involved as a contributor to OpenTelemetry after I joined Lightstep last year. Same as you, it's been super cool to watch it evolve. I would love to hear about some of your experiences with OpenTelemetry, the good and the bad.

IRIS: We are pretty new to OpenTelemetry. First of all, I heard about it last year. And I just played around with it a little bit, and it caught my attention. So now we actually had the space to work with it and the need to work with it. And I have to say I love it for the fact that, first of all, there is such big community support in OpenTelemetry, so it is very easy to actually implement it into an already running solution. You always find the Helm Charts are extremely helpful. There is very good documentation. 

And the other thing that I love about it is that it allows us to solidify our platform in one. Instead of using several tools, for example, logs, traces, metrics, we just use OpenTelemetry. 

ADRIANA: Nice.

IRIS: But my favorite part so far is how easy it is to just fit it right into an existing architecture and make it work without having to change everything [laughs] and spend months and months of work on it.

ADRIANA: That is really, really cool. I'm super stoked to hear that. What are the ways in which your own team uses OpenTelemetry? Do you guys stand up collectors? Or do you provide guidance on instrumentation to other teams? Like, what kinds of things do you guys do? 

IRIS: So, my team, we're responsible for the collector and the infrastructure in general. We have another team that is helping with the instrumentation. We work closely together, but my team works with our infrastructure. We are very close to setting it up in production, and I'm very excited about it, [laughs] the collectors. And then, we're going to start with the agents as well to make a full OpenTelemetry solution. [laughs] Currently, we're using Jaeger. So we are going to try and put them together until we have a full OpenTelemetry solution.

ANA: Nice. It's always nice when you kind of get to bring things together and start finding the entire space of observability. Like you said, being able to now have your traces, logs, and metrics all in one with OpenTelemetry is kind of like a nice little package.

IRIS: Yeah. And I have to say backwards compatibility as well is amazing. For example, I mentioned Jaeger earlier. It's just amazing [laughs] that we don't have to switch back and forth to make things work, and that's great for me.

ADRIANA: Yeah, yeah, totally. I think for me; the aha thing was that you're not locked into a particular vendor. So if you decide, hey, this vendor is working great for me now, but two years from now, nah, it's not working so well, you're not cussing [laughs] over the fact that crap, I got to re-do all this crap. And your developers are also not super mad at you after they've spent all this time instrumenting their code, and you have to be like, no, sorry, you have to use something else. [laughter] That's not the case with OpenTelemetry, which I absolutely love.

IRIS: Yeah, absolutely. [laughs]

ANA: I feel like we need a lot more tools in this space that have implementations like that, like the vendor agnostic open-source projects, because it is true, like, the amount of heavy lifting that a team or an individual needs to do because it's like, oh, sorry, this contract is going up by like $500,000 a year. A company can't support it anymore. And it's like, well, in order to rip this apart and go build it with another vendor, that's going to be another 500,000 anyway. So what is the company going to do? [laughs]

IRIS: Yeah. I can't imagine that for a big company that has engineering teams working with different technology, different programming languages. It must be a headache to switch. [laughs]

ADRIANA: Yeah, seriously. I feel like that would be a nightmare. So you guys, when you started implementing OpenTelemetry, was there anything already in place as far as implementing distributed tracing or metrics, like, any of the signals, any of the observability signals?

IRIS: Yeah, we do. We use Prometheus. We use Jaeger. We had basically a full monitoring platform with Prometheus Internal Grafana alert manager for alerting and, of course, Jaeger for tracing. So we did have existing platforms. And that's why OpenTelemetry seemed so attractive because we could get it right there without disrupting the whole thing. We work with many teams, and there are a lot of traces and a lot of metrics being collected. 

So we wouldn't take the risk of switching to another tool unless it really fit and it actually benefited us in this case. Because, yeah, Prometheus is an amazing tool, and we wouldn't just go and disrupt it. [laughs] A lot of people would be angry [laughs] if that happened, not being able to have observability at all.

ADRIANA: Yeah, I totally agree. So because of your existing stock, I guess it sounds like you guys didn't have to rip anything apart to be able to leverage OpenTelemetry right away.

IRIS: Yeah, yeah, exactly. We don't because it basically supports all the tools that we're currently using, and we build from there. We don't have to have a full solution and remove one and put the other. We can put it piece by piece, and we will have full availability 100%, and at the same time, implement OpenTelemetry until it's a full OpenTelemetry platform.

ADRIANA: Nice, nice.

ANA: No work goes wasted, which is always nice. [laughs] 

IRIS: Yeah.

ADRIANA: Now, keeping in with the observability theme, I think in our pre-chat, you mentioned having some experience around tracing. And, of course, you mentioned that you all use Jaeger at FARFETCH. Tracing, I feel like, is one of those controversial topics for folks getting into observability because they don't necessarily see the value of it. What are your thoughts around that? And share some of your experiences on tracing.

IRIS: I have to say it infuriates me. I'm a big [laughs] tracing fan, like a diehard tracing fan because...that infuriates me because I know there are so many engineers that say, "Oh, why do we need tracing when we have logs?" 

ADRIANA: Yes, yes. 

IRIS: And it's very important to make people understand what is the difference between them. And I feel like the job of observability or an SRE team is to also educate on these topics and help people understand and engineers understand how important tracing is and how different it is from logs.

So one thing that is with tracing is that it can be pretty expensive to have traces fully for teams. And that's why sometimes it is seen as something that, oh, we don't need it because not everything is saved; for example, we could have a 2% sampling size, 10%. It's never enough. Some spans, of course, might be dropped by the collectors. And people are like, oh, but this is not enough information. So I can understand the first one but logs and traces no. [laughs] I am completely against it. 

But this one, I understand because we can never get full sampling or maybe, yeah, if we spend a crazy amount of money. So people see that as a negative side to tracing. But there are ways that can be improved, and that's why I come back to OpenTelemetry. As I said, I'm very passionate about it [laughs], and tail-based sampling that could help. There are ways to make this happen. But anyway, every information that is in the traces can be very useful; even to see the flow of a call or the flow of an application can be very useful for an engineer. Even if it's not what they were expecting to see, at least it will take them to where the issue was.

ANA: What do you say to that engineer that doesn't want to spend the time to instrument their code in order to have traces that's just like, nope, I'm not doing this work?

IRIS: What I would say, honestly, I have never had a conversation with an engineer that is against tracing. I feel that right now, engineers are very well educated about observability because it's becoming so big, but I'm sure there are some. The only thing that will be is your loss. [laughs] I'm joking, of course. But what I would say is that it is really your loss because you're going to miss out on a lot of information and in the troubleshooting moments because when the application is running perfectly, maybe you will not care about the traces. 

But when you need to troubleshoot something, that's when you will see the real value of tracing, so try it and see. [laughs] Or I would also offer to have a game day. Okay, let's make your application fail and see how much tracing is going to help you. Show with data and not just an opinion because it can be considered my opinion. [laughter]

ANA: I love game days. I love that you brought them up. [laughter] 

ADRIANA: I was going to say this is like your love language. [laughter]

ANA: Literally a love language, like, inject failure into your infrastructure, into your life. Think about what could happen and move forward with those learnings that you have. I think a lot of people don't realize where that concept of failure and observability go hand in hand. I'm actually writing a talk around this right now about you make the end goal reliability, but you don't ever care about the steps that you need to do in order to get there. So I'm trying to tell folks make observability; your goal and reliability will follow. Like, it all kind of goes hand in hand.

IRIS: I'm happy it's becoming so big, [chuckles] the observability topic because it's very important, and it wasn't understood as much before. It was seen as a side thing, oh yeah, maybe observability or not. 

ANA: Do you have any tips for folks that are embarking on their OpenTelemetry observability journey where they're coming from a place where they haven't necessarily done that? 

IRIS: Keep breaking things [laughter], and that's the only time that you're going to actually see success. [laughs] Because I know many people that when they try a new technology, they always try that locally, and it works amazingly. But from trying something locally and deciding whether it works for you or not, whether it's easy to implement or not, and going to a thriving dev environment or a staging environment is completely different. 

So my advice is try and put that infrastructure in a live environment, not production, of course, but in a dev environment, when you have real applications running, you have connectivity; you have all those things. So you can actually see how much it's going to take you to implement it and how much value you're getting for it; only then you can be fully confident with it.

ANA: Is there any way that you have found to quantify that value or to explain it to your leadership? Because I think that's sometimes something really hard in order to get, leadership to buy in so that you actually, one, have the time to do observability, to work on projects like OpenTelemetry. How do you start telling leadership like, hey, this is actually going to help us in the long run?

IRIS: This is surprisingly not an issue. For us, OpenTelemetry was always in the table and actually brought to us by leadership. 

ADRIANA: Wow.

IRIS: Of course, our intentions were there as well. So I feel like, as a company, we are very well educated to the new technologies and the benefits it can bring us. So I'm very happy about that, very, very happy actually. [laughs]

ANA: That's awesome. It's sometimes really hard to find that. When I talk to most folks, they are just like, whether it's observability or reliability, they're just kind of like, well, as engineers, we really want to bring in this technology. They're going to conferences, hearing the talks, learning about all these tools. But leadership is just like, no, we got no time. We got no money, like, [laughs] no.

IRIS: I don't know. Honestly, of course, the leadership goes in layers because it's a big company. But I don't want to brag, but other engineers that I work with are some of the most knowledgeable and know a lot about the tech scene right now. So it's very easy to get these new technologies approved and to work with new technologies brought to you to see and to try and to test it. It's very nice, actually.

ANA: That's exciting.

ADRIANA: That's so refreshing. It's nice to hear that there are companies out there that are thought forward. [laughs]

ANA: As you've been working on making observability better, has it made you and your team start thinking about other things you want to improve on alongside the platform or just the way that you engage with other teams?

IRIS: Yeah, we're always trying to find places to improve. First of all, we want to improve on performance as well because, of course, the more time passes, the more teams join and the more information we have to collect. So our main goal currently is to work and to improve performance, therefore, improving the cost as well. We cannot just let the platform run wild. [laughs] So yeah, we are trying to find a good solution there. 

And always, well, I would call them customers, but our engineering teams we try to work very closely with them. But yeah, we're always trying to find ways to better communicate with them. As I mentioned, sometimes it could be that the observability team is not seen for what it really is, that it's providing you the tools to actually do the work and implement observability yourself. So that's something where we have to work more on and try to communicate more clearly to the teams and show them. But it's not something that happens very often, but definitely, something to improve because the more teams are added, the more we will have to have this conversation, basically.

ANA: Definitely. 

ADRIANA: But as far as at least explaining the value of observability, it sounds like that's all sorted out. It's just now how to execute on it is more of, I guess, the challenge.

IRIS: Yeah, exactly. I think it's important for an observability or SRE team to be there for the teams to help them figure out how everything works and how to set it up. As I said before, of course, our job is not to go and create dashboards or set up metrics or traces for an engineering team or for an application, but it is to guide them. And at the same time, I work with observability every day. I work with those tools every day, so I know them by heart. Even in my dreams [laughter], if you ask me a question, I will answer about observability. 

But we have to understand that there are other engineering teams that work with completely different technologies, so they're not aware of how everything works. So we have to be available to help and to lend a hand as long as it is a collaboration and not us taking all the load of setting up observability for them.

ADRIANA: I think that is so perfectly put because I've been in situations also where I was on an observability team, and we kept getting asked to create dashboards for other teams. [laughter] And it's like, we can guide you, but this is just weird. [laughs] I don't know your stuff. 

IRIS: Exactly.

ADRIANA: So I'm glad, like, emphasizing the two key things. Y'all instrument your own code. Y'all create your own dashboards, but that you're there to support and guide them and to collaborate with them. I think those are key things and I think excellent takeaways for our listeners, especially those who are embarking on their observability journey, because I think that's where a lot of organizations can end up going wrong. So these are really good practices to follow.

IRIS: Absolutely.

ANA: As you've engaged with these customers, the engineering teams, do you have office hours set up, feedback forms, Slack channels, what is your actual way of serving them and letting them come to you?

IRIS: We have, of course, Slack, which is always open communication, but people know people. So, for example, there are many people that know who is in the observability team; in this case, some of them know it's me, so they come to me, to my co-workers, and so on. But, of course, we have official ways like service request, feature request that teams could ask for assistance. And we will help them no matter what it is, even if it's, for example, an incident or if it's a new feature that they would like or some new technology that they would like us to look at because it might be beneficial for them. We're open in many ways to accommodate these requests.

ANA: Have you or your team ever been called into an incident just as support? 

IRIS: Yes, it happens a lot, but mostly when something from our site is broken, for example, in this case, metrics. We could use metrics for autoscaling for other functions. So it is important that the metrics are always running well and configured properly, all that. So if, for example, that happens, we are called. But I don't think there was a case that we were called when another team's application went kaput [laughs], and we were there to provide assistance because we are the observability team. I don't think that happens. And that's why I was saying earlier as well. I feel like we have a very good culture currently in the company when it comes to observability.

ANA: That's really awesome. You got to continue cultivating it.

IRIS: [laughs] Yeah.

ADRIANA: Yeah, yeah, definitely. You guys are like the poster children [laughter] of how to do observability the right way. I love it. I love it so much. 

IRIS: I don't want to brag, but -- [laughter]

ADRIANA: No, you should. You should. [laughter]

ANA: Brag about it. Tell people that y'all are hiring.

IRIS: It's pretty great. I think we're lucky in that regard. We've done a very good job. But it's also, of course, the environment itself and the juniors we work with that make it possible.

ANA: You've gotten a chance to share about your observability, OpenTelemetry journey. What do you say is the biggest evolution you've seen since you first started working in this space to where you currently are now?

IRIS: I think the biggest evolution has been migrating the whole platform to a more scalable and reliable environment. I think one year back when I joined the team...it's actually not that long, but I'm very attached [laughs] to the team and the mission we have. The platform was not as available and scalable as it is right now. So for us to be able to be so quick on our feet and onboard new teams and new metrics, new traces, it was a lot more difficult. 

Currently, we have an amazing platform that is fully scalable and available 100%. And it's much easier for us to maintain but also to improve. So the improvements that we did one year back were much slower than they are now, thanks to the migration that we did. So I'm very proud of that. 

ADRIANA: Oh, that's amazing. Just switching back to, you know, we were talking earlier about OpenTelemetry and specifically how you really enjoyed the responsiveness of the OpenTelemetry community. Have you and/or your team had a chance to also make contributions to OpenTelemetry?

IRIS: Not yet. I'm very scared [laughs] for some reason to start there, but I really much want it. And probably it's going to happen to have a receiver, sorry, an exporter for Cassandra for the database because currently, as far as I know, it's not supported from what I have seen and from what I've tested. So I'm planning to make my own contribution, [chuckles] but I've been scared so far. 

ADRIANA: Oooh.

IRIS: I don't know; I find other people that contribute; they are such good engineers [laughter], and sometimes I don't feel up to the level. But I'll get there, I promise. [laughs]

ADRIANA: That's totally fair. We had a discussion with one of our previous guests about contributing to open source and how it's so scary because you're putting yourself out there. You're so vulnerable exposing yourself to the world, to the judgment of others.

IRIS: Exactly. [laughs]

ADRIANA: I can completely relate. I remember my first OpenTelemetry contribution. I'm like; these guys are so smart. Are they going to think I'm an idiot? And for me personally, what helped, and I mean, I know everyone's got their own path, but for me contributing to the OTel docs was a nice way to ease into it. Because I feel like [laughter] nobody is scrutinizing my code. It's just scrutinizing my writing, which I feel [laughter] is a little bit less scary.

IRIS: Yeah, that's not as scary. [laughter]

ADRIANA: So, anyway, that could be if you want to just dip your toes into OpenTelemetry, that could be a cool way to get into it. But I can say that for all the pull requests that I've made in OpenTelemetry, no one has ever been evil. The comments have never been mean. They've always been very polite. So that has put me at ease a fair bit. So I hope that you also have a similar experience when the time comes.

IRIS: Thank you for the recommendation. This is actually very good to ease myself into the documentation and then actually [chuckles] start writing code. Yeah, I do appreciate constructive criticism, but yeah, it's scary still. I pride myself on being a good engineer, and if someone says something mean about it... [laughs]

ANA: I think it's that people forget that you can contribute to these open-source projects without it being a full code repo or all these bug fixes or anything like that. There are ways that you can still create that PR and be like, oh look, I'm starting to contribute to such a project that I'm part of. 

And additionally, to piggyback off what Adriana was saying, it has been a welcoming community for OpenTelemetry, for other CNCF projects that I also contribute to. I think the umbrella of all those projects, the communities that are being built in this cloud native space, have gotten it right of, like, we're all just trying to build cool shit. [laughter] Like, let's just be nice to one another and remember that we're human, like, we got feelings. We got bad days. We are going to have to fail. We're going to have to learn. It's just that constant reminder.

ADRIANA: Cool. Well, I guess we are coming up on time. So as we wrap up, we would love to know your thoughts on what you would like to see in observability in the future. What's part of your wish list?

ANA: Well, part of my wish list about observability it will be, first of all, to keep continuing to grow so much and to be so modern and fast-moving because it's fascinating right now. And another one would be for more companies to actually start implementing and appreciating and seeing all the benefits of observability. I think some teams and some companies are there or at least are getting there. But I know that there are so many that still are very far from the goal of embracing observability, of how it should be, [laughs] not the observability that is different from the one we've been talking so far. [laughs]

ADRIANA: Yeah, yeah.

IRIS: But I really hope that all companies get there because it's going to be very, very good for them and, of course, very good for the observability community and observability engineers who invest so much time and their skills on these tools.

ADRIANA: Absolutely.

ANA: Most definitely. I think a lot of learning is going to come out with more movements like that. Well, with that, thank you so much, Iris, for joining us and talking a lot about infrastructure and observability.

Don't forget to subscribe and give us a shout-out on social media via On-Call Me Maybe. Be sure to check out the show notes on oncallmemaybe.com for additional resources and to connect with us and our guests on social media. For On-Call Me Maybe, we're your hosts, Ana Margarita Medina...

ADRIANA: And Adrianna Villela signing off with...

IRIS: Peace, love, code. 

ANA: Whoo!

ADRIANA: Yeah. [laughter]

ANA: Yay.