Everything from hobby projects to enterprises with GitLab

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests. Andy (00:26): I bet the depths that 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, we are back in the sauna. This week we have a fantastic guest. I apologize to all Hungarians on the line about my pronunciation. But we did practice during the pregame. So Péter Bozsó, a Solutions Architect with GitLab. Hello, Peter. Péter (01:05): Hi. Hi, Marc. Hi, Andy. Thank you, Marc, for the nice introduction. And I think you got my name very, very well. So no complaints on the Hungarian side, I could say. Marc (01:14): Okay, thank you. You see, Andy, I showed up to rehearsal. Andy (01:18): That's how it works. My usual colleague, Mr. Andy Allred, is on the phone. Andy (01:23): Hello, hello. And at least I have an easy name for you. Marc (01:27): That's correct. I'll start this with a story where I recently did some pre-sales for a potential enterprise customer. And they had a lot of government work that they were doing. So a lot of their customers were governments and they had a lot of different kinds of requirements for tooling. And they were looking for some platform engineering. And the first thing that I told them is well, the obvious choice is you have to go with a single one-stop tool solution. And GitLab is a really good one of those. So you are a channel solutions architect, Peter. Péter (02:02): Yes. Correct. Marc (02:04): So can you tell a little bit about the type of work that you're doing? And what is GitLab about? And why should people consider GitLab as one of the best solutions for what, actually? Péter (02:16): Let me start with explaining my title a little bit. Solutions Architect, that's anybody in the industry should be familiar. So I'm working on solutions, but my job is a bit special at GitLab. And it can be rather confusing, not just our customers, but even to my colleagues as well. So what regular solution architect does, they are working with customers, building their solutions, obviously, but my job is more about that I work with our channel partners as the channel part of the solutions architect, and I work with them and I essentially, think myself more of a trainer. So I help the solution architects of our partners, one example would be Eficode, to do their job using GitLab, that's essentially my job. And I do interact with customers, but rarely directly. I usually interact with customers and work on customer projects with a partner, together with a partner, consulting with the partner, helping them to see the full picture and make their customers see the full picture with GitLab as well. So that's my job. And about GitLab itself, my personal view, professional and personal view at the same time, is that what you mentioned, Marc, is spot on. So the main reason what I see at least in the EMEA region, so Europe, Middle East, and Africa, that people or companies are choosing GitLab because it can be very easily so out of the box, one-stop shop for everything, really from maintaining your backlog, building the code, writing the code, building the code, collaborating and deploying into production, that's one part. The second part I would say is the built-in security features that I see that many, especially big enterprises, not just the security, but also the compliance features. So it's very easy to set up complex organizational structure inside GitLab. So if you have hundreds of projects, hundreds of developers or project members, it's easy to set up GitLab in a way that it's not getting in your way when you are doing your job. But at the same time, you can still maintain compliance, you can still see what's going on. It all ties into the one that circles platform strategy. So it's basically an extension of that. But I think it's an important aspect that you have these features, the security and compliance features as part of the whole story. And this is something actually a big challenge for me personally and for my partners to spread the word about this because what I see in the market, a lot of people, so like actual end users of GitLab, still look at GitLab just like okay, storing my source code, running my pipelines. And I'd admit that's the bulk of it. And that's what made this product great. But since then, we started to expand into other areas. And that's a challenge. But it's a good kind of challenge to get this message to the actual end users that, hey, when you use GitLab, when you buy GitLab, you get so much more than that. So I would say there's the second. And the third is that the nature of openness, not just the product, but as well as the company. So what I see that people really value about GitLab. And there are many more, these are just my main three takeaways, that not just the product itself is open source. So you can check the source code, even submit merge requests to the original repository. But even our backlog is open source, it's open in the public Internet. And many of our customers value that so much that they can know exactly what we are working on, they can see where a certain feature that they are looking forward to have, where is it in development, they can provide feedback, the feedback is actually listened to by our engineering team so that I would say the third point, which is usually very valuable based on the feedback I get from the customers to the partners. Andy (06:11): All right. I suppose I can kind of go both ways that I see something I really, really need in the backlog. And it's not moving anywhere because it's not a priority, but I can see it on the list. Why not? But at the same time, understanding that it's on the list and see what else is on the list might alleviate some of that pain. Péter (06:30): Yeah, I agree completely. Marc (06:32): There's a lot of things there that I'd like to touch on better a little bit. One of them is you're just to explain to our listeners, sometimes you know, a customer or company they approach, a company called GitLab, and then GitLab sends them to Eficode. And there's reasons for this. One of them is scalability, at least in my opinion or in my experience, one of them is scalability. And other one is kind of having a localized and personal touch on whatever it is the work that they're going to do. Another one is that GitLab has a very wide offering, there's an awful lot of things to consider if we're just taking a tool focus on something which many people do. The tool is the thing that they touch every day, and that they complain about or that is supposed to get out of the way for them. So they come to us looking for a tool, and it's like, okay, what you need to understand is, this is going to change the way that you work, it's going to change your ability to adopt best practices, it can even be. I've seen going to GitLab as a lever for cultural change within an organization and may have certain pathologies that they can't get away from. So it's like, okay, let's break all of that old stuff by changing the tooling. But let's use that in order to build up a set of best practices. Péter (07:48): No, I believe that's a very, very important point that you are making there. And it's funny because I think it was half a year ago or so I just had a webinar together with one of your colleagues, Darren Richardson just about this exact topic. So this was the whole topic. The tool set is just one part of the picture, you need to look at, what are you doing as part of software development? What are the processes and how you can complement those with adequate toolset so yeah, I think it's very important and just 1 more point from my side regarding why apartment is valuable for GitLab. The points that you've made Marc are absolutely valid. But one more point that most likely for the finished market, or the Nordic market is not so obvious, because my personal experience is that more or less everybody speaks perfect English there. But you cannot imagine how valuable a local partner in southeastern Europe, in France, in Middle East in Latin America, in India, so it's just that you are literally able to speak the local language that simple fact is so valuable and goes such a long way with the customers and makes the whole collaboration much more easier, that's a very weak point, especially in EMEA. So in this region, where every 1 million people speaks another language. So it's very important. Marc (09:12): One of the things that I have noticed over the years is that there are many, many organizations out there that have maybe a sponsored set of tools or a suite of tools that they're using or whatever. But then there's always at least one or sometimes many teams that are running GitLab on a local machine sitting under somebody's desk that has shadow IT and the cleaning lady hits it with a vacuum in the evenings. And then what happens is when these companies realize that they need to standardize their tools, then there's this fraction that says, well, we've been using GitLab the whole time, why not use that? And then this kind of whole process starts where the top of the company or the ivory tower will start trying to say, well, we need to tell them what tools to use. And they're like, we've already got GitLab, we'll just roll it out in the rest of the organization. Péter (10:07): Yeah, it's incredibly important and to be completely transparent because that's one of our values at GitLab. I have to say that we are not doing a good enough job of that. So we are not spending enough effort on spreading the word across the actual people who are actually using GitLab. So the developers and the infrastructure team, the platform teams, because we are lucky, I can say without a doubt that the product is solid, it's good. So it's getting spread by itself. But at the same time, what you were talking about Marc, I think it's an extremely important point that that a lot of times to get into an organization, the easiest way is to go through the actual users, or the soon to be users of GitLab. And approach this conversation sort of bottom up. So not coming from the management level or the director level, but from the actual engineers, when they get asked, okay, what do you prefer? What is the preferred tool set for you? And then they can say, yeah, it's GitLab. Because of this, and this, and that, that's an important point. Without disclosing the actual deal, I can say that we had some very big successes in the region already recently, with this approach, where the customer was approached by many different vendors. And the reason why the customer chose GitLab, at the end of the day was literally because the developer team was so adamant in saying that we prefer GitLab. We used it at previous jobs, we know the value, we see the value already, and we want to use this product, end of conversation. So yeah, it's an important thing that this whole topic is very important. I have to agree. Marc (11:48): All right. What are the things that we talked about in the pregame was this kind of hobbyist mindset as well. How do you tie like this word as a hobbyist back into GitLab? So are there hobbyists using it? Or is it about having hobby projects with your code? Or is it a mindset? Can you tell me about this hobbyist mindset idea? Péter (12:09): Yeah, absolutely. This is my personal experience as well, and it ties to what we just discussed previously, like coming from the developers going from that point on what is that? My personal background, I'm a software engineer. So I was working on writing source code in my whole career and transferred from that into the DevOps space. And recently, just a couple of years ago, I started self-hosting stuff myself, really just to try out playing around setting up some backup for my photos and stuff like that. So very basic things. But I got introduced into the self-hosting community, so to say, so if you go to Reddit, there's a self-hosting subreddit there. There are many old school forums there, Slack channels, Discord channels, whatever you can imagine. And in this community, GitLab is very big. Exactly because of the ease of hosting it. As you said, previously, it's all PC sitting under the table for somebody at the company, many people does that at home self holds the open source versions of the GitLab is in itself. It's incorrect. It's not open source. It's an open core product, right? Part of it is open source, part of it is proprietary of the source code, it's all available, but some features you need to pay for. But the free part is there for everybody to host under a very permissive license, so you can literally do whatever you want with it. And I think that fits into this culture really nicely. And we GitLab, the company and the product gets so much mindshare through this fact that if you have such a setup at home, you can just plug GitLab into it. You can set it up. I'm horrible with this stuff. I said I'm a software engineer. So if anything is more complex than just a couple of comments, I usually mess it up and I have to reinstall Linux on my machine. But with GitLab luckily it's literally just a Docker container. You'll give it the parameters, what port to listen on, how to do the redirects, where's the database, and it goes, and it just works. So this is what I would call the hobbyist mindset. Many developers and many infrastructure engineers have and they bring GitLab a lot of times not from previous employment, but actually from their hobby projects that they use GitLab to host their hobby projects and play around, automate everything. Just a quick derail. I have a friend who is using GitLab pipelines for automating his life, like literally everything is automated by GitLab pipelines at this point for him. It's crazy. <laughs> Marc (14:53): It's quite something to say when a developer has a choice of what tool they wish to run, and of course, there's more than cost as a factor. And they choose GitLab as what they will run their hobby projects with. I think that's pretty neat. Andy (15:12): Often the best tool to run is the one that you're already running at home. Because you've seen the rough edges, you've seen the pain points, you know how to work with it, you know how to think it, your brain starts to think in that model, and then you just see, okay, well, I'd run a GitLab at home on my own server. So when I go to work, I see these GitLab sheet holes everywhere at our solution. Péter (15:36): Yeah, absolutely. Me and another colleague of mine, who is also a channel Solutions Architect at GitLab, we started roughly at the same time at GitLab. And I have to say, I had more or less zero previous experience with GitLab. I mean, I knew it existed before joining, I had some familiarity with the product, but I haven't used it myself and my colleague, he also used it mostly for infrastructure as code stuff. So for us, it was actually part of our onboarding learning experience to set up a GitLab instance on our own machines at home, our own home servers play around with it and get, as you said, Andy, I think that's spot on video because I have to say, GitLab, even though I'm employed by GitLab, GitLab is not a perfect product, nothing is. So there are rough edges, and there's the only way to get to know them when you actually install it, when you actually update it. That's always when the janky stuff might come out, like, database migration and stuff. So far smooth sailing with my installation, I have to say, but still, you get the mindset, and you get the understanding. Okay, what's going on here? So that's important. Marc (16:46): This goes into, I think, an interesting topic. So great that people are running this at home, and they're running their hobby projects on it. So there must be something about the developer experience, there must be a community behind this as well. Can you tell us a little bit about the developer experience of GitLab? And then maybe how you use the community in order to improve that or how the community views it or this type of topic? Péter (17:11): Yeah, absolutely. I would tie it back a little bit to what we discussed previously. And what I said about we having not open source, but an open backlog. So our issues are there on the Internet, and there are some really good conversations going on there. So a lot of times, I monitor some of the issues myself because some features might be important for a partner or a customer of a partner. And it's not just that we are communicating with the partners, or there would be companies there. But actually, individuals come there and provide their feedback about certain features that we are working on or opening back tickets and feature requests. And there were many times that our product team really have been able to incorporate that into the product. So I would say that that's a big part of our community building, we have our GitLab champions, who are people who are contributing to the actual source code of GitLab. So the actual code base of GitLab. And we have a very good relationship with these people, they are all over the planet, there are individual people, freelancers, even students, there are people from big corporations who are using the product, and they would like to implement something, scratch their own itch, again, coming back to this whole hobbyist open-source mindset. So that's certainly a big point for us. I don't know if I'm answering your question. I'm actually just talking here. Marc (18:33): I think it went well. And one of the things that we find in many projects is that there's usually that one guy, but it could be a group of people, it could be a team, they could be spread out, they are so concerned about their one tool that they can't even imagine a world without that or imagine a world that is better than what they've been able to cultivate with their pet Jenkins or something like that. And I've seen installations with GitLab using Jenkins to run the pipelines. Is this something that you could open up for us a little bit? And maybe are there some arguments that we could make or argumentation or rhetoric or something or just plain straight out factual based things that might help in those types of situations to get people to clearly understand that you can do what you need to do with a one tool solution and that has advantages? Péter (19:28): Yeah, this is a very important topic. I'm working a lot in the EMEA region. So Middle East Turkey, Africa, onboarding a lot of new partners and I'm having this conversation many times with the partners through the partners with the customers like okay, I understand the value proposition. Very nice, says the customer, but why should I just drop let's say what you just, I don't want to pick on Jenkins, but like the Jenkins setup that I have for five years, it's been working nicely for me. What's the point of replacing that? And I can fully go with that, right? As I said, I'm an engineer, if it's not broken, don't fix it. So I'm fully supportive of that. But at the same time, I believe that GitLab can bring a lot of value, as we discussed many times because of this one platform approach that we have everything built into the product as a feature, instead of having separate tools that are integrated together. But this is a difficult conversation, I would say. And it's always very specific to the given customer. Sometimes you have a choice of your tool set that you choose. Sometimes your leadership team listens more to the people who are using the tools and doing the work. Sometimes it's more like you are being told what you need to use. So in that case, it's not much you can do. But in the case when the conversation is open, people are open. They're curious, I still believe that especially myself, being a technical person, the easiest way to talk about these things is through a demo. So that's what we usually do. We do a demo together; we might do a proof-of-concept project together inside GitLab. Saying that, okay, let's say you have a JavaScript project deployed as a microservice architecture in Kubernetes. Okay, let's just try to set that up in GitLab. Let's see how the setup that you already have, with whatever tools I'm not naming names, but whatever tools you have, right now, to build your DevOps tool chain, let's just take a look at how can we do that with GitLab. And that's the easiest way to show the customer shoulder. Again, the actual people who are using the tools in their day-to-day job. What is that? What does it bring to them? And it just starts the conversation, we can get into the details of how to do this, how to do that. For me, that's always the most effective way. I mean, you can talk about slides for days on end, but more or less, that's meaningless, right? Showing diagrams. Let's look at a real-life example. And that's usually when the conversation starts, and we can really show the customer the value of the product, I would say. Marc (22:08): Hi, it's Marc, again. If you'd like to unlock the true potential of GitLab for your organization, be an enterprise or a small team, let us know. We'll leave a link for you in the show notes. Now, back to the show. Andy (22:27): As a former and still sometimes recovering grumpy old sysadmin who really add the attitude of you can take my tool when you pry it from my cold dead hands. Marc said they can't even imagine a future without that tool. Yes, we could. It was dystopian authoritarianism, Orwellian, but we could imagine it. We just didn't want it. But I think that when you come back with a demo, as you are saying that, okay, well, here's what you have. And here's how we would look and here's the other things you can add to it, and you actually see it, then it just opens up the conversation a lot more from well, that's not my tool to well, here's how it's filling the use case. And that just changes the whole conversation. Péter (23:08): Because if you go to these people, because as you said, Andy, I'm that kind of person as well. And somebody comes to me and says that, yeah, if you use GitLab, your life will be perfect. And the cat won't vomit on the couch anymore, right? <laughs> As we discussed previously, then I will say, oh, come on. I have nobody believes that. But if I see a demo, and I can see my processes in another light, right. So that's how I do right now. That's how it could be done. That's actually meaningful, and starts me thinking and comparing and just starts the conversation. I think that's the whole point, just start an open conversation where we actually listen to each other. That's the core of it. My mentor, in my previous job always said, he said, the easiest part of this job is working with computers. Because computers do what you tell them to do. And that's it. Maybe sometimes they don't do what you want them to do, but they are still doing what you tell them to do. Working with people, that's when it gets difficult. Andy (24:11): And now this has been a lot of cool conversation, interesting topics. We've been going a little 26 minutes, and it's August of 2023. So I'll be the one who brings it up. How about AI? Péter (24:27): How about AI? You tell me. <laughs> AI is all over the place. I mean, it's hard to open any kind of new site and not read about AI taking away jobs, AI doing everything, literally. So yeah, that's a central topic in GitLab as well so our customers are more and more interested in AI features. There's the cool thing for me, at least as a solution architect that our customers or your customers our partners customers are not just interested in using the AI, so like chatting with a chatbot, and getting suggestions and stuff like that, but actually developing their own chatbots and AI models. And I believe is a very cool thing that GitLab we are striving to cater for both audiences because I believe any project team or any software developer team can benefit from using AI. So getting code suggestions, getting security alerts in this way, but there's still minority, but growing minority of customers who actually are mandated to or they want to build their own AI based solutions and at GitLab we are developing features for both of these audiences, which I believe is really cool. How do you see it at Eficode with your customers? What's the fear for AI in the Nordics right now? Is it very important for customers? Or it's still more like, yeah, sometimes it will come. How do you see it? Andy (25:58): What I hear from the customers a lot is just what is this AI? And what do we need to think about it doesn't really do anything kind of stuff. Yeah, it answers some nice chats, and he gets some funny memes out of it or something, but does it really help. And then you do a little bit of this kind of code suggestion type of it, here's some code you can get from it. And it's not going to be as good as a developer with 20 years of experience, but it will jumpstart you and kind of get a lot of the boilerplate stuff out of the way and enable you to kind of think about here's how you. I could solve it that way. You may throw away everything you'd get from the code suggestion, but the suggestion itself is like somebody else say, well, here's an idea that might help. And if you kind of take it with that mindset, and so they've been really interested in that. But some of the most interesting conversations have been around exactly what you said that how can we use the AI? Not how can we consume it, but how can we create it and integrate it into our offering, and kind of benefit from AI? More than just using ChatGPT or something as a chatbot. Péter (27:08): Yeah, absolutely. And I believe what you touched on is one of the most confusing part for evidence ages for GitLab customers, but like people overall, non-technical people who are not software engineers themselves. They don't fully understand how these AI models work. But still, for people who are working in the software industry, and this is a conversation, which I'm having so many times in the past couple of months is GitLab also started to roll out our own AI features that a lot of people who are not developers themselves start to look at AI, especially code suggestions, as you mentioned, like I get a new developer, right? For so cheap, is just a subscription. And I get a junior developer, like the AI is a junior developer, which is yeah, I mean, it's easy to perceive it that way. But I'd like to look at it more like it's a new kind of search engine or new kind of interface for data, right for information. So as you said, Andy, that was spot on that you still need the developer who needs to interpret what he gets, or they get as a suggestion, but it can get you really quickly started. Personal experience, as I mentioned, previously, I have this home server setup, etc. I was writing the best trip to automate some stuff. For an experienced person, I believe it was trivial stuff. But for me, who is more of a software developer, I have more or less very, very little experience with Linux, it would have been a no joking at least two hours of just Googling, just like looking for okay, what is the magic incantation that I have to put here? I know what I wanted to do, I knew what I wanted to do. But I didn't know how to exactly express myself in bash. And I just used an AI tool for that. And I was able to put together a working script in 20 minutes or so. And I knew that in two hours, I would have been arrived at the same solution myself, but just the fact that I asked, okay, how do I do this and that in bash? In Ubuntu, Linux, BAM, there's the answer. And sometimes it was a little bit off, but I get what to look for, get what to search for. And so I look at it more like, yeah, you don't get a new employee, but your existing employees will be much more productive, that's for sure. Yeah, absolutely. Marc (29:25): To take the conversation in a little bit different level, we were talking about. So Eficode traditionally been a DevOps company. We have a lot of partnership work that we do with companies like GitLab, and Atlassian, and our customers are always kind of they want to understand what the industry is up to, what we might believe is coming and all of this and what ends up happening in so many discussions around technologies is people start talking about the tools and then it's like, okay, let's rise to conversation for a minute. So if we define innovation as It's not just a new idea, it's oftentimes taking two things and putting them together in a novel way. Okay, so then we can think of this in in multiple directions, we can take an existing thing like GitLabs software development interface, and you add AI to it. Okay. And then now you have a bunch of use cases, and some things you can do. But then what I kind of realized this, the novel way is the AI. So it's like, let's take a few different things and put those together using AI as part of the glue. So if we were thinking about a company that wants to take public and private information, and by using AI, be able to leverage these in a variety of scenarios, test those scenarios, and then use this to have more data focused and accurate forecasting for whatever area that they're doing. It could be even things like software delivery, predictability, it could be in how they are using customer data in order to prioritize backlogs and all of these kinds of things. This is where I think it gets really interesting. Péter (31:03): Yeah, I fully agree with you. Yes. So in a lot of times, AI in itself doesn't need to be like a new product, right. We create a new product with AI, it's a lot of times and this approach, if you if you take a look at GitLab, current AI features, apart from code suggestions, which is I would say a new category. So like giving you suggestions as you type your source code, every other feature that we have is literally existing features with AI on top, so to say, so like, how can we make it more productive, what you are already using GitHub for by putting AI features or sub features, so to say, or AI aspects into some of the features, like my favorite one is, which I actually use myself day to day because I need to jump between many projects is to explain this code to me. So just select the code in your repository. Explain this code. And yeah, as I said, I'm a software engineer, I know many programming languages, but obviously not all of them. And it just so useful when I jump into Java code base, I'm more of a dotnet guy. But still, there are some differences or C++, I can say that it can be striking difference. Sometimes I just select it explained to me. And again, as I mentioned, I'm a software engineer, I know many programming languages, but obviously not all of them. And it just so useful when I jump into Java code base, I'm more of a dotnet guy, select it, yeah, I can get a feel for it. Because dotnet and Java are not so different. But still, there are some differences or C++, I can say that it can be striking difference. Sometimes I just select it explained to me. And again, as Andy mentioned it, it's just about getting started shortening the time which you spend with understanding what you have, and it's making it more fast to be able to meaningfully contribute. That's the main point for me, at least personally, but that's what I see in the market as well from the customers. This is the feedback that we get that okay, yeah, how can it make it even more productive for everybody in my organization, not just for the developers, there's just one person on one piece of the team, one part of the team. Andy (32:49): I like the explain it to me, but then I often follow that up with, how would you write this in 'insert my favorite programming language here', and it's not going to work, what it comes back with isn't going to be like a direct language translation. But this is the logic these applications or this code is trying to implement. And then between explain it to me, and show it to me in a language I'm more familiar with, you get this aha, that's what it's doing and then you know where to focus next. Péter (33:24): Exactly. And that's what was half an hour of Googling before these tools. Again, you end up at the same place at the end of it. But you can shorten this time of like when you want to understand something, but your understanding is so low of that particular piece of technology that you don't even know what to look for. So you spend time with looking for what to look for to get your answer. And this is what the AI is nice with like, can get you the pointers, you have to walk the path yourself still, but it gives you like, the signs, okay, this way to go. Okay, thank you. Andy (33:59): And when you ask it to help you do something in bash, maybe the command line variables, and the options are totally wrong. But then you see, there's an option that does that. Okay, maybe if I asked this question, and then you find the answer. Péter (34:13): Yeah, exactly. Or just having the actual comment line snippet and then I can look up myself the parameters and the switches and everything and the configuration file format. But to get to that point to know what I'm looking for. Yeah, exactly. That's where it gets really useful. Absolutely. Marc (34:29): And I have to say as someone who sometimes has attention issues, you don't always end up in the same place if you're just Googling about your problem because there's so many distractions when you come out of context and being able to do this directly in the IDE, literally in the context of what you're working on. I think that's something not to be underestimated. And also, just a reminder that when we are working with AI, we're constantly building the Context to get closer to the output that we're looking for. So the more that we're adding there as we go along, it's the thing that's interesting to me now, instead of trying to tweak a Google search in order to find somebody else's opinion about what something is, in this case, we're getting closer to the most valuable information for the context that we're creating using the AI interfaces. Péter (35:26): Yeah, absolutely. Marc (35:29): Cool. All right. I think this has been really fantastic, Peter, I think it descends from Peter, pretty soon it's going to be Peter at the end of the. It's been a really fantastic conversation. And we do have two questions that we ask everyone that comes on to the podcast. I'd like to ask you first, Peter, when's the last time you tried something new or tried something for the first time? And what was it? Péter (36:01): Yeah, the last time I tried something for the first time. Yeah, I'm already like jumbling it up. I moved one year ago to Austria from Hungary, I'm Hungarian, I haven't been speaking German at all. And since then, I'm here doing my best in my short, free time to learn the language as much as possible. And last week, I've been to Germany for a German partner, and I spent the day with three German persons. And that was the first time when they accidentally obviously you get tired, and they just accidentally switched to German and started to vivre looking at some architecture, and one of them started to talk to me, like directly in German, and I was like, yeah, I kind of understand that. So it was such a big, big feeling of accomplishment. I couldn't understand everything, obviously. But like 70% of it. And that I would say, that was the first time I could actually understand the native speaker talking to me, actually, about not like, what is your name? This is how much an apple costs. So something a little bit more complex. So yeah, first time understanding German that was it. And it was awesome. That was the highlight of that architecture discussion for me like yes, I'm doing it. Andy (37:18): And judging by your 'yes, yes,' your answer might be very similar for my question. But what's the last thing that really excited you? Péter (37:27): Yeah, it was this. I mean, it was my cat vomiting on the couch yesterday, that got me really excited, but not on a good way. But yeah, the good kind of excitement was this last Thursday, finally. Marc (37:39): Awesome. It has been really fantastic, Peter, to have you on the podcast this time. I look forward to working with you on solutions. It's really cool to see how GitLab is coming out swinging and taking market share and providing really cool solutions for our customers, as one of your partners. So thank you very much for being on the podcast. Péter (38:05): Thank you very much for having me. It was such a great experience. And yeah, I'm very much looking forward to work with you. I mean, that's how I see. And that's how we see at GitLab that our partners are basically a cornerstone to everything we are doing, especially here in the EMEA region, because our customers are more inclined, especially the big enterprises to work with partners. So for us, the relationship and the work you are doing is extremely valuable. And yeah, let's keep it up. And thank you again, for having me. It was such a great experience. I hope we can do something like this again in the future. It would be my pleasure. Andy (38:40): Definitely. We'll talk about that. This has been really great. Thanks a lot. Marc (38:44): All right, for Andy and Marc, and the Eficode DevOps Sauna, we're signing off. See you next time. Andy (38:50): Bye-bye. Marc (38:55): Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are. Péter (39:02): Hi, everybody. Thank you for having me on the podcast. My name is Peter Bozso. I'm a channel solutions architect working at GitLab. I'm Hungarian based in Austria. And my job essentially is to work together with our partners at GitLab in the EMEA region, so Europe, Middle East and Africa and help them to understand our product more and help them to help their customers to understand our product more. Marc (39:27): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode. Andy (39:31): My name is Andy Allred, and I'm doing platform engineering at Eficode.