Episode 13 [SREpath Podcast]
Ash Patel interviews Adriana Villela who is a CNCF ambassador, OpenTelemetry contributor, and senior developer advocate at Lightstep.
Adriana talks about her experiences discovering observability, life as a team leader, and the promise of OpenTelemetry.
She sheds light on the importance of observability practices and the role of OpenTelemetry in standardizing instrumentation collection, enabling organizations to achieve comprehensive observability in complex systems.
Episode Transcript
Ash Patel: Adriana, great to have you. I’m looking forward to learning what you have to teach us about all things SRE, or at least a few interesting things you’ve been working on recently.
And I know you’ve been talking about OpenTelemetry quite a bit. So, looking forward to talking about that. But let’s do a quick introduction of who you are and what you do.
What do you do SRE-wise in terms of you and your company?
Adriana Villela: I guess I’m in the SRE adjacent space if you will. I guess it is part of SRE.
So I’m a Senior developer advocate at LightStep, which now is part of ServiceNow. So it’s actually called ServiceNow Cloud Observability. And Lights or ServiceNow Cloud Observability, I’m, I’m still getting used to the new name is an observability tool. And observability I would say is one of the important aspects of SRE.
What I do as part of my job is to educate folks on observability practices with a focus on OpenTelemetry, which is a great open-source CNCF project that aims to standardize how we collect instrumentation from our systems so that we can achieve those beautiful observability goals.
Ash Patel: OpenTelemetry has got to be one of the hottest projects out there on CNCF right now.
Adriana Villela: Mm hmm. I think it’s got the second-highest contributions behind Kubernetes, which is pretty wild when you think about it.
Ash Patel: I was gonna say. I know Kubernetes is number one for obvious reasons.
Actually, not obvious reasons, but you know what I mean. Yeah. Yeah, open telemetry is such an important area.
I say to a lot of people that observability is the foundation practice that any cloud operation needs to have to be effective.
Adriana Villela: Yes, yes, absolutely.
It is such a foundational practice. I think one of my pet peeves, and I had to edit myself when I was introducing myself and talk about SRE because I think a lot of the industry tends to treat observability as a separate thing when in fact it’s part of the overall practice.
When you consider the fact that we are in this microservices world, right? I think a lot of organizations have moved away from monoliths and have embraced the microservices model, which, you know, has its ups and downs.
But one of its downs is you have so many different services. And depending on the size of your organization, you can have like ton of microservices interacting with each other in ways that you would never even predict. Right? And so observability helps to untangle those interactions.
All of a sudden, You’re like, oh, I see how data flows from point A to point B of my application.
Ash Patel: You mentioned monoliths. What are your thoughts on a lot of companies talking about how they’re switching back to monoliths, but I don’t know why they would do that. Is it to save money or is it to cut down on their spending on doing things like observability? What are your thoughts on monoliths?
Adriana Villela: I’m kind of happy to hear that because I do feel like a lot of organizations went on this microservices craze because it was a fad.
And so I feel like some C suite executive attended some seminar or whatever where they were talking about microservices and then all of a sudden it’s like, Oh, we must do this at, our organization, it’s going to solve all of our problems and feel like a lot of companies rushed onto the microservice bandwagon without really thinking about does this actually do what I need it to do?
So I’m kind of happy that some companies are taking a step back to the monolith.
I think what people conflate with monoliths and microservices is that there are still efficiencies to be made when it comes to monoliths where I think if you structure your project properly, you don’t have to have some of those huge long build times that you would normally see with your monoliths in the past. And I think that’s one of the things that I think folks try to alleviate with the microservices model. Cause it’s like, you just change one little thing. You don’t have to build the entire frigging project.
But I think if you structure your monolithic app properly, it doesn’t have to be painful either.
Ash Patel: Exactly. You don’t actually have to do a monolith as a waterfall project either. Mm. Mm. Which I think people construe a few things together. They say, hey, microservices is agile, monoliths are waterfall.
And I’m saying, no. But anyway, we could talk about architectural decisions all night long.
How did you get to working with people in observability in the first place? How did you get into the space in terms of your work history, your personal history with it?
Adriana Villela: So I’ll say I got into the observability space.
I caught wind of Charity Major’s tweets when I was doing some research for something else. I had like a little side hustle with, with a friend of mine and I don’t know, we were just doing some late-night research and then I happened upon one of her tweets, which I don’t think even had anything to do with observability.
And then my friend, he started obsessing and reading all her tweets. And then he’s like, Hey, you should check out this observability thing. It’s really cool. And I’m like, okay, but I don’t get what it is. And he tried to explain it to me a bunch and I’m like, I sorta get it, but I don’t really get it.
And then like the company where I,
I was out of the time.
I was at the time they were exploring some observability products. They had some microservices and they were like looking into getting into Kubernetes. They, they were like hung up on this one product.
I’m like, you know, we should check out these other products around observability. Me saying this with like a vague notion of what observability was about. And then a couple of months later I found myself working at Tucows where I was managing two teams. It was a platform engineering team where, instead of using Kubernetes, they were using Nomad.
So I had to learn that. But I was also managing an observability team, which was kind of funny because I had a vague notion of observability from my, you know, like, my chats with, with my friend doing, during our side hustle. But also, I was trying to wrap my head around and when I got this job I started thinking I’m like, I’m like leading a team of people.
I better know what observability is because otherwise how am I supposed to like lead an entire organization on this journey, right? So I set out to do what I do best, which is learn the thing that I don’t know so I can do my job. And as part of that, I started blogging about it.
And I already had a blog at the time on Medium which was focused on, like, more the Kubernetes, Argo CD side of things. And so I started exploring observability. Blogging about it.
As I learned more, then I was able to start setting a direction for my team. So this team that I inherited It was an observability team.
I’ll say this in air quotes. And really what the team did was manage a set of, of open source tools in house. But at the same time, the organization was sending its observability data to a SaaS vendor. So I’m sitting here thinking, okay, we’re already paying somebody to receive our data. Why the hell is this team managing a set of tools in house?
At this point, I had a better idea of what observability was all about, and I said, let’s pivot this team completely. I want to focus on observability practices and not on observability tooling. Leave the tooling to the experts. So then I sought to educate my team on like, what are proper observability practices?
And that’s around the time that I got wind of open telemetry. Started looking at it a little bit closer. So the company before I was there was like that, I think that was the first time I’d heard of open telemetry, but it’s. It seemed like, I don’t know, it, it, it seemed like a very small thing. And then when I, when I went to my job where I was managing this observability team It was something that I started looking at more closely as I started reading blog posts about it and whatnot and educating myself and I’m like, huh, I feel like this is the future of observability.
So I started pushing really hard for the organization to adopt OpenTelemetry, which was very difficult because I found myself in a position, this was 2021, where OpenTelemetry, like, the tracing specification was not yet in general availability. And this was like summer, fall of 2021. And I’m sitting there thinking, no, no, this is going to be the next big thing.
I assure you it’s going to be the next big thing. But how can I convince these folks that OpenTelemetry is the next big thing when tracing isn’t even in general availability?
So I thought, I, I need to like, calm these folks concerns. So what I did, which is what I do best, I think, in my which I’ve been able to leverage in my capacity of as a developer advocate now, which is like make connections with people.
And so I had made some friends in the open telemetry space.
I’d talk to a couple of folks from two different vendors that we were also considering at the same time, because we were, you know, we had the SaaS vendor, but I’m like, well, is, is this the right fit for us? We should explore other vendors.
I reached out to these folks who were, who worked for other vendors, but they put on their OpenTelemetry hats for this, right? They said, please come speak with us on a unified front under the OpenTelemetry umbrella to answer questions and concerns for folks in the organization who are hesitant about adopting OpenTelemetry.
And to my surprise, they went along with my idea, I, I honestly thought, this is a total long shot, this is not happening. But they went with it and I remember telling my team, we need some seed questions in case this thing is going to be crickets, otherwise I’m going to look like total ass.
So we came up with some seed questions, but guess what?
For the whole hour, the folks from the dev teams, they had one question after another, and we didn’t even have to ask any of our seed questions, which I was very relieved to hear. To me, it showed that there was an interest in what was being done.
There was a genuine interest in OpenTelemetry, and I think at the end of the day, mission accomplished. We managed to quell those fears as a result. And so the company was a lot more comfortable in terms of adopting OpenTelemetry. So that was my original foray into it. And then I ended up getting hired by one of the observability vendors as a developer advocate because of my blog posts around observability and OpenTelemetry, my explorations.
Which for me, honestly, is, is something that I’ve dreamed of.
I love educating folks through my blogging and I love digging into technical topics. So I feel like it was the best use of my, of my skills. And it’s been great because also like this job has been my first opportunity to contribute to open source, which I’d never done before.
And it’s scary if you’ve never contributed to open source cause you’re being vulnerable. You’re putting yourself out there. It is terrifying. Like what if someone says your thing is crap, but I’ve been lucky cause in the OpenTelemetry community, no one goes and says your PR is crap.
They always have very thoughtful suggestions always useful suggestions. So, even though I’m scared every single time, my fears are always put at ease because the folks are just genuinely nice about it.
That’s been my journey into OpenTelemetry and observability.
Ash Patel: That’s the great thing about open source communities. It’s psychologically safe in that everyone’s trying to learn and trying to improve what they’re working on and they’ll share ideas, but in a constructive way.
Adriana Villela: Yes, absolutely.
Ash Patel: And I said that because I’m calling out to people to try and do the same as Adriana and contribute to open source if you can, and if you have the time to do it.
Adriana Villela: I do want to mention one thing actually on that same vein, like when, when I was at Tucows, I myself wasn’t practicing what I was preaching, but I did encourage my team as a whole, like my observability team, like when they were running into issues with, Oh, I’m waiting on this feature for OpenTelemetry and blah, blah, blah.
I’m like, dude, just try to work on it if you can, if you feel like you, you can like put in a fix, do it. It took me a little bit longer and, you know, switching roles to like muster the courage to do it myself. But I, I totally agree with you.
I think it’s so important for us to contribute to open source.
And for our organizations to encourage contributing to open source, especially if we are consumers of that open source software.
Ash Patel: I have a question about your thoughts on how organizations that are non tech native feel about open source. We’ll get to that in a second, but I want to actually go back one step and talk about how OpenTelemetry fits into the whole observability area of software.
Adriana Villela: I think the important distinction to make is that open telemetry is not equal to observability. Open telemetry is one of those tools that enables observability. And honestly, like, you know, before open telemetry, there were things like open tracing and open census. OpenTelemetry is at the forefront now because it is the one that all of the big vendors have rallied behind and, and for a little bit of history, open source projects like OpenCensus and OpenTracing, they actually merged to form OpenTelemetry.
But I wouldn’t be surprised if, like, somebody for funsies decided to, like, create their own tracing library or whatever. But at the end of the day, like, observability is about, you have that information. What do you do with the information about your system so that you can follow the breadcrumbs to answer the question, why is this happening?
OpenTelemetry enables that to happen, right? It’s the thing that supplies that information.
I would encourage folks to use OpenTelemetry as the standard for that sort of thing because if we get to the point where, like, we’re all using different tools, we end up losing out on the standardization and the work that has gone into OpenTelemetry, if that makes any sense.
But a tool like this is only as good as the user base. And if we don’t have that standardization, if we don’t rally as a community to standardize around how we get our observability how we emit the observability data then we end up with all these different factions.
I don’t want to be super prescriptive about it, but I think it ends up losing its worth if, if we go all like everyone on their own, do whatever they want for these sorts of things. Right?
Ash Patel: Yeah, I would be totally against it myself.
If I were managing a team or multiple teams, which like I have in the past, I always used to tell my teams, don’t reinvent the wheel. Look at what’s available out there. And try and use that first. And then if we have to make a solution from scratch, then we’ll look at it then. But start learning from what everyone else has done, and then we can work with that.
And this is how OpenTelemetry is doing. It’s giving you all this capability from the get go.
Adriana Villela: Yeah, totally. And the other thing that I want to emphasize is that because, you know, all the major observability vendors are behind it. It means that these vendors are not competing on the data that is ingested. They’re just competing on how they’re rendering the data.
We all speak the same language. The data that we send to whatever vendor, vendor X and vendor Y, it’s the same data. Vendor X will probably render it differently from vendor Y, and so as a consumer. It’s up to you to decide which one is more useful for me for my troubleshooting purposes.
Ash Patel: You actually have a bit of experience with running teams. So, I’d be interested to know in terms of your observability team, how you managed them, how you hired them, how you managed the performance. .
Adriana Villela: When I joined Tucows, I was lucky enough that there were some folks on both of my teams already, and it was, like I said, it was managing two teams, and they were similar but different.
And so there were already folks on those teams, but I needed to also hire a headcount. At that point, I already knew what I wanted out of my teams. And in particular, I’ll talk about the observability team.
I wanted to hire somebody who either appreciated what observability had to offer either as an expert in observability or somebody who maybe they didn’t come from that observability background, maybe they came from a more traditional monitoring background, but saw the importance of observability and were willing to do a paradigm shift.
It was a weird role because it was a technical role that wasn’t terribly hands on. So my team our mandate was to be able to educate folks at the organization on observability practices.
We taught them the overarching best practices, but also we assisted them as far as unpacking some of the gnarly bits of OpenTelemetry so that they could instrument their code.
Now that was very different from actually instrumenting the code themselves, because the slippery slope that you can get into by having an observability team, and it wasn’t just my team you can end up getting asked to instrument your developer’s code. Which is a very bizarre ask, because I know nothing about your code.
I don’t know what’s important to you for debugging purposes. I don’t know what the code does in general. I might have a vague idea from a high level. But realistically speaking, it is not my code. I don’t have that kind of vested interest. I will help you in terms of, like, Hey, these might be the things that you might want to instrument.
And I can provide some assistance on how to instrument in whatever language. But as far as instrumenting your own code, that was something that was on purpose outside of the realm of my team, because we wanted to encourage developers to instrument their own code.
So hiring for the team was… was tricky in that sense, because I had a lot of candidates applying for the position who came from like an infrastructure as code background and were super gung ho on managing tools and I’m like that’s not exactly what we do.
I wanted somebody who had an appreciation from an infrastructure as code background, somebody who had an appreciation from like an SRE type of background, you know, someone who felt the pain so that they could then go on and advocate for those observability practices.
In a way, I guess I was hiring for an internal team of advocates in the organization. So it makes it a very tricky type of role to hire for because it’s a more squishy role that’s not completely hands on, but I need you to be an engineer. I need you to understand the pain around this sort of thing.
That was on the hiring side, but then for the folks who I had inherited was a little bit tricky too, because all of a sudden I come in, I’m saying we’re pivoting the team’s mandate. That went well for some folks and for other folks they’re like, but I want to just do infrastructure as code.
That is my thing. I enjoy it. So I had to have some hard conversations with some of my team members saying, look, I understand that this is your preference and that I have gone ahead and shifted what our team’s priorities are.
And I am okay. If we don’t align, if you want to go look elsewhere in the organization, I will support you in that search, to ensure that you find something that’s more in line with your career goals in the organization.
It’s kind of a tough conversation to have because it means that person admitting, yeah, I don’t really want to do this and me saying I’m okay letting you go because I think at the end of the day, when you’re managing a team you kind of have to all toe the party line together.
You have to be aligned as to what the overarching team goals are. It’s okay to question certain things. I think it’s always important to question direction. Hey, maybe you should be doing X instead of Y. That’s totally fine, but to have folks who are constantly questioning what you’re doing as if you’re butting heads because you don’t see eye to eye on the philosophies and where the team is going, I think it ends up being very unhealthy for the team, and so you’re better off parting ways because you’re better off parting ways.
All it takes is one person to start sowing dissent on the team to ruin the team cohesion. And then that becomes a very toxic work environment for everybody, right? Because then you start creating factions and people aren’t working together, they’re working against each other, and that’s not something that you can have.
So, I mean, at the end of the day, being aligned on what our mandate was was very important, whether it was somebody already existing on the team or somebody being hired into the team.
Ash Patel: That was very insightful about a lot of things that you can apply beyond what your team issue was in terms of there’s so many teams that are facing this exact thing. There are people already there, there are people that you need, and you need to all align on whatever mandate you as a manager have to create to align with goals.
Coming back to now, what you’re doing right now, you’d be having some interesting conversations with a lot of people every day about what their challenges are. So what kind of person typically reaches out to you or you end up having conversations with around observability and OpenTelemetry?
Adriana Villela: So we talked to, I’d say, a lot of people who are new to OpenTelemetry, who are just trying to figure this thing out. I had a conversation recently with somebody who was just starting to wrap their head around it. They knew that observability is important. They knew that OpenTelemetry is important, but they weren’t sure how to get started.
So one of the things that I like to do is, I’ll give them a little overview and I’m happy to, anyone who wants to talk about observability, OpenTelemetry, like reach out to me. Let’s have that conversation. You know, I work for a vendor, but I’m not here to sell you a vendor product.
I’m here to sell you on observability first and foremost. I’m here to sell you on observability, OpenTelemetry, the power of that.
And I think that’s the most important thing we, we need to do right by, by our systems and make sure that we have the tools necessary to be able to troubleshoot in production.
So having those conversations with folks to understand what their needs are, what their difficulties are. I can come because I have the experience of having been on the other side of looking at a couple of different vendors and really just focusing on observability practices.
I can have that conversation with folks around what do you need to do in order to be successful in terms of bringing observability and open telemetry to your organization? Just, just like wrapping your mind around observability. I think with a lot of things in tech it’s very easy to get into various anti patterns.
We saw that with the DevOps movement. I think one of my biggest pet peeves is still the idea of, like, DevOps as a job rather than as a practice because I think we, we ended up moving away from what DevOps was trying to promise.
And I feel like, you know, it, it can be a similar slippery slope with observability where I have used OpenTelemetry, therefore my system is observable, and I’ve encountered situations where you can instrument till you’re blue in the face, but if you’re instrumenting the wrong thing that’s useless.
Recently I’m one of the co leads of the Open Telemetry End User Working Group, and we had one person come in and present to us, Hazel Weekly, and she was talking about a story where one of the organizations where she was in.
They instrumented their code. They over instrumented their code to the point where like, great, we’ve got open telemetry. It is useless. We have no idea what is going on here. It’s not giving us any meaningful information. So she actually had to spend some time unraveling that big mess and trying to get it to a state where the instrumentation was more meaningful.
We need to be aware of the initial lack of knowledge around both observability and open telemetry – both from a I don’t know where to get started, to, Oh, I’ve come in guns blazing and I’ve over instrumented and it’s still not helping me.
We really need to take a step back and really, really focus on the practices.
Ash Patel: Okay Adriana. Where do you see the category of observability heading in the next two, three, five years?
Adriana Villela: This is my, my hope and I, I, I hope that it, it follows my hope. So, in terms of observability, I hope to see more integrated with the SRE practice and not so much of this separate adjacent practice. We need to start talking about it from a more unified standpoint. The other thing that I wanted to mention is that I really want us to look at observability as a team sport.
And not as just the thing that is the burden of the SRE. Because when you think about it, yes, the SRE is probably going to be your first line of defense when there’s an issue happening in production. But, let’s think back to who instrumented that code in the first place, the developer.
So the developer, you would expect, would want to have a vested interest in making sure that the instrument, the code properly so that our poor friend, the SRE has an easier time of troubleshooting issues in production. But I think we can take a step further and say, the developers should take advantage of these observability platforms to even help troubleshoot their own code while they’re debugging, while they’re unit testing.
But let’s take it a step further than that, which is before it goes into production, we send it over for testing, right, to our friends, the QAs and this idea of: “why don’t we empower QAs to be able to use observability data to make sense of what is happening in the application when they’re testing the code so that when there is an error, then the QA can go to the developer and say, “Hey, there’s bug and I can tell you where it is”.
Or if there’s a bug and the QA can’t tell the developer where it is, that’s fine too because they can say to the developer, ” Hey, your system’s not emitting enough information. I don’t know what the problem is. I think you’re missing some instrumentation. Go back. And then the other piece of that puzzle is leveraging those traces that you already have in place and creating trace based tests.
Which is basically, as the name implies, you use traces to create automated integration tests, and there are some tools out there that already do that. The most talked about one in the space is TraceTest. It’s an open source tool that facilitates trace based testing.
There’s another one called Maliby: it’s more of a JavaScript based trace based testing tool, and I don’t think it’s been maintained for the last little while. And then Helios I believe they were looking at trace based testing definitely last year. I don’t know where things are at now, but these are three different types of tools that you might want to look at if you want to explore trace based testing.
I think it’s a really, really cool concept and that’s something like I want to see more. I want to see us talking more about trace based testing in the future because I think trace based testing can give us extra superpowers in terms of achieving more reliable systems especially because now you’re not having to worry about wrangling different testing frameworks to be able to do end to end tests of your systems, especially if you know, you’re dealing with a system where the microservice is written in different languages.
Now trace based testing is like your single unified language for writing your your integration tests, which is awesome because the unified language itself is the trace.
So again, we need to make sure that we have good quality traces so that we can leverage those traces to really make them work for us.
Ash Patel: It’s interesting you’re talking about tracing because I was crossing University Avenue in Toronto and I overheard two developers talking about tracing and testing. It was a little haphazard.
They were talking about trace testing, but they were very confused about what they had just heard in a meeting prior. So there’s a lot of, it was surprising to me because then I stopped them. I said, Hey, what do you guys know about observability? And they said. Not much. And I asked them, do you need to learn more?
They said, yes, please. Well, they didn’t say it like two boys in a Charles Dickens novel, but you get the idea that they were pretty keen on figuring out what is this thing that’s now suddenly become part of our responsibility in this increasing you build it, you run it model.
It’s interesting that these kinds of things are being brought out. Trace testing was just mentioned. I’m gonna say one thing, and I’m not sure whether you’re gonna agree with me. It’s that all this needs to be brought together cohesively, so that when it’s shared with people, they can see this is where this fits into the observability practice.
Where do you see SRE heading in the same way in the future? Where do you see it heading in the next few years?
Adriana Villela: I think for SRE, I’d like to see more conversations happening around things like self service provisioning.
Actually Anna and I have a talk coming up at KubeCon where that is our subject matter. The idea that there’s the rise of platform engineering, which this may or may not be a popular opinion, but in, in the definition that we’re using, we see platform engineering as an extension of SRE.
Where you’re not only concerned about the external customer, but the internal customer, i. e. the developer. And this idea that in platform engineering, as a developer, it’s so annoying when you’re trying to get your job done, and you need certain tools to get your job done, and you gotta wait on this platform team to provision stuff for you.
And so you’re sitting there waiting, waiting, waiting, thinking, Frigman, why can’t I just use, like my own Kubernetes cluster? I don’t want to use this stupid Kubernetes cluster that’s, you know, in the cloud and blah, blah, blah. And, like, this is taking forever. I need to get my job done. And by having self service tooling available, it means that developers can then provision the resources that they need to get their jobs done on demand.
These resources are provided by the platform team. However, the platform team automates the provisioning of those resources, right? They’re not having to like, you know, execute on these requests manually but on top of that, this whole idea of being packaged, so that it’s compliant within the organization.
So security concerns are addressed. It’s using standard configurations. So you’re not deviating from what the standards within the organization are. So the thing that’s delivered to you that you’re able to use as part of your tooling is wrapped in a nice little neat bow.
It’s got all the configurations you need and you don’t have to wait days and days and days to get the thing that you need to be able to do your job. So having the self service provisioning.
And then the other thing that is important that I think follows in with that is whenever we go from one organization to another, I can’t tell you how many times you figure out this automation, then you go to the next organization.
Oh crap. I got to do this exact same automation. Like, come on. We keep reinventing the same automations over and over and over again. Wouldn’t it be nice if we just had this marketplace of standardized automations where we can just pick and choose, right?
And then make some customizations here and there, but we’re not having to like reinvent these friggin automations every single time for our SRE practice.
The last one is policy as a service where I feel like we’re always at odds with InfoSec. InfoSec has a very tough job because they’re protecting us from all these attacks in our systems making sure that everything’s safe.
And I feel like there’s… And they can’t even talk about their triumphs, right, because if you talk about, like, oh, I, I blocked this attack from happening, I blocked that attack from happening, that already, like, that’s not secure by nature. So, you, you can’t even, like, you can’t even gloat about your accomplishments but to be able to work together with Infosec so that we have certain policies in place that are codified, and again, so we don’t have to go through these long drawn out processes of, Oh, I need access to XYZ and have like all these approvals.
Well, yes, we’ve already had the pre approvals because we already have all of these policies, like pre packaged, pre approved. Everything’s compliant. And so we’re not mad at our InfoSec friends. They’re just trying to do their jobs and we’re getting these compliant things. These things that are properly secured. Our Kubernetes clusters that are properly secured and are cloud resources that have the right permissions without having to like wait forever and ever and do this song and dance with InfoSec.
Those are the areas that I, I would like to see like SRE going towards.
Ash Patel: We can only wait and see.
Adriana Villela: I know, right? Fingers crossed.
Ash Patel: What advice would you give to SREs who are dealing with a lot of challenges right now to help them in their working lives?
Adriana Villela: I would say never stop being curious. Whether or not you’re an SRE, I think that will take you very far in your career. Because by being curious, by always looking to do things a better way. It helps us grow in our practice. I think it allows us to innovate. I think we risk stagnation when we stop caring about innovating in our technologies, in our jobs.
So let’s continue to be curious.
Ash Patel: There we have it. Never stop being curious. Thank you so much for joining me, Adriana.
Adriana Villela: Thanks for having me, Ash.