Anais Urlichs - Is It Worth Going The Extra Mile?

SPEAKERS
Liran Haimovitch, Anais Urlichs

Liran Haimovitch  00:02
Welcome to The Production - First Mindset. A podcast where we discuss the world of building code from the lab all the way to production. We explore the tactics, methodologies, and metrics used to drive real customer value by the engineering leaders actually doing it. I'm your host, Liran Haimovitch, CTO and Co-founder of Rookout. Today I have with me a very special guest, CNCF newest ambassador of the year, Anais Urlichs, and she's right here with me. She won the prize just a few days ago and she's still excited about it. So welcome Anais.

Anais Urlichs  00:43
Hello, thank you so much for having me.

Liran Haimovitch  00:45
Anais, what can you tell us about yourself?

Anais Urlichs  00:47
So, I actually joined the cloud-native ecosystem, just about a year ago, when I joined Codefresh. And I was with code fresh for several months, and then got excited about the technical aspects, the really technical aspects of the cloud-native ecosystem, and joined Civo, a site reliability engineer. So, I've been slowly progressing into the more technical areas of the cloud-native ecosystem, still in cloud-native. Civo is completely-- Kubernetes is cloud-native first cloud computing provider. So, I'm staying in that area. I joined the space after working for several years in the blockchain space and I had to learn everything completely from scratch. I was working before as developer advocate, but I've never heard about DACA, about Kubernetes. I've never used a cloud computing platform until I joined Codefresh. And then, I just-- Hey, I'm learning everything from scratch, I'm just going to make it all public, I'm going to share it with the community. It was, first of all, I started as like a selfish reason, just for myself, I wanted to learn how to talk about technology and just manifest my learnings by talking about it. So, I started a YouTube channel and then a newsletter, and then I became a CNCF ambassador. And now fast forward one year later, I am the CNCF ambassador of the year. So everything, as you can imagine, happened quite quickly. And I was still processing it a little bit. So yeah, that's about me.

Liran Haimovitch  02:24
That's pretty crazy. Can you share us a little bit more about that award? How you got it? How did you find out?

Anais Urlichs  02:31
Yeah, so to be honest, I wasn't participating in the ecosystem with the idea of, oh, I want to win an award, or oh, I want to get a certification. I don't have any certification seats in this space, I'm obviously promoting for people who want to get certified and promoting ways and pathways, learning paths, strategies to get those certifications, also as part of the CNCF ecosystem. But I haven't contributed with the idea of I want to get rewarded for my contributions, right?. So, I think the main contributing factors to that award were, first of all my personal social media channels and the efforts that I put into those. So for instance, with my newsletter, I really focus on other people in the ecosystem that do really great work, that create amazing content. And I tried to share other people's content, because there's so many amazing individual contributors who don't really have a spotlight on them a lot of times, so I thought, hey, I'm just going to create a newsletter to give them that spotlight. That was part of it. Another part was that, I think my YouTube content specifically provides a really unique perspective of what is it like getting started, and just telling it, how it is, exactly how I experienced some of the tools, some of the projects, some of the technology is probably quite relatable for a lot of people getting started as well in the space. They see me learning it, they see me struggling with it, being frustrated after not getting any proper deployment done after several days. And that makes it-- It normalizes it for them. Let's say that some tools, some technologies are just really difficult, and it takes time. But if you keep using them, being consistent, then you will figure it out and in the end it will work. So, that's I guess more to my personal efforts, but within the CNCF ecosystem, I really try to contribute to smaller communities. So, within the CNCF community as a large space, you have several sub-communities and I really tried to get involved with local meetup groups, contribute to their efforts, contribute to other people's individual efforts in whether that's educational material or example projects or anything related to education in the space. And I think that just built up over time. So, it wasn't this one thing of like, I'm going to start this project and hopefully people are going to recognize me, right? It just me talking to people and keeping an open mind. And then, the award happened out of the blue. I didn't expect it. There were other amazing people who were nominated from the ambassador group, from the CNCF Ambassador group, I nominated several other amazing people, there's so many people who really would have deserved the same award, right? So, I just see it as a collaborative effort in the space. So, the award goes as much to a lot of other amazing people as it goes to me.

Liran Haimovitch  05:31
CNCF today is a huge community. A very growing one, very active one, probably one of the most active ones, both online and offline, by the way.

Anais Urlichs  05:40
Yeah, there's a lot going on behind the scenes that you don't necessarily see online, right? Also, within certain groups, like I remember when I was meeting different people in this space in Berlin, in person. There was a lot of things that they do that you wouldn't necessarily know about, because it's just not online, right.

Liran Haimovitch  05:58
Thinking of the CNCF, I think the first thing that comes to mind for everybody is Kubernetes. So kind of, from your perspective, from what you've seen so far, what is Kubernetes to you?

Anais Urlichs  06:09
What is Kubernetes is to me? The interesting part here is, when I'm talking about how I use Kubernetes, when I'm talking about how I use cloud-native tools, people have to remember I don't know anything else. I'm proud of the generation that kind of appeared in the space, thought it was amazing, started learning about the technology, but I don't know what came before Kubernetes. So, I have little to compare it to, which is an interesting perspective. So when people ask me, what would you use instead? Or how would you use these tools instead? Or what will your deployment strategy look like otherwise? I'm not 100% sure what to answer. Of course, there are ways that I deployed static websites and other base applications before, without Kubernetes. But they are not really comparable to large scale production systems. So, everything that I'm learning, that I know about is how you make things work with Kubernetes, and why you want to make things work with Kubernetes. So for me, it's, I guess, representing a shift in infrastructure management, as well as in deployment strategies. And also, there's a huge cultural shift that Kubernetes in the cloud-native space push us towards, that is really interesting for me. And I think that's part of when we talk about Kubernetes, we also talk about everything that goes on around it, and how our practices, our processes change as well.

Liran Haimovitch  07:27
So, you love Kubernetes. I think today, many people have Kubernetes. But the thing is, it's not always easy to get started with and it's not always easy to get things done with it. What kind of challenges have you experienced? Or have you seen other people experience when it comes to Kubernetes?

Anais Urlichs  07:43
That's a really interesting question. Yeah, I think the main challenge is the documentation and understanding the documentation. So, there is lots of documentation that's provided by maintainers of different projects by the community, by Kubernetes first cloud-native projects platforms that you might pay for. The problem is understanding that documentation is not always straightforward from what I've experienced, and based on what other people have told me, because you obviously approach documentation with certain biases from a certain mindset, right. So, you will think about concepts in a certain way, depending on what you've already learned about. And when you start learning Kubernetes, you might experience kind of a shift in the way you think about your infrastructure and your deployments. And that shift that you have to go through when you start learning about a tool, that's not always represented in the documentation. So, the documentation would, for example, describe how would you deploy x? Or how would you use these custom resources? Or why would you use this project? But then, it misses to make the connection between other tools and other processes, or why you would actually want to use those tools in the first place. Like, why is it actually necessary? Like, there are lots of amazing innovative projects in the cloud-native ecosystem? And sometimes I feel like people have problems understanding of why are they needed in the first place? Yes. They seem like they have a lot of amazing, interesting technologies, that's probably really exciting to learn about on a rainy Sunday afternoon. But do you actually need to implement it into your production environment? Do you need to use it on a day-to-day basis? Is it worth going that extra mile? And I think some of the tools missed out on that part on the 'why' itself. And then also, what I've experienced, especially like getting started SRE work and Site Reliability Engineering, and having to implement tools on a production multi environment level, is that several documentations, they don't cover that part. They don't cover those advanced use cases. So, the documentation is amazing to get started if you do it on small scale. One class the environments, if you just want to play around with those tools, but then those actual use cases that organizations need to learn about, where they need to have those technical examples, that's quite scarce to find. And a lot of times, you have to look through Stack Overflow and GitHub issues and similar and look at the conversations that happen in public, right? And that's why it's so important to keep talking about it, right? Keep talking about the struggles, keep talking about the solutions, the use cases, and so on, right. And I guess over time, it will get easier for people and it will get more advanced, and people won't find that as much of an issue anymore, as I find right now. I guess.

Liran Haimovitch  10:41
Definitely, you get the basics out of the documentation, but to understand how to put everything together, the community and the research is so important. I personally spent a few rainy Sunday afternoons writing a series of blog posts around developer tooling for Kubernetes. And kind of, what each of them is doing, and how are they coming together? And kind of what should you use for what? And what's new for each of them? And so on and so forth.

Anais Urlichs  11:06
Yeah, I think it's really needed to have this level of curiosity on those tools, right? If you don't have this level of curiosity, you will find your way around using Kubernetes, but you will have a lesser experience in the process. I think.

Liran Haimovitch  11:20
Complexity is one of the biggest pillars of modern infrastructure of cloud-native infrastructure. And I think one of the ways we're seeing people like to handle that is by offloading as many of that management work to the cloud provider, essentially moving for managed services. And I think Kubernetes isn't any different. I mean, every cloud provider out there, has their own managed Kubernetes product.

Anais Urlichs  11:43
Yeah. So, I actually have a strong opinion on those. It's not necessarily diminished Kubernetes clusters of various cloud providers. I mean, it's even, we really tried to focus on providing the simplest onboarding experience, but you have a cluster with three clicks. And that's it, where it's completely self explanatory, which is obviously great to spin up a cluster. But then, you still have to figure out how do you deploy your workloads, right? And that's what you will have to do on every cloud provider when you're using their managed Kubernetes service. Right? You will still have to figure out for them, how do you deploy those workloads? And I mean, there are, especially throughout the past year, I feel like a lot of different developer platforms popped up across the space that target developers specifically with the promise of you do not have to know any Kubernetes, you can just tell us your containers and we deploy it for you, we manage everything that has in any way Kubernetes related for you. The problem here is that - and that's I have such a strong opinion on them - that sometimes developers still have to learn about the concepts, because not everything is necessarily masked, right? They might forget to mask some parts, because obviously, those platforms are created by people who know Kubernetes. And as soon as you know about something, you will kind of integrate it and you won't realize it, right? And then, the developer, the engineer who just wants to get the application up and running, knows Docker, wants to deploy, just gives you the Docker containers. They will get really confused when they all of a sudden have to know any specifics related to kubernetes, whether that's the type of service they have to choose, or anything related that makes it possible to use those platforms, right? So, that's one part, that either they don't extract the right parts of the entire Kubernetes management lifecycle, let's say. And the other problem is that, in some cases, they extract so much that you can't even use Kubernetes, as it's intended to use, I would say, like, Kubernetes I think the fascinating part of the ecosystem and that's maybe what makes it so difficult - this space - to navigate and to get started with, is that it's really extensible. Like, you can start with a basic Kubernetes cluster and just deploy the most basic workloads, right? Just about application, just have that running, two pods, that's it right? Done, kind of, right? And you can-- you can that get up and running relatively quickly with some online documentation. But then, what if you want to use serverless workloads on Kubernetes? What if you want to use more custom resources? What if you want to use Githubs? And you have to then learn, okay, how do you deploy those, right? And in many cases on those managed developer-focused Kubernetes platforms, you can't even use any of those nice tools that make Kubernetes so amazing. Like, I think the ecosystem still has a long way to go to make it easier to use everything. But at the same time, if we take the other way, the other approach from the other side and we say, engineers don't have to learn anything about it. We just abstract everything. Then we take away this exciting part of notice, actually so much happening behind because Kubernetes, the API is the magic part where you can do so many different things. But if I extract it away completely, and I don't allow you to do anything with it, then why do you use Kubernetes in the first place? That's kind of my response to it. Which is maybe a bit controversial. But, yeah.

Liran Haimovitch  15:16
I'm guessing you're seeing Civo as a bit different than the rest of them.

Anais Urlichs  15:20
So I mean, I'm talking specifically about developer Kubernetes, like, Developer Focus Kubernetes platforms. That's what I'm talking about, specifically. And that's independent of various cloud providers. In some cases, when you use one of those Kubernetes developer platforms, you still have to choose one of the cloud providers, right. But the thing is, if you look at the amount of resources, you have to spin up just to get a cluster up and running on AWS, and then it takes like 20 minutes for a cluster to be up and running. Is that really what you want to do? Like, what do you want to spend your time on? What do you want to learn about, you don't want to learn about the nitty gritty details that are involved in your cluster, in your cluster management, you just want to have a cluster, you want to connect to the nodes, you want to tell it what to deploy, and then be done with it right? You don't want to have to learn about everything around it and perceive of being just focused on Kubernetes really undisclosed native space. But basically our ideas, we make it really easy to get up and running a cluster this different cloud-native tools and platforms. So we have, for example, a marketplace that allows you to select just by name, this application should be on my classes, this application should be on my cluster. So, you don't have to handle those different custom resource definitions. You don't have to look through different GitHub repositories to find the resources that you then want to deploy. So, we take that little step away from you. But you still have to understand how do you define your resources and tell Kubernetes how to deploy those, and you still will have to understand how to use those applications, right. But just the original spin up process, right, that should be the easiest part because that should be the part that could be made the easiest. So that's I guess, where I see Civo being different. But my rant earlier was specifically targeted at developer focused Kubernetes platforms, at least those that I've seen before that I don't think have the right goals in mind. Let's put it that way.

Liran Haimovitch  17:18
We're seeing developer experience with Kubernetes is still very challenging. On the one hand, Kubernetes is super flexible, you can do tons of stuff with it. On the other hand, sometimes people just want to run code, and you kind of have to balance the two. And definitely, you don't necessarily want every developer on your team to have a deep knowledge of Kubernetes. Even though you might have some complex configurations behind the scenes, you wanted them to be, you know, invisible for most of the team.

Anais Urlichs  17:48
Developers should know as least as possible, just to get the job done. Definitely. I don't really see Kubernetes right now focused at developers specifically, I really see it to be focused more, I mean, depends on the size of your team. Obviously, a really-- also a statement that probably lots of people right now will disagree with, I guess, if you are in a large scale team, you will want to have people who are dedicated to making the deployment process happen in some way. Like obviously, not to take the entire engineering component out of it. But I think to properly use Kubernetes without exposing yourself to any risks, to unnecessary risks. You want to have people who are not split between different tasks, or too many tasks that are quite relevant. So, if you have engineers who are working on a platform on your application, I don't think that is the best approach to have them also be experts in Kubernetes.

Liran Haimovitch  18:50
Yeah, it's about division of responsibilities. You need somebody-- No matter how little maintenance is involved in this cluster, there is a maintenance involved, whether it's, you know, application version, whether it's the cluster version itself, whether it's the Kubernetes Working Group occasionally, you know, deprecating various API's, and then you have to go and chase them. Those are the kind of stuff that happens and you have to make sure that you're on top of that.

Anais Urlichs  19:15
Yeah. How do you stay on top of things?

Liran Haimovitch  19:19
You mentioned you have your own YouTube channel now.

Anais Urlichs  19:22
Yeah. So, I started a channel nearly a year ago focused on a challenge called 100 days of Kubernetes. Now I'm at day 40 something, 45. Obviously, after a year, day 45, you can tell that it takes a lot of time and effort to get those videos, to get the content created, and then to record yourself and to edit those videos. And then, to publish them ultimately, but yeah, so I hope we link the channel and you can check it out. It's basically-- At the beginning, mainly different Kubernetes concepts. The architecture, how does it actually work behind the scenes, because you don't want to use tools that behave and feel like a black box, right? And then from there, I move on in working with different tools with different platforms and exploring those in that series. And it's just basically one example of, if you want to continuous learn about a tool or a platform, you can do it across a timeline and just spend a lot of time learning about it, in that case, Kubernetes and at some point, you will get really good at it. Just continuously putting the effort in, right?. And I recognize that other people's Kubernetes journey will look a lot different. Also, depending on your previous experience and your knowledge. It's just basically to show, this is what I'm learning about and this is what I share on my channel. So, yeah.

Liran Haimovitch  20:45
If you've checked out a ton of new Kubernetes tools over the past year or so, kind of how do you go about experimenting and evaluating a new tool?

Anais Urlichs  20:55
Yeah. So, it really depends on the circumstances of why I'm looking at the tool in the first place. Sometimes it's out of curiosity that I just come across scrolling through Twitter, or it just pops up in my GitHub notifications. And I'm like, oh, let's check it out. It sounds interesting. Sometimes I have specific problems at work, and I'm looking for tools that might help me get my job done quicker. Lazy me. Sometimes, it's also kind of dictated by my work, of we need this tool or a similar tool. Can you evaluate different tools? Can you look at those tools? So, it really depends. At the beginning, most of the tools that I looked at were mainly for work, for demos, for presentations. So, in addition to those work related demos, I then also did a video on my YouTube channel. Now it's highly focused on, also on what is the community interested in. If there are lots of people who are interested in me looking at a specific tool and getting my thoughts on it, or having a rant of how difficult their documentation is, then I'm happy to do that and look at those tools. It really depends on the circumstances, I try to really focus it also on what I'm interested in, right? Like, I don't want to lose the joy of making those videos. And I think if it's not you who's driving it, if it's not you who's making the decision of which tools to learn about, which tools to use, then it can seem like another task that you have to get done on your list, which obviously something like a YouTube channel shouldn't be, it should be educational and fun. And that's how I want to keep it.

Liran Haimovitch  22:35
So, next time I have a task from my boss, I should send it your way to prepare video and send it to him.

Anais Urlichs  22:41
Okay. Yeah.

Liran Haimovitch  22:45
What do you recommend? What tips do you have for people evaluating new tools for Kubernetes? For the workflow, for their infrastructure?

Anais Urlichs  22:52
I think one of the main recommendations I have is look at the community and look at which tools right now are highly used. What do people struggle with, with those tools? And based on that make a comparison of some tools that seem really interesting, fascinating to get started with and to implement. And then, if you actually go through the community feedback, you might realize that a different tool might be more suitable for your needs. So it really depends on what's your end goal. What do you want to deploy? What do you want to do with the tools in the first place, and then from there, try to gather community feedback. And if there's no community input, any community signals, lots of projects have public slack communities are similar, where you can get involved and just start a conversation. And people will provide you with honest feedback and honest input of why tools are good or not so good to use for certain use cases. So, I would really try to gather as much community feedback and learn about existing use cases before actually going through the effort and implementing a tool. Also, you will want to have, like, kind of trial use cases, you want to see in a small scale environment first, if the tool works for you, if you can make it work, if it makes sense to you. If it does not, then it might not be the right tool before going through the entire deployment process and moving all your workloads, using that tool for everything that you do.

Liran Haimovitch  24:20
Makes sense. It really seems that whenever people speak of Kubernetes, the community keeps popping back. I mean, it's hard to separate us. It's not just about the technology.

Anais Urlichs  24:30
It's everywhere. I think in this space in particular, because you rely on so many open source tools, so many projects that people largely do as well in their free time. You can't really separate the technology and the community that well, like, it just doesn't, you would fall short doing that, like in other areas. For example, when I was working in the blockchain space, the project or the company behind a tool or project that's what it was. So, you would talk about the technology, we'll talk about the tool, not necessarily the community, versus here, you can't really differentiate it. Because also, sometimes lots of different companies or employees from different companies come together and work on a tool collaboratively. So, it's really about what do they come up with? And then, how does the community end up using it? I mean, many tools don't have 24/7 support, right? So you will want to know, what are the struggles? How do they solve their issues? How fast are people from the community to respond? How active is their community? How much do they think forward to the future of how is the tool going to evolve? Is it going to be maintained? In what direction will the community or those current maintainers take it? So, it's really like the community will actively shape the technology, not the other way around.

Liran Haimovitch  25:52
Yeah, that's kind of how things work when you're such a-- It's not so much a single vendor pushing a single technology or a single technology platform, rather than a large group of people, a large group of companies pushing, you know, tons of different projects that are interconnected. So there isn't just one, one voice that's defining the roadmap and building the documentation. It's off mesh.

Anais Urlichs  26:16
Exactly. That's a good point. Actually, lots of tools are dependent on each other to work themselves. Right. So, you're automatically dependent on other tools by other maintainers with other stakeholders behind it. Right.

Liran Haimovitch  26:29
There is one last question, I want to ask you a question I ask all of my guests. What's the single bug from your career that you remember the most?

Anais Urlichs  26:36
Let me think, that's a great question. So, it's not necessarily a bug, but a great learning experience that I ran through in my first week of joining Civo. So, I've never worked, properly worked with operators, before joining Civo and our entire infrastructure, everything was driven through Kubernetes operators, like that's what we used to manage our entire infrastructure, basically, just spin everything up. And then, yeah, so it's a huge part of it. And in my first week, I was supposed to make some updates to one of the operators. And they didn't quite reflect in the staging environment, how I wanted it to, and I just went ahead and deleted the operator. I was like, Oh, I don't need that. Or like, let's try again, let's delete it. Because what I did didn't work and I just wanted to have it removed. So, I deleted the app, like I deleted the resource, and it automatically deleted all the resources that the operator was managing, which I wasn't aware of until that happened. And it was kind of just a shock moment of reading in the Slack channel of like, who deleted all the resources in staging. Luckily, it was only staging. So, I had quite a shock. And at first, like in those first few days of like, oh, I have superpowers now. Obviously, it depends how you use the superpowers. Since then, I'm a lot more careful whenever I do something. I'm glad it happened my first week. I'm glad it happened on staging. And it was just, yeah, it was a great learning experience of don't just go ahead and delete resources in Kubernetes. It's not a good idea. Yeah.

Liran Haimovitch  28:15
But it didn't take down production, you're not necessarily.

Anais Urlichs  28:19
I'm working on that page and behind-the-scenes planning.

Liran Haimovitch  28:24
Waiting for the right moment.

Anais Urlichs  28:26
Exactly, when everybody's asleep, ideally.

Liran Haimovitch  28:30
Nice. It's been great having you and chatting with you.

Anais Urlichs  28:33
Thank you so much for having me. It was great. Yeah.

Liran Haimovitch  28:35
So, definitely check out Anais's YouTube channel and newsletter. We're going to have links at the bottom of the post and thank you for listening. So, that's a wrap on another episode of The Production - First Mindset. Please remember to like, subscribe, and share this podcast. Let us know what you think of the show and reach out to me on LinkedIn or Twitter at @productionfirst. Thanks again for joining us.