Open source today

Anais (00:05): If you get used to it over time, then at some point, the weekly releases are not going to scare anybody anymore because it's just so much part of what you do, what you work on, and how you work.

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I bet the depths remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Enjoy your time in the DevOps Sauna.

Marc (00:46): Hello, and we're back in the sauna. This time we've got Anais, a developer advocate at Aqua security and CNCF ambassador of the year from 2021. Hello, Anais. 

Anais (01:00): Hi. Thank you for having me.

Marc (01:01): Great to have you.

Andy (01:02): Yeah, welcome Anais, it's great to see you again. We met first at the state of open-con, that's the name of it, in London earlier this year. And you interviewed me. And now it's my chance to turn the tables and interview you. We thought it'd be great to get you on here. And we're going to have a whole season around open source and talk about what open source is, how to use it, what are some of the difficulties, all that kind of stuff. And who better to kick it off than you who've been like the CNCF ambassador and deep into open source and working as a developer advocate for an open source project. I think you know a little bit about the topic, hopefully quite a lot. How did you get into open source? And how did you get started? Let's just go from there.

Anais (01:54): Yeah, so for me, it was never really a conscious decision of me getting started in open source. A lot of people made a good distinction of open source versus not open source, working for projects that work for open source versus not. I started my career in the blockchain cryptocurrency space versus technical analyst and then as developer advocate for projects that were using decentralized applications, building decentralized applications in the platforms they run on. Everything was pretty much driven on open-source tools. And they had the open source governing setup between different community members and stakeholders. Everything was open source first, and us using any proprietary tool was very much a tough decision to make when we had to use certain tools that wouldn't really have an open nsource alternative. There are some, for example, for even something like Google Meets, they are open source alternatives, but they're usually not as good. In those projects that I was working in, we tried to use them, but a lot of times, we had to fall back to proprietary tools. And that was the situation I was in for the first years of my career until I changed into the DevOps cloud native space. And also, while working for enterprise companies in the space, I was always pretty much involved in the open source part of the cloud native space.

Andy (03:15): And it's just interesting that I started my career in the US Navy on submarines, so absolutely nothing was open. No way you could use anything open, quite literally closed equally to keep the sea out and everything. After that, I moved into telecoms, and I often joke that in telecoms, you need an NDA to find out where the bathroom and the coffee machine are. Everything is like this is our company secret. And this is so proprietary secret, this is our value add, there's no way we can share this with. I'm coming from the perspective of open source is really cool. And we need to find ways to convince people to use it. And you're coming from the perspective of well, of course, things are open and who would not use open source? That's crazy.

Anais (04:02): It's interesting to see and think about how much the perspective change because you outlined how it was a deterrent to use open source tools from an advantage perspective, right? Like companies wanted to keep their industry advantage by not revealing any of their source code. At state of open-con, I also interviewed somebody who is working on open source AI machine learning models to predicting the weather. And for them, it's crucial to now open source these tools to have that knowledge sharing across different departments across different organizations in different countries. 

Andy (04:36): And then you run into a lot of okay, of course, my own code, my company's code can't be open source, because that's our secret sauce. But how can we use open source to build that because what if something sneaks in or how can we trust it? Or what if we have an issue? How do we get support from a GitHub repository? This is crazy. I suppose there's ways to handle getting support and knowing what's inside. 

Anais (05:02): I think it's pretty much to me companies are just providing the services, the soft skills, I guess, on top of the technology, and that's what should differentiate them. When companies are dependent on open source tools, even like their source code is not, somebody can build something similar. There are so many companies where people can just build something similar, and just then providing the services on top of it makes them unique. And what you mentioned that how do you know what you're using in the ppen source field? How do you know that it's legitimate? I think it's because more and more people are moving to using open-source tools. People don't question whether the Grafana open source or any monitoring solutions that are open source, they don't necessarily question if they are legitimate because they're so widely used by so many companies. And that collective knowledge and collective input that open source now provides, generates the trust from the community. I personally wouldn't also use open source tool that's maintained and used by one person, I wouldn't do that. I wouldn't just go to somebody's GitHub repository, and use whatever projects they have. I think it's very context dependent on those soft skills and other information to the edit on top of open source that make it so reliable.

Marc (06:19): I think this is one of the really interesting things as well, where I've even had a company say, well, we have a pretty good impression that our competition is using these open source tools, so we should be using something else. It's like, my God, if they're using it, and you're doing anything else, then you're building something that they already have which freely available to you. But free is an interesting word. We talked a little bit in the pregame. Traditionally, we've talked about free speech, or free beer, or in Latin, it's [Latin], which is freedom. Andy had an interesting point, that it's not necessarily speech or beer, it's more like free puppy.

Andy (07:00): Free as in puppy. I've heard this used a couple of times. And I don't know where it started. And I don't know how widely it's used. But I've heard it a couple of times. And I love that analogy that you're driving home from somewhere and you see somebody on the side of the road with a box of puppies or kittens and says free to a good home. You take your puppy, and then you have a lot of things you need to take care of once you take this free puppy. And I think that's maybe a better analogy for open source software that yeah, you can use it, it's free. It's yours. Go ahead. And there's all this stuff that comes along with it, like how do you maintain it? How do you keep it up to date? How do you make sure it's secure? How do you update documentation internally around it? How do you get visibility of what dependencies it has? And there's all this kind of baggage that comes with maintaining software? How do you do that with open source? And that's where the soft services, as you're mentioning, come into play that if you find a partner who takes care of the soft services, and these things around the open source, then how open or closed is the source code itself is less interesting than how popular is this thing? How well is it supported by a community?

Anais (08:14): Yeah, totally. A lot of times, for example, the open source project at Aqua that I'm working with, we don't expect users to have to proactively update or contribute to those tools to make them work for them. I mentioned it also early because we release for example, on such a regular basis, we release fixes we deprecate existing commands, introduced new commands, that requires people to stay really on top of things and know what's going on within the project, they conscious passively integrate with our tools, and expect that the open source tools are just going to run indefinitely. And needed maybe have to check in every six months or something like that with our tools. But you actually have to stay on top of what's happening in the community after decided to change things around in a major raid, it would break your pipeline. These are kind of questions that if you are deciding to use open source tools, you have to stay on top of it, even if you're not like practically getting involved with the community. I guess that's also something that the community will help you with if it's a larger community that you have to put less effort into actually staying on top of things because the information is automatically generated by people as a collective entity, but still, you have to look at it.

Marc (09:33): I think it's really interesting here because I understand that your career is a bit young. But this is all you've ever known. And when I talk with companies that have legacies, essentially, they're not very good at change. But you're a perfect example of a company or a person and understanding a way of working that is very good at managing change. You're doing updates all of the time you're working with the community or upstreaming you're taking these updates more regularly than many companies can even do a release. And I think that this is a really interesting and fascinating example of how to do things in a modern way.

Anais (10:10): Yeah, it's also something I mentioned earlier that, to me, I can't grasp that there is a situation where companies have struggled to release updates, maybe on a year-by-year basis, because to me, it's just this is the only way I know of working, you have, I guess, monthly or even weekly release schedule depending on your project. And you just whatever you have, at that point that can be deployed to the project, you just release it, and I guess it's something else that people have to be conscious about. It has also negative sides to it, right? If you're using an open source tool, you can't 100% rely that it's going to work all the time because there's so many changes. Like maybe something is going to get deployed or released that isn't 100% working just yet, or maybe an edge cases are not working any more than you have been using those until that point. It has both sides to it. I watched a talk yesterday about somebody comparing the way that people now really software, it kind of to how mobile phones evolved, like early on, when people started having their own phones, and they wanted to have an update. If someone wanted to have a specific game on their phone, they needed to buy a new phone because you couldn't just change your phone. And that's also something that I can't really grasp. But now, I don't even know which version of Twitter is running on my phone because it's just these little updates, it's just going to do it in the background without me knowing about it. And that's similar to how I see a lot of open source tools as well. And that kind of strategy, that kind of way of deploying, and using software's just on a continuous basis, you evolve it over time. Yeah, it's not stagnant or not waiting for certain moments in time to change things.

Andy (11:52): It's interesting coming from domains and industries where things have to be so planned out ahead. And six months from now, this is what we need to have. And we need to have this in place. And we need to check that that's ready. And then we have this annual or really, really up to date and fast pace company might do it twice a year, updates to production mentality. And then you're talking about weekly deployments. And it's just breaking the brain for some people. But we were talking with one of our clients on the platform engineering side. And he was asking him, what would he have done differently. And he says, I don't know, not much of anything. Because we knew from the beginning, the tools will change, things will update, we will realize this wasn't a good tool, after all, we should switch to that. Just get used to changing and get good at changing. And if your skill set becomes changing things, then what tools you're using, it's easier to change and to adapt. And I really like that mentality, which comes along with this open source and CNCF way of looking at things and thinking about things. You're just always not moving fast and breaking things, but moving fast and making things.

Anais (13:06): Yeah, it's similar to, if you think just about people's lifestyle, if you're used to doing a lot on a day-to-day basis, if you're used to waking up early and basically keeping you busy all the time, it becomes a lot easier to you versus not being used to it, and then try to get into those certain habits and being more active or getting more done on a day-to-day basis. That's a huge step, but if you gradually move towards it, it becomes a lot easier. And I think that's similar to adapting to change. If you get used to it over time, then at some point, the weekly releases are not going to scare anybody anymore, because it's just so much part of what you do, what you work on and how you work. Versus if you turn it to somebody who is used to deploy updates, new releases on a yearly basis, they are just going to freak out and not know how to deal with it and how to make the best out of that new situation. Right?

Andy (14:05): Yeah. I have changed, but I'm going to assume the role anyway. In my role, I'm going to sit back and say, so we have to do an update every week. And then you're looking at it from the other angle of saying, we have to wait a whole week before we can update this?

Anais (14:23): Yeah, exactly. Pretty much. I mean, also, as developer advocate, I work on a lot of small changes, whether that's documentation or just the way that things are expressed in a command line, and so on. And those are things that not going to affect much. Me not being able to just update those things, it feels in a way sometimes very limited. 

Marc (14:46): I didn't think of this before, Anais, but are you a cloud native?

Anais (14:50): Am I a cloud native? Is that going to be a new term to describe a generation?

Marc (14:56): Well, it's interesting because cloud native, we talked a little bit before, cloud native is the only way that you've ever worked. Are you a cloud native, then?

Anais (15:06): That would be a good way, I guess, to describe me and my understanding of the software world. And the way that infrastructure is setup as well, like also, when I was working last year as site reliability engineer forum for a startup, we only used cloud native tools, we relied heavily on open source tools. And our infrastructure was caught native first, in a way. And that's what I knew how to deal with and workaround. And in advance and everything, I wouldn't know how to do it otherwise, I guess. Yeah.

Andy (15:45): We have to go back and redo the introduction. This is Anais, she's a developer advocate at Aqua Security, CNCF ambassador of the year from 2021, and a native cloud native.

Anais (15:58): Perfect, I'm going to use it in my bio from now on.

Marc (16:02): I think it's great, absolutely fantastic that we work so hard, Andy and I with companies that are trying to overcome their legacies. And you're so far beyond it, that you don't have to look back in this case. But let's do look back for a minute. You had an interesting 100 days. Tell me about your 100 days.

Anais (16:22): So 100 days of Kubernetes, I started doing my first role within the cloud native space working for proprietary company, and getting started with Kubernetes, getting set with cloud native tools and learning how do I optimize the use of the company tool with open source tools, because they were so heavily integrated, and also the companies that were using our tool, were using cloud native tools. It really much dependent on me getting unwrapped to Kubernetes as fast as possible, learning how everything is used and optimized, and it generally worked with and that's why I started my YouTube series called 100 days of Kubernetes. It was very much driven out of selfish objectives that I needed to learn Kubernetes to do my job properly. I got started, and basically learned every day across 100 day, something new related to Kubernetes in the cloud native ecosystem. And that then inspired lots of other people to get involved and do their version of 100 days of something, somebody started 90 days of DevOps, because they were like, well, Kubernetes is great, but for them, it's just it's a small part of their DevOps workflow and tools they are using. So they wanted to broaden it further beyond the cloud native ecosystem with also DevOps focused tools, and started that and built an entire curriculum that's open source on GitHub around that initiative.

Marc (17:52): I think it's fantastic that you said the word selfish at the beginning. And your selfishness has created and inspired so many people, and connected so many people together, that maybe it's not that selfish, after all.

Anais (18:05): It's something you've done at the beginning, right? Yeah, it makes me feel better. 

Marc (18:12): I think it's fantastic. The oxygen mask example, this is something that we talked about, like last season, like we lead off with Kelsey, I think we're on a first name basis now, where it was like you have your platform that you look at the world through. It could be something technical, like just Kubernetes, or it could be a language like Python, but this 100-day series, I think that was like a platform that you were able to look at things in a different way and connect people much greater than even if you were in an open source community and releasing upstream patches all the time. This is a wonderful example about how to get out there and make a much bigger difference in the world.

Anais (18:52): It's not just creating content around certain topics, but creating a higher level like schema around what that is supposed to be like when I say 100 days of code, people without having ever heard of it, they get an idea of what that's going to involve and then they understand why people would want to get involved and how they would get involved without even looking at it necessarily. It's just a theme that this is based on. And if you want to learn something related to Kubernetes, across 100 days, that's when you look into 100 days of Kubernetes, and similar, so it's creating those concepts that didn't really. I haven't been there before in that way, and then allow other people to build upon it with their own concepts and ways of doing things. 

Andy (19:39): Well, I think that's just such a perfect example of how open source community and open source projects work that you had your own itch you needed to scratch and you looked around and you didn't really find anything. You found another idea, 100 days of code, okay, I like that idea. And I can take that idea and I can build on it for myself and call 100 days of Kubernetes. And you got a lot out of it and you scratch that itch and you were fine with it. And then somebody else had something that like, I need to figure out how to understand DevOps. Well, there's this 100 days of Kubernetes. What if I do 90 days at DevOps, and they build something on that, and then somebody else adds to that repository and builds on that. This idea of standing on the shoulders of giants and standing on the shoulders of others, and helping lift everybody else, yeah, what you actually contribute, usually starts with scratching your own itch. It maybe sounds a bit selfish or feels a bit selfish in the beginning. But when you open it up to the world, and you like share it out, then it becomes something that everybody else can build on. And we're lifting all the boats together.

Anais (20:45): Totally. You also have to think about that way that about, like two and a half years ago, in the DevOps space, or the Kubernetes cloud native focus spaces, specifically, there wasn't that much not necessarily open source, but openly accessible educational content that was accessible to people getting started. At the time, there was maybe one youtuber who was focused on the space, which was nanotech worlds, if you know that channel, it's a very big channel. And at the time, it was very much focused on DevOps content. And since then, there are lots more YouTube channel and other blogs and content that have been created, that sometimes it's just needed that one person starts something and then provides the platform for everybody else to build on top of that. Like, for me, that was the 100 days of code from the coding boot camp space that I just adapted to the cloud native space.

Marc (21:51): Are you in Scandinavia this autumn? Well, if you're not, you ought to be because the world's greatest DevOps conference is coming to Stockholm and Copenhagen, I'll leave a link for you in the show notes. Now back to the show. A different topic than we've turned to like, as a developer advocate, are there certain trends or conversations that you're having a little more often, or certain topics that you're seeing in this work? Because developer experience is so important right now, everybody is still struggling to attract top talent. And there's a lot of churns in the industry. What's your approach with developer advocacy and developer experience? And what kind of things do you have going on there?

Anais (22:37): Yeah. I think it's obvious when I talk about developer advocacy, it's worth highlighting what I mean by that. I posted the other day on Twitter, like should developer advocates have the title if they are not coding or involved with code and technical skills like coding? In my opinion, it shouldn't be because that's moving towards Developer Relations versus developer advocacy. When I talk about developer advocacy, it's really about imitating to meet what the user would experience. If my users are developers of code heavy tool, then I need to be able to get involved with that as well, to know what's going on. Now, what you mentioned at the beginning of your question of what do I experience on a regular basis, working with developer communities working with open source communities specifically is that people have different questions on how to use the tool. It's usually easy to get started with a tool to use that tool, but then to integrate it in your workflow is a different story to integrate it with the existing tools. That's a different story. And what I experienced a lot is that with open source tools, you have to set things up yourself, you are required to use the tool and to then discover the tools that can be used in combination, and to make the output easier to reuse in different environments, basically. Now enterprise tools, proprietary tools, give you all of that out of the box, you don't have to take care of anything, versus with open source tools. That's one of the things that lots of people struggle with. Like yeah, this is a great tool, but how do I integrate it? How do I then use it? Because that's something that opens those tools, they don't give you that additional information. That's something that I experienced a lot that usually also maintainers of open-source projects, they are focused on their open-source project and not focused on the right ecosystem and the different components that are used with information within that ecosystem. When users want to get started, they sometimes are very lost on how to actually integrate those tools. And that's my role as developer advocate, to go through those struggles that our users’ developers within our community have and work on resolving those on experiencing the same pain points and then doing something about it because I'm in a position where I'm empowered to do something about it.

Marc (24:47): Excellent. I like the thought of bridging the tools together in the ecosystem as a developer advocate. I think that's really keen. It highlights something that we talked about a little bit which is that many open source developers are paid professionals working within a company for a goal. And when they take an open source tool into use, there's not always yet a straight ahead way to get help. Of course, there's forums and all of these different places where people communicate, Slack channels and things like that. But I love this idea of putting yourself in the shoes of the developer because the developer is the user in this case, and helping to create those bridges.

Anais (25:28): Yeah, a lot of the open source projects, especially popular ones, that I have very well maintained, let's say, like you mentioned, they usually have a company that's several companies in some cases that are backing that tool and paying for engineers to contribute to that tool, but according to their own objectives. For example, Argo CD is a tool that's very popular in the ecosystem. And it has several different enterprise companies that are integrating with Argo CD in their own platform. And for writing services on top or providing additional features on top of Argo CD that you will have to pay for as part of their platform. They are like, I don't know, five different companies, I guess that I can think of that do that with Argo CD alone. And obviously, they are driving their objectives on using Argo CD and building Argo CD the features itself that they need across those, they are different projects across the different companies, and then integrating it with their own services. But at the same time, if you don't want to use one of their services, if you want to use Argo CD with other open source tools as a standalone tool, then you can't just like you don't necessarily have access to the information on how to set it up. Because that's not what their goals are, but they have working towards in showcasing because then again, you have this enterprise objectives of how you want to onboard people to your tool, you don't want to make it necessarily easy to integrate the tool into other open source projects without yourself benefiting or your company benefiting from it.

Marc (26:57): This reminds me a lot of the model where then as proprietary companies grow and grow. They don't even want to do that. They want to have an ecosystem of partners below them to do the integration work as it goes on and on. And you said another interesting word, which was workflow. And we talk about pipelines all the time. And I haven't heard a lot of workflow in the developer space. I think of workflow in terms of media production a lot. It also comes to mind a little bit with Andy has an operating system about his daily workflow, but I really liked this developer workflow as a concept.

Anais (27:37): Yeah. To me, that's really what do you do? And a step by step to go through different projects. You access Project A in a certain way. But Project A then needs to integrate with Project B, how was the process like from you moving over during using those tools from Project A to project B, like, what does that process look like? And that's ultimately then translated into the workflow that is built for developers.

Andy (28:05): Excellent. And we were talking last season a lot about platform engineering and setting up these platforms and pipelines that once the developer commits, then we trigger this and this and this and this to happen and it ends up in production. But then there's still the that's once a developer commits, how do you get to that stage? How does the developer get things set up? How does he get checkout done? What kind of things does he need to do before they can check in? How does she know that she needs to do this and this and this and get that requirements? There's a whole workflow around just the developer part. But then when we look at the whole platform engineering between the whiteboard and production pipeline, that's just like, developer adds value. But there's a whole lot into that part as well.

Marc (28:54): Yeah, we do some work in value stream mapping often. And like I could visualize when Andy described it, so you oftentimes have this value stream map with 30 blocks in it. And then all of the value creation in that 30 blocks is between checkout and commit. All right, nice. It's been really fantastic having you on the on the podcast, and we have new for this season. We have a couple of different questions that we are going to ask everyone who joins the podcast. And the first one I'd like to ask is, when is the last time you tried something new? It could be work related or not work related, but what's the last time you tried something really new for the first time?

Anais (29:40): That's difficult question like something you have to think about and you want to come up with something very exciting. It's not necessarily that exciting. When is the last time I tried something new? Generally, I'm a person of habit. I love following my routines and my habits, so there's not necessarily always room for something new. Work related, I like to try out different tools on a weekly basis just out of curiosity to also like, I guess, to keep my mind sharp in a way and to be able to evaluate tools and form an opinion. That's something I do on a weekly basis; I just look for a tool that I've never heard of necessary. And then go try it out something else. What I tried new last year, what I started last year is lead climbing. I go regularly lead climbing and me being afraid of heights, that was a huge step. I'm afraid I can't give like this one big thing.

Marc (30:48): Well, I think it's two.

Andy (30:50): Two pretty good ones.

Marc (30:51): It's a big thing and a whole, it's a lifestyle. I think the first one, this is really fantastic. Tell us about the last new tool that you went and looked at on your weekly journey of trying a new tool.

Anais (31:06): The last new tool. I'm right now in the process of writing a Kubernetes operator. Now I have written with other people operators before, but was like cool pair programming, versus me writing it myself and me having to look up things myself. Those people knew how to write operators, and I was just contributing to it without having to figure things out from scratch by myself. I'm just looking at cube builder and an operator SDK, that's what I started to look at. And it's a process, to say the least, it's a huge topic. I'm reading even books about it, to understand how to not just how to write an operate, I think writing and operate itself can be pretty straightforward with those SDK set available, but how to write a good operator because there's so many badly written operators, so people also suddenly use that have lots of security issues and other things in play. But how do you write a good Kubernetes operator? Yeah, that's what I'm working on.

Andy (32:14): That's interesting because that's something I've been noodling around in my head that, could I solve this one problem I have by writing an operator? I'm going to be watching for your YouTube video or blog post on how to make a good one.

Anais (32:27): I think it will translate definitely in the long term into different content types. 

Marc (32:33): Of course, we'll leave a link, Anais, to your YouTube in the show notes.

Andy (32:39): And I have another question for you, personal or professional, personal is sometimes more fun, but professional, if you want. What's the last thing that has really excited you?

Anais (32:49): The last thing that really excited me? Let me think for a second. I think generally I'm in the process of planning DevOpsDays, Birmingham, again, with my co-organizers, we organized it for the first-time last year, and this year, it's going to happen in June for the second time. And I'm responsible to go through all of the submissions, all of the CFPs that we receive from the community and building the schedule for the conference. And generally, I'm always very excited to read those submissions, like some of them are just so creative, that I'm reading it, and I'm like Oh, my God, I want to hear to talk and I get really excited about those topics and about what the people submit because these are things that I obviously wouldn't think about that in the same way. Or I would just not make the connection myself or submit something along those lines. Having access as a talk, I guess, submission reviewer, to all of those submissions before they put on a schedule because once they are on a schedule, they are already like edited in a way or you read them in a different way. But when you first read them, sometimes for the first time, did somebody read that upstart besides the person who wrote it, that's so exciting. Anybody who has the option to become like to get involved with conferences to review submissions, do that because it just gives you so much inspiration for also your own work. I think that's something that I really enjoy. And it really excites me right now on a daily basis reviewing CFDs. Yeah, we received about 180. And going all of them is going to take me some time.

Andy (34:30): So what excited you is reading submissions for call for papers for a DevOps conference. You're definitely our kind of people.

Anais (34:42): Yeah, the thing is it's you get so much inspiration on it on how people use different technologies. And that's just so fascinating that you don't get in other ways in such a compact format as well as like as an abstract at a conference, right?

Marc (34:57): Anais, it's been absolutely wonderful and fun to have you on the podcast. And I'd like to thank you again for joining us and sharing your stories. And thank you. It's wonderful to watch your career and the work that you've done on the 100 days of Kubernetes. And I can't wait to see what comes up next. And we'll check out the DevOps days, Birmingham. And thanks again for being on the podcast.

Anais (35:23): Amazing. Thank you.

Andy (35:24): Thanks a lot. It was great to see you again. 

Anais (35:26): Thank you. You too.

Marc (35:31): Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Anais (35:38): Hello, everybody. My name is Anais Urlichs. I'm the open source developer advocate at Aqua Security. Aqua Security provides end to end supply chain security for your cloud native applications. I'm working specifically on the open source pipe. We're maintaining and contributing to two main projects. One of them is Tracee, a runtime security and forensic tool using EBPF but tailored at the normal DevOps engineer. And the other one is Trivee. Trivee is an all-in-one security scanner so you can scan any resources that you really using as a developer, as a DevOps engineer in your day-to-day workflow.

Marc (36:16): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (36:21): My name is Andy Allred and I'm doing platform engineering at Eficode.

Marc (36:25): Thank you for listening. If you enjoyed what you heard, please like and subscribe it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.