Ramzi Akremi is a senior Salesforce technologist, Modular Salesforce Evangelist, who applies software engineering to Salesforce & DevOps.
Main Points
- Why Ramzi focuses on the DevOps topic in Salesforce
- Concepts and terms in Salesforce DevOps and DX@Scale
- Application architect and modularization
- DevOps mindset and practices
- The hurdles of moving to real DevOps in Salesforce
- Small steps to learn DevOps
- How code quality influences DevOps
- DevOps engineer’s role in Ramzi’s perspective
- How to engage Salesforce developers to learn software engineering skills
- Things related to the DevOps concept
- Great salesforce developer
- DX@Scale tool
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:13] Hey everybody, this is Xi Xiao. I'm sitting with a new guest. His name is Ramzi Akremi. Hello, Ramzi. Hi Xi, nice to be here. How are you? Yeah, thanks for your time and good and good. So we are talking across the continent now. You're from Australia and from Finland, the north and the south. That's at least twenty seven hours of flight. Yeah, yeah, and it's winter and summer difference. It's really the season. So Ramzi, would you like to quickly introduce yourself? Yeah, who am I? Um. Fell in love with computers when I was twelve. Started to code back then. Still coding today in different technologies. Salesforce being one one of the main. And I took the kind of open source route with Ruby and Elixir a few years ago. So pretty fan of those three different platforms. Started with Salesforce back in two thousand and ten, kind of a random thing, really. Ended up building one of the largest Salesforce implementation in Europe back in two thousand and ten, and then had the privilege and the extreme luck to. Work on the World Economic Forum Salesforce implementation back then, which was extremely challenging, and where I learned. Tons of things when it comes to Salesforce. Moved to Australia back in 2014 with the whole family here, participating into growing the Salesforce
[01:43] practice for my previous company here, and then started the big transformation program. When was that? Back in 2020, which was about moving an entire. CRM platform that was on SAP CRMs and Desk and and other places and bring them into Salesforce and with that we we actually use one of the asset that we have open source back then which is called the Excel scale for now probably the name is going to change and we we have seen wonders and we have seen amazing amazing results to the point where we have open sourced the Excel scale. And we have started to actually talk about the benefits of using the approach that we were using on this transformation program. We have now a community of. Almost four hundred users. We know that the XAI scale is being used on more than one hundred and fifty production orgs, and we are starting to communicate a little bit more loudly on the model because we think that this is one model that is very different from what it is that we are seeing in the DevOps space when it comes to Salesforce, and we think that's the model for the future. But the thing is, why do you start to focus on the DevOps topic? Because the DevOps topic has always been really blurry. If you think about it in in the Salesforce space, right? I have seen horrors in that space where. Where people
[03:14] did actually take weeks to deploy a new Salesforce solution, so they are working for six months implementing something, and then they are trying to go to production. And guess what? Nothing goes according to the plan because we we have missed something. We do a deployment, we fail, we fix the deployment, we try again. You've been there, right? So you have seen that kind of things. And comparing with other technologies, I was that can't be it, right? That can't be the life. It's a nonsense, right? Yeah, it's it's completely nonsense. So our thinking and my thinking back then was, if it was a tool problem, then somebody smart enough would have created that tool. But because we still have the same problem, that means that this is not a tool problem. Essentially, this is this is deeper than that. And this is where, coming from a software engineering background, if you if you look at the way that Salesforce applications are designed, you realize that this is a huge blurb of things. And the marketing that Salesforce has is amazing. They are calling that the happy soup. In my mind, there is nothing happy about a soup. It's just a soup, right? Yeah. And then when when Salesforce DX came, and the work of that team in the Salesforce product area is amazing. They brought exactly what we were
[04:44] seeing in other technologies like JavaScript with npm, like Ruby with gems, with like Rust with with the cargos and and all these kind of things. And they brought that notion of package. And the moment where you bring that notion of package, you bring the notion of modules. And the moment where you bring the notion of modules, you bring the notion of. Application architecture and how you design your application. I'm not talking about the design as in Service Cloud, Community Experience Cloud, Revenue Cloud, or those different components. I'm thinking about the architecture inside the application, the service layer, the boundaries between the different the different things, and then. We already had a small tool that was open source back then, but it was extremely painful to to actually adapt the CI/CD pipelines each and every time that we that we wanted to add another module or another package, right? And this is where I had the conversation with with Aslan, telling him. Hey Aslam, I want to be able to create a module with one field if I want to, and not be slowed down or stopped because somebody needs to update the CI CD. His first reaction was, "Oh man, it's too hard." And then he went on, and he came back two weeks after that and tapped me on the shoulder, saying, "Hey, let me show you something, okay?" And
[06:14] typing the SF DX project just on the manifest, adding something, and then adding another field on top of that, and then just executing a command line. And the CI/CD was organically adapting to this. It was reading the application architecture, and inferring in what order it should deploy things. And that's how the orchestrator came to life. So, if my point here is. DevOps is hard in the Salesforce space because one, we didn't have the tool. Now we have them since five years. The next stage is how we architect the application in such a way that we actually don't need to worry about a DevOps team within within the organization. Just to be specific to what you mentioned, this DX tool and the the the package that's what Salesforce currently calls it as the second generation packaging. Yes, module, right? That we can. Okay, okay. I don't know if the name is going to change in the future because because there are so many different things are moving parts. So we just need to be getting down to the. Unlocked packages. That's the reason why it's it's hard to communicate around this. So let me put it this way. If you have proper modules in your application, then deploying them, installing them
[07:44] is something that a tool can do for you, and you don't need to do anything about that. And that's exactly what what the ExactScale does. Now, what is a module? A module is a set of metadata that are related to each other. Okay, now I'm not talking about packages here. I'm just saying it's a set of metadata that are related together. Now, if we think about the delivery mechanisms in the Salesforce DX space, you have three main delivery mechanisms: you have managed package, unlocked package, and org dependent package. But we know that not everything can be packaged, and not everything should be packaged for some reason. So that's the reason why in the DX at scale construct, what we have added was two other types of packaging. We are talking about source packages, which is just metadata API deployment, and we are talking about data packages, and we are using exactly the same process to deploy data source unlocked, managed, and org dependent. The system understands what kind of. Packaging you have, and can adapt its way of installing something. So, why source packages and why data packages? Right, because some of the products in the Salesforce space do use data as a way to be configured. If you think about
[09:15] Revenue Cloud, the CPQ thing, it's essentially data, right? You need to master that into a version control system. You need to have modules around them. So that's the reason why we have invented that source. There are different reasons for source. The first one is going unlocked packages or going into a packaging upfront can be very painful because you can make mistake and not have the right boundaries. So source for us is a way to kind of identify very early on the boundaries of your system. So that's one safe way to have modules without all the complexity and the ceremony around unlocked packages. And then the other reason why we have source packages is that sometimes it doesn't make sense to unlock package anything at all. So, if you think about that reports, do you need to package them? That that's that could be a good question. Big UIs and Salesforce is is is fond of these kind of things. We are talking about single pane of glass and that kind of things. If you think about an account page that shows contacts, opportunities, cases, invoices, and all these kind of things, you realize that you are bringing dependency from a lot of different places, right? And the more dependencies you bring, the more time it takes to build an
[10:45] unlocked package. And that's the reason why we are saying those things. Actually, they are not called to the system. They are the single pane of glass on top of everything, and we can just go with source. That's fine. Because here, the problem is not. Sorry, just just one quick question. When you talk about the source package, that's specifically designed in the DX at scale tool. No, it's it's actually a capability of Salesforce DX, right? So if you if if you create a folder in Salesforce DX. And you say deploy that folder into the next thing. You are going to deploy that folder. The only thing that is missing there is what is the version. Of that of that source, what are the dependencies that this source has, so that I can install them before installing anything, and that's the thing that we have added on top of that. Okay, I see. I see. Yeah, so you also mentioned which is really a big pain is that, for example, the page layout, the profiles that pose the dependencies from all different angles. It was really a pain as to to retrieve that. Okay, absolutely. So back to your your question, and I think it was about the the DevOps challenges. If you have the right application architecture, there is no DevOps challenge.
[12:15] The the other challenge that that I saw before before we went into that journey is that we we had this separation between between building the application and deploying something right. Where usually you would go for one sprint and then build, build, build, build, build in your Dev Sandbox, and then you will try to push that to the next environment at the end of the sprint, right? And guess what? It's painful as well because we we forgot a lot of things. Even though this is smaller, we forgot a lot of things. And oh, that thing that we changed that day. Oh, yeah, I need to change that back again. And this is where. There is a mindset shift, also in terms of practices. So, what I'm saying to my teams is, the priority is not that the feature is working. The priority is that I can deploy my changes each and every time that I'm making a change. So I do a commit into my version control system. I run the CI/CD. I deploy to the next environment. At that moment in time, the fact that the feature works or doesn't work is not important for me. Right, because I'm going to test that to the next environment. In the next environment, the certainty that I have is I can deploy that thing. I'm certain of that because it's in the other one. I'm going to do the tests there. I would have tested before, right? But I'm going to do tests there. And if somebody finds a bug or change something, then
[13:46] back into Dev, I'm doing the modification because I'm sure that I can deploy that. I can deploy that to the next environment. And if I'm doing that each and every time. The moment where I have a feature that is actually working, I'm 100% sure that I can deploy that feature. This is continuous delivery. People think that continuous delivery is pushing to production each and every day. Continuous delivery, in my mind, is about pushing to the next environment and the environment that is the closest to production. Something that works, something that I can ship. Because the moment where the business says, "Yep, thumbs up," you can go to production. I'm already ready because I've done that each and every day. So, if you think about the exact scale again, the number of deployments that we are doing each and every day. Is more than 200. So we do more than 200 deployments a day using this approach, using this this open source tool. And we even have K Health and Ruslan talked something like a month ago about their experience and moving away from the happy soup into into this model. They are now able to spin up fully integrated development environments in a whim, instantly. Yeah, if we step back, you mentioned that it's more of the mindset to develop such a application architect. How we create the boundaries,
[15:17] but this thing has never been a case in Salesforce in the history. Let's say we did not have a package, we did not have namespace. We just put everything into the cloud, and it instantly works. So now we need to train the people to learn this stuff. It's difficult, I have to say. It's difficult, and sometimes people don't see the benefit because it worked in the happy soup way, and it continues to work. Why do old dog learn new tricks? Yes. So I think that the biggest hurdle is exactly that point: that the fact that people don't see the pains yet.
[16:00] But some of the businesses are seeing those pains, right? You probably heard about this tension between the business and the IT, where the business wants new things and the IT is not able to deliver at speed. Oh, so much, yeah, and that's the reality that we have, right? Yeah, I think that we are doing that to ourselves. I'm not talking about small Salesforce implementations, right? There are times where if you are just a very small business and the only thing that you are using is Salesforce out of the box with few reports, everything that I'm talking about, I mean, don't even bother. But if you if you have if you are investing in in CRM in Salesforce as your your CRM platform and it's and it's part of your A business strategy. Then you need to be serious about that platform, the same way that you are serious about your website, about your backend systems, and everything else. So, biggest hurdle number one: feeling the pains. And I think that most, and more and more businesses and customers are feeling those pains. The second one is, I think the fact that people think that Salesforce is different from other technologies. Salesforce is no different than other technologies. It's software. It has exactly the same limitations. It has exactly the same rules. It has exactly the same behavior than than any other technologies. I'm going to give you an example.
[17:33] Everybody thinks about SOQL queries like something new, right? It's
[17:39] absolutely absolutely amazing to have to be able to write a query into a language that is object oriented and get that into an object that you can manipulate. Ruby has been doing that for years. Java has been doing that for years. It's called Hibernate. It's called Active Record or that kind of things. It's it's exactly that. What is different though in the Salesforce space is if you are coming into Java, if you are coming into Ruby and Elixir, you are coming from a coding perspective. So you are writing code. If you are coming into the Salesforce space. Because there are a lot of different ways to configure and customize Salesforce, you can either use code, or you can use flows, or you can use workflows, or validation rules, or these kind of things. And most of these capabilities that Salesforce is marketing around. Are neat, very neat. I'm not going to argue against them, but they are just another way to implement something, but that hides you, and that discards all the complexity behind flows. If you think about flows, for instance, what is flow? It's just a graphical way to write code. Right, right. You can achieve exactly the same thing in Apex as in Flow, but because you don't see the code, you don't see the intricacies and the consequences of what it is that you are building, and then you end up seeing
[19:09] flows that are screen pages long, and you can't understand them anymore. Where if you had an Apex class and an Apex method that has one thousand lines, you would look at that class and you would say, "Oh, there is something wrong there. Why is it one thousand lines long?" And I bet that if you go and check some of the Salesforce implementations around you, where you have a lot of pains, and if you look at some of those classes, you will find those classes with methods that are one thousand lines long. And this is where we go back into the software engineering principles, and I think that you had Uncle Ben right invited to your your podcast, and you talked about clean code and boundaries and all these kind of things, right? And that's exactly that. It's solid, right? Separation of concerns, inversion of responsibility, dependency injection, and then once you have those. Those things grounded in you, then you realize that one, you can do two hundred deployments a day. Two, when you are fixing something, it doesn't creep into another place. And three, because your system is designed. To change, when the business comes to you and says, "I want to change this," then you can change that quickly, and you can deploy that quickly because you know that you can deploy each and every time. Hmm. I don't know if I'm making. Yeah, I understand
[20:39] your point here, and also I like the idea that you open it up. And Salesforce indeed is another platform. The challenge that I typically see is that because Salesforce is a low-code platform, it has the flow and other configurations. Things are not directly compiled into a byte code. It's not the machine code. Let's say when our code finally put into the platform, what we see as the developer is the XML file for a lot of metadatas. Yeah. So those things are different. Sometimes it's tricky to move from one environment to another. I think definitely you have seen that, right? Yes. So that's one of the other challenge that you have in in DevOps, right? So, and this is another of those conversations that I'm seeing online where where people are talking about Git being hard. You probably heard this conversation as well, and we are saying admins for the admins. It's hard to to learn Git. I've had dozens of functional consultants, so the same kind of skills that an admin would have, and each and every one of them has learned, never seen Git in their entire life, and they were able to. Use it as the tool that they need to use in less than two days.
[22:09] It's, I mean, it's Git in it, Git add, Git commit, right? So the in it you never do that. The commit that's the easy one, even though you need to have some meaningful messages. The Git add, and to your point, is exactly the problem. When you are writing code in JavaScript or Ruby, let's say Ruby on Rails, right? You change a Ruby file here. You change an ERB template over there. You know exactly what is the file that you have modified, right? You know that because you modify them yourself. The moment where you create a profile, you change your layout. Salesforce does the magic behind that, right? And this is where, and this is where you need to understand. And that's the next level, right? That's but it comes with with practice and and that kind of things. Those XMLs and that could be overwhelming to get there. So few tricks there. Yeah, tiny steps, very tiny steps. So, for instance, if you, if you want to create a new field. Salesforce gives you that flow or guided flow where you create the, you select the type of field, you create the field, and then it offers to actually add the field to the layout, to the profiles, and all these kind of things. What I'm saying is, don't follow that flow. Just create the field, and stop there. Retrieve your modifications. Make sure that you have them in another place. Commit. Take the next step.
[23:39] Add that field to the permission sets, and do one permission set at a time. People are overwhelmed because sometimes when they are getting all the changes that they have made into the platform, they are seeing thousands of files, hundreds of files, and it's very hard for them to understand that. And everybody would be confused. So the thing here is go extremely tiny steps, one step at a time. What is it that you want to do? Add a field. Just add the field. Commit. What is it that you want to do? Enable access to that field for that permission set. Make the modification of that permission set. Commit. What is the next thing you want to display? That field on the layout, that specific layout. Make the modification, retrieve, commit. The good thing about following this process is. Is extremely repetitive, right? And you can be sure that the only thing that you are getting are the things that you have changed. Sometimes we are trying to make two big leaps. We need to make tiny steps all the time. I think this is also part of the DevOps concept: is the fast feedback loop, right? And also in Salesforce, we have the scratch work. We we create the field in the scratch work. We pull it down to our local. We see okay, what metadata files it changes. You learn that, and then you push to a new scratch work.
[25:10] You can't rinse and repeat. And until you are really confident, okay, these things I have full control. Then I would absolutely, absolutely. So the the other thing in in terms of coding and and that kind of stuff. And that that talks to the to the modules, right? So when you are looking at triggers, for instance, one of the best practices that Salesforce is pushing for, and they are right about this, is you need to have a trigger handler that is going to send that to different services. And that's what you will see in most of the Salesforce implementation. You will have a trigger handler that is going to dispatch your message to trigger handlers. And this is where the problem starts. Open a trigger handler, any one of those, and what you will see is one a bunch of static methods, two business logic intertwined with SOQL queries. You've seen that. Of course. Okay. So, what do you have when
[26:16] you have this? One, because you are using a static method, you can't use any. Things that are related to object orientation. You can't use polymorphism. You can't use instantiation. You can't use interfaces so that you can mock or change the behavior at run times. So that's one problem. The second problem that you have is you are intertwining business logic, which is a higher level. Of concepts, with SOQL queries, that is a lower level of concept. So, for instance, the fact that I'm storing my case in the case object. Should not be a concern of my business logic of on how I'm dealing with complaints. Okay, complaints are stored as a case, but if I want to store them as opportunities, I should be able to. I'm not going to do that, right? But from a business logic perspective, the fact that I'm storing that complaint into that object or that object is irrelevant because I want to be able to change. That logic. So the way that we we are dealing with that in terms of software engineering is this is pretty well explained into Andrew Fawcett's book around how to properly architect an application. He's talking in terms of domain driven design. If you will, and boundaries, and and all these kind of things. So you have the application, you have the service,
[27:46] and then you have selectors, and then you have data access objects, and all these kind of things. And all of these things are integrated. Together through a contract, and that contract is usually an interface. Thanks for sharing this this information, but I see. Things from different angle. I I enjoy the conversation, but if we go a little bit deeper on this topic, is that this is not only DevOps related thing. This is DevOps plus the developers. So if the code is with better architect, better quality, faster unit tests, things can be dependency injected, can be easily swapped out. Then it's easier for DevOps engineers to deploy. So it's it's a win-win in different angles, but. It's just a huge topic, right? It is, it is. But in my world today, my DevOps engineers do not do deployment.
[28:57] Okay, what do they do? They build the tools to make my pipeline more efficient, and the people that are in charge of the application have the tools that enable them to deploy. And this is, I think, one of the misconception in the Salesforce space. And I need you to hear me out here because I think this is critical that that we understand that you have people that are building an application, right? They build the application. They hand that over to a team that is called the DevOps team, and the responsibility of that DevOps team is to deploy that application. Does it ring a bell? Yes, I I see it quite often. You see that each and every day. My problem with that is the people that are responsible for deploying the application have no idea what the application is doing. They have no idea what the application is, how this application is structured, and they have the responsibility to deploy. So that's a problem. They typically get like a KT session, right? Ah, what do you did? Train me for an hour in a meeting. Show me what it is, and that's it. Yes, but you can't do KT in one hour if you have worked for six months on something. So that that's one of the misconceptions I think in the Salesforce space. DevOps is about you build it, you deploy it, you operate it.
[30:28] That's what DevOps is about. In the Salesforce space, DevOps is about a team that is going to deploy something. What I'm saying is, if you have the right approach, the right tooling, the right platform engineering, and this is what the Salesforce scale is about, then the people that are in charge of the application are going to build a modular application, and because they have the tools to support the deployment of those capabilities. They only need the DevOps engineers when there is an issue with the tool that they are using, or if they need another feature. Yeah, I want to talk more about this mindset shift. To me, learning all these things as a software engineer is interesting. It intrigues me. Like at the beginning, I learned Git. Okay, version control. Why do we need a version control in this? Right, we started that. And then why do we need DevOps? What benefit it brings to me? Okay, automation, faster feedback loop. But I also see there are people as Salesforce developers. They don't learn these things. I even see today there are people using the Dev Console to change the code and then deploy to Salesforce. It's not easy to convince people to move, as you mentioned. It's not easy, but it doesn't mean that we should give up. Ninety nine percent, ninety nine point ninety nine percent of the people that you are going to meet in your life want to do a good job. I'm pretty sure it's 100
[31:59] right. I'm convinced that that's the case. They are doing things because they. I think they they never been exposed to other ways of doing things, and nobody told them. Hey, if you do that small thing that could improve what it is that you are doing, most of the things that I have learned were actually people looking at me doing something and saying, "You know that there is a more efficient way to do that." And slowly you you get there, right? So that's one part where improving the processes should be key. The other one is, and that's one of my big rants as well. The business wants something in two weeks. We know that if we want to do that the right way, it's going to take six weeks. And I'm not even talking about technical depth, right? And we we can't stand behind those six weeks and say no, you're not going to have what it is that you are asking for in two weeks. So, let's have the conversation on: are the two weeks something that are critical, or are the features? And if features and timing are critical, then one thing that is going to happen is we are going to take a lot of technical depth just doing that, and we are not even sure that we are going to hit those two weeks, right? So, if the goal is to hit the two weeks, then you need to give us at least four weeks behind this to kind of reengineer, refactor what it is that we have
[33:29] built, because. If we don't do that, then this is going to slow us down as as we go. One thing, and I'm always trying to find images around this, right? So, do you cook at home? Yes, I do. You clean your kitchen each and every time, right? My girlfriend does that.
[33:53] Yeah, but yeah, there are people doing that. Why? Why are we doing that? Just to prepare for the next time, right? If you don't clean it, it's just a mess. Exactly, and and that's exactly my point here. It's you can take shortcuts and that kind of thing. Shortcuts are going to hit you back any time. So. And this is one of the, and I'm way beyond the DevOps here. I mean, more in the lean kind of mindset, the continuous improvement, the fact that we have exercises, and they call them kata, right? The fact that we deploy each and every time. At the end of the day, we we just train our muscles, we train our brain. This is fitness for software engineering, right? And I think that Uncle Ben has called his software fitness. I don't know, probably for that reason. Hmm. I think we talked a lot these things. I would kind of summarize DevOps. It's not just DevOps in its name. There are so many things we have touched, and they are associated. To me, is that there's a lot of things for a Salesforce developer to learn. You mentioned Git. You mentioned all this: how to write good code, how to have a fast feedback loop, and also we have to learn this. DX tools, scratch works, all these new things that Salesforce gave us as as a tool. So, it's not an easy job as a Salesforce developer. Pretty much all the concepts that I have learned in engineering school
[35:23] are still valid. Today, they haven't changed. The basic principle around how to write good software hasn't changed in forty years. Now, the technologies that we that we are using they're evolving, and that's that's the nature. But if you have the strong concepts, you can pick up anything. Hey, you started learning Rust. Yeah, you you saw my message. Yeah, I saw that, except the syntax and few things like the option and the other one, the result or that that kind of things, which is some kind of pattern matching on, on what it is that the result of your your query was. Pretty sure Rust resembles all another language. I don't even know if Rust is functional or object oriented or kind of. It's it's in the between. It brought me back the joy when I was a computer science degree students. Rather than only the high level things, I can go a bit deeper. That's interesting to me. But I think that Salesforce is its own ecosystem. The best Salesforce developers that I have seen are people that are that have that Salesforce skill set. As part of another set of skill sets, so the people that I know that are extremely good, right? They have
[36:53] they're already extremely good when it comes to Salesforce, but they they understand Go, JavaScript, TypeScript, Ruby, Elixir. They understand Docker and the containerization thing. If you are Salesforce developer, the concepts that you are going to see on the platform are concepts that already exists somewhere else. It's probably easier to understand those concepts. Using those languages and other ecosystems because they are lighter, and then you can reapply them into into Salesforce. When you understand that a SOQL query is just an ORM. And I'm kind of exaggerating here, but Salesforce. What is Salesforce? It's a huge database, essentially, with a virtual machine on top of it. That's that's what Salesforce is about. But it does amazing things, right? It runs business. Thanks, Ramzi, and it was really good to discuss with you. Before let you go, would you like still quickly introduce your DX at scale? Yeah, thank you for that. By the way, thank you for for having me. I don't know if I went off track or not. This is something that I'm really passionate about. Yeah, it's totally fine. Like I said, the XSL is open source. Will stay open source. I think that you are going to add the link in your yes in my show notes yeah yeah. So we we have a model that we think enables this compose what Salesforce calls
[38:24] composable ability right. We call that modularization. Now the next stage for us is to actually help people moving from the happy soup. Into the composable modular way of doing Salesforce implementation, so that's one of the aspects I talked about. The fact that we we want to share more information. There are a few things that are moving on from that perspective. So stay tuned in. It's open source. There is a community. We have one person on average that is joining us today. So welcome. And yeah, if you have any questions, any time. Thanks, Ramsey. I will put your LinkedIn information, DX at Scale, and you have a Slack community as well, right? Yeah, absolutely. So I will put all this information on show notes for our listeners to check. And definitely, it's open source. It's a free tool, and we have great people behind it to support us. So absolutely. So the team now is probably eight core maintainers. So we are growing. Thanks a lot. See you next time. Yep. Bye bye. Bye.
