EPISODE 1603

[INTRODUCTION]

[0:00:00] ANNOUNCER: Frédéric Harper is the Principal Developer Advocate at Kubefirst, which is an open-source platform that integrates some of the most popular tools in the Kubernetes space. Frédéric has deep experience at major software companies having worked at npm, Mozilla, Microsoft, DigitalOcean, Fitbit, and others. He joins the show to talk about the challenges and solutions for working with Kubernetes.

This episode of Software Engineering Daily is hosted by Jocelyn Byrne Houle. Check the show notes for more information on Jocelyn's work and where to find her.

[INTERVIEW]

[0:00:43] JBH: Welcome, Frédéric. It's really great to have you.

[0:00:45] FH: Thanks for having me.

[0:00:47] JBH: Tell us a little bit about how Cubeshop into Kubefirst.

[0:00:51] FH: I've been in tech for just a little more than 20 years now. The first half of my career, I was a full-time software developer. Actually, it's not totally true. I was mostly a full-time software developer, but at some point, I'm an H team. I'm an H project. I did some architecture, customer relationship. I would say, always, 80% to 90% of my time was creating software. Work with mobile development, standalone development, web application, with multiple technology. I realized that as much as I love coding, and to be honest, I mean, in my role right now, I miss coding full-time. But I'm a social, extrovert person.

Yes, I was working with team when I was a software developer. I was working with some customers, but I need to be with people more than just those small amount of time. I switched to a more social role, where I still have to own my technical skills, but it's really about people. As I said, my job is to help developers. Part of my job is to create YouTube videos, is to participate to podcasts like yours, is to speak at conferences. It's always about technology, or tips and tricks that can help, again, developers be successful, save time, do maybe sometimes a better job, improve their skills. It's a great mix between, as I said, my technical skills and my social skills.

I've done that in a couple of places, like really big company, medium-sized company, small startup. Right now, it's going to be a year in the month or two. Time fly when you have fun. I'm part of Kubeshop, but you're going to see me advertise Kubefirst most of the time. Kubeshop is a startup incubator, but not like in a traditional sense. We have projects that are in-house. Kubefirst got acquired about a year ago from Kubeshop. I work for Kubeshop, and we have other projects that are mostly related to the Kubernetes space, but my main focus is 100% on Kubefirst at Kubeshop. It may be a little bit, like people, "Where do you work? Kubeshop or Kubefirst?" I mean, my employer is Kubeshop, but I spend most of my time on Kubefirst.

[0:02:55] JBH: Kubefirst is a loose assembly of city-states that form one ecosystem. Is that right?

[0:03:02] FH: It is. It is. What do we do, is we offer a tool that helps you to create Kubernetes cluster by respecting the GitOps principle. We create full-fledged, production-ready Kubernetes cluster with the tools you need. Cloud Native tools that really helps you to be productive.

[0:03:18] JBH: Interesting. I want to talk a little bit about that. Let's talk a little bit about what Kubefirst is and what problems it's solving. Then I want to go in a little bit deeper on some of those solutions. I just actually copied this down. Kubefirst principles. I'm going to read this out loud. You ready? An open-source GitOps-driven, Kubernetes-centric infrastructure and application delivery ecosystem. That's a mouthful.

[0:03:46] FH: Actually, that is like, we just put all the keywords that make sense about Kubefirst in that one longer sentence. It translates into the fact that if you use Kubefirst to create your Kubernetes cluster, you can use the CLI. We have a UI installation tool. It's going to create your Kubernetes cluster with the tools you need. It's going to install Argo CD, HashiCorp Vault, Terraform, Atlantis, and it's going to be installed for you.

Instead of creating an empty Kubernetes cluster where, okay, it's fine, that's the easy part. The next part that is a little more difficult is to have all the tools, management tools you need to have a functional cluster, where you're going to be able to deploy your own application services, or tools. What do we do? It's an open-ended platform. We decided some of the technologies that we think would work well together and that we had to be frank, that we had experience with and we put them together. We made it easy.

For a company, instead of spending, if you really have a huge expertise, it can take you even days to set up, to create that setup. If you don't, it can take you weeks, or months. Now, the difference is that you can use Kubefirst and you can create your cluster, like full production-ready cluster on AWS, DigitalOcean, vulture, SIBO, Google Cloud, even locally create your cluster. It's going to take you between five to 25 minutes. As I said before, creating a Kubernetes cluster is not difficult. It's the part that come after, and this is what we tackle with Kubefirst.

[0:05:16] JBH: I want to talk a little bit about that, because it would be difficult for me. I'm a little bit out of my depth on this, but I have had a front row seat for the challenges that enterprise has with Kubernetes in terms of trying to onboard new solutions, or work with startups who want to distribute their product more broadly in Enterprise. Let's back up, though. I'm sure most of our audience knows what Kubernetes is and why companies like to use it, but let's just cover that for a moment.

[0:05:41] FH: It's a tool that helps you to create a distributed platform, and it really helps you to scale your application. Compared to, let's say, traditional cloud when you're going to deploy your application, deploy your services on the cloud, you're going to deploy your application on a Kubernetes cluster, and that's going to open up to a lot of tool sets that's going to help you to manage and scale your application. It's a project that was created for Google along a couple of years ago. I'm not quite sure when it was created. It's at least now about 10 years. They decided to open it to really give back to the community.

It was built for larger type of issues, like when you really need to scale things about Google type of issues in terms of scalability. It's more and more available for smaller player, people that want to scale and that want to use the latest and greatest technology out there.

[0:06:37] JBH: Yeah, it scales, and then the dream for enterprises is that it breaks up any monopolistic dependency you might have on the big providers, right?

[0:06:46] FH: It's the goal. There is also a caveat about that, because like most clouds right now, at least the biggest player, and even the small player, they now have a Kubernetes offering. In theory, you wouldn't be vendor locked in. That would give you the opportunity to have an architecture that consider Kubernetes when you deploy your application, your tool, or service.

Some clouds right now, the way they configured Kubernetes, the way you create your cluster, the way you use their own services to bring your cluster to the next step, sometimes you can be stuck a little bit with some vendor locked in.

[0:07:21] JBH: They have eccentricities that are specific to the provider.

[0:07:24] FH: They have. They have. Good opportunity. Which could be not always time effective, or it could be a little bit more costly is to try to implement the cloud provider's services yourself within your cluster, which would make it more portable. This is also one of the adventures of using a tool like Kubefirst, because we use cloud native, open source 3, open-source cloud native tools that we install in your own cluster to sometimes replicate some of the feature of some cloud provider, which prevents you to be vendor locked in.

[0:07:55] JBH: I think that's part of it, right? If you are an enterprise, you want to scale, you want portability. Then the other thing I've seen is for enterprises who want to adopt new technology, or work with younger companies, most younger companies are creating their first install packages on Kubernetes.

[0:08:10] FH: It is true. I was working at DigitalOcean at some point, which is a smaller player in the cloud provider space. But they had our Kubernetes offering. Part of my job was to talk. My focus were startups. Every startup founder that I was talking to, either technical founder, or non-technical founder, maybe CEOs, they all wanted to put their application on Kubernetes, because they were like, "Hey, that's the future. I'm going to be the next Facebook, and I'm going to need to scale."

People want to use that technology, whether it's useful or not for them at that stage. It's not always easy, because it really shipped the paradigm from the traditional DevOps space to a new space that you need to learn. This is also one of the barriers to entry that I personally think about Kubernetes that that's a wonderful technology. It's not always easy to start to learn that new technology, because now you're talking about like, there is pods and there's that new thing that is a cluster. You need to understand, if you want to do GitOps, you need to understand the principle.

Now there's a new set of tools that you may want to use that are creative for their cloud native space, Kubernetes space that you may not have been used before if you were doing DevOps. The barrier to entry can be a little bit steep when you move to a cloud native technology.

[0:09:30] JBH: It's definitely steep. Then in large companies, the most talented, most experienced engineers who are doing this type of setup, they're in short supply and it's hard to spare them for something like this. They're already working on the hardest problems.

[0:09:44] FH: It is. It is.

[0:09:46] JBH: Also, talking about talent, you talked about using the most popular tools. If you wanted to extend, or expand your Kubernetes commitment and you wanted to hire the right people, the fact that you you're focused on vanilla open source, or unalloyed, true open source has been a benefit, right? Because more people know it, are part of it. I know that's one of your principles. Then you've got some other principles, I thought we'd just chat through if that's okay.

[0:10:13] FH: Yeah, yeah.

[0:10:13] JBH: Because to me, that's leveraging the most popular tools when you say you're open source. Is there something else I'm missing there?

[0:10:21] FH: There are what we think are the most popular tools. Sometimes, like it's gone from with surveys, or from CNCF. Sometimes we may disagree with some people in the community. One of the questions we often have like, "Oh, why are you not using flux CD, instead of Argo CD?" It's because when we started to create a platform, Argo CD had that UI that we thought could be useful for users and flux at that time didn't have. To be honest, also, it was a tool that we've known and used before.

The founder went also with the tools that they felt comfortable. It's still a popular tool out there. I think it's one of the most popular tool out there. I still want you and phases that Kubefirst is an opinionated platform. Often, we have discussion with our community users where like, "Oh, why did you choose tool X, instead of Y? Or why did you decide to use that tool compared to the other tool?"

Again, we try to go with the more popular option, but we also have our own decision to make about the platform. What's best for the platform we're building and what we think is going to be best for users. So far, except some discussion about like, I would say, people that are a fan of other technology, usually we can have a pretty good discussion order users and basically, just let them know why we made that decision. Usually, people agree with those. So far, so good. Pressing your finger. I think we made the right choices.

[0:11:46] JBH: Yeah, that's right. It seems to be. The other thing I wanted to just dive in with you a little bit is easy platform provisioning. When I hear that, it's sometimes a little bit of a red flag when you come from super complicated enterprise environments. I also raised my eyebrow a little bit, because maybe I don't understand it as deeply as I should. I just thought I would ask you a little bit about, just at the high level, what makes platform provisioning easy or difficult?

[0:12:16] FH: Before answering your question, if you let me just had on what you said. I totally agree. I mean, when the manager of developer relation at Kubeshop reached out to me for that role, and I went on the website and I saw the exact same sentences that you read. I was like, "Nah, that's bull." Not to say all the right word. I was like, "No." I mean, it's complicated. Not that I don't believe in an easy solution, but usually, it's a little bit too marketing-ish, and it's not true.

I tried it for myself. I was like, "Oh, my God. They're right. They're doing it." The good thing about easy versus difficult is that with our platform specifically is that we made it easy for you to create that cluster. The thing, though, is that if you have a certain experience and expertise, you may, again, you may not like the tools we choose, which, as I said, so far so good, but like, hey, you may like not them. The thing is that you're not stuck with everything we put there. It's your platform. Once we create the cluster, it's yours. Because we respect the GitOps principle, we have that GitOps repository, where everything is declared there, so it's yours. You make it yours. If you're not happy with us using vault and you want to change for something else, go for it.

If you want to remove something we installed, like we installed, example application call Metaphor. You want to remove it because you think it's just cluttering your cluster, it's just adding some clutter, you remove it from your GitOps folder and you sync Argo CD and you're good to go. It's not there anymore. That's the benefit of we get you started. But if it's not exactly what you want, you can update, change it, remove stuff, add stuff. The goal is really like, we kickstart things for you and it's up to you after to do the rest of your magic.

Yeah, the difficult part, just to finally answer your question is that we made it easy because with either one common line, you can create that cluster with all the tools and plus even more tools than the one that I mentioned before. All interconnected in between. They're all working together already, so you have those tools with one common line where you put a couple of flags about which cloud you're going to - you change a comment depending on the cloud. If you want to use GitHub, or GitLab as the place where we're going to create your GitOps repository. You've changed a flag, but it's one common.

Depending on the cloud, you wait between five to 25, 30 minutes. Let's say, it takes more time to provision, because includes a lot of services. In the end, you have your cluster with all those tools working together, but you can also do it with a UI if you want to. It's a couple of clicks. You wait the same time after that and you got your cluster provision. The difference is that it's not just about installing the tool. The difficult part is not just about installing the tool. It's about making all them work together. Making all those tools work together.

As an example, you have your GitOps repository. If you want to add a new user, you can pat, or let's say, you want to add a new repo, you go in a Terraform file, you had a new repository that's going to be managed by the cluster. If you want to have new users, you can go on vault. You had your new users and that new users are going to work in Argo CDs, is going to work in all the tools that we installed. Everything is tied together. I would say, I'm not the engineer who worked on the code, but I would say, it's the difficult part to do. Adding all those tools work together.

[0:15:36] JBH: I know you work with developers for the most part. This is a question I often ask. You've got such a heavy emphasis on open source. There's really no delicate way to put this, but help me understand the difference between what's open source and what you guys and then how do you charge for that?

[0:15:49] FH: Right now, we're not charging anything. We're a startup. We're still at the stage where it's free, it's open source.

[0:15:57] JBH: Everyone hear that? just call them up now. Now's the time.

[0:15:59] FH: This is a good time. Actually, to be honest, that's going to be a good time also in the future, because we still believe in open source. In the future. It's a big if. We are actually discussing how we're going to monetize the platform right now. That's probably going to be a mix of part of the platform is going to be free and maybe, are going to be able to create X number of cluster, but that's the Y number of cluster. You may have to pay a fee.

[0:16:25] JBH: I get. There's some throttle.

[0:16:27] FH: Some sort of throttle.

[0:16:28] JBH: A following product that makes it enterprise, or some fancy enterprise. Extra services.

[0:16:32] FH: Exactly. Exactly. Another possibility is to have most company, or many company does, like they have open-source feature and they have enterprise level features. The thing though is that everything we have right now in our open source, or GitHub repository, it's free. It's there. It's open source. That's always going to be there.

[0:16:53] JBH: All right, you heard it here first. Get in there and just get [inaudible 0:16:57].

[0:16:57] FH: Yeah. If something changed, you know what? You can point to that video and say like, "Hey, Fred said that." The good benefit of working where I work is that the Kubefirst thing really believe in open source. The goal was to open source that tool right from the beginning. We're big users of open source. At some point, we need to get back to a community also and like, it's our way to do that. Also, we need to be realistic. We have salaries. We're a for-profit company. We need to make money at some point.

Now, we reach a point where we feel like the platform is production ready. People can use in production. It's solid. It have all the features that we wanted for, let's say, the first real, big, nice full-fledge version, it's out there. Now we're like, okay, now we need to start to think about making money. But we're an open-source shop. As I said, there is still going to be a lot of open source when it comes to Kubefirst.

[0:17:50] JBH: Well, I love that. I think I told you the last time we talked, I'm an open-source hippie from way back. I worked up early in the Linux journey. I worked for a company that did support for any distro. That didn't work out as a pure support model, but it's an interesting line to embrace between keeping an open-source project alive and vital. Also, supported. I think now, 20 years later, you definitely need to have some monetary component to that. People aren't just spending their nights and weekends.

[0:18:19] FH: Exactly. As much as I love what I'm doing at Kubefirst right now, I also love getting a paycheck.

[0:18:24] JBH: Right. People have to eat.

[0:18:26] FH: Yeah, exactly, exactly. Enterprise support is also an avenue. It's already something we're doing with some enterprise, like people that may not have the resources of time to manage their Kubernetes platform and need expertise to understand a little more how to get started. Because as I said before, you can do it with Kubefirst. But to be honest, you probably want to understand the tools, so we can also help people to do that. We have an expertise with those technology.

[0:18:52] JBH: As a people business, it doesn't necessarily scale perfectly. But I think especially for what you're doing, which is so much more than just an operating system, right? I can't believe those words just came into my mouth, because operating systems are a lot. Support, training, those type of things, there's a huge gap. You could spend all day every day on it. Not that you should.

Then, of course, I'm sure you guys are already talking about the woeful lack of tools to monitor and understand the performance of your Kubernetes clusters inside of a large organization. What it's costing you, how it's working, where it's breaking down anomalies in the telemetry, all of those things are really not visible to most organizations.

[0:19:33] FH: Yeah. What I like also is that there is some - it took within the team, and I know probably every company say that, but we gather some telemetry. It can turn it off, and we anonymize the thing. We got the minimum information we need to take decision and see if the platform is working, because especially, I would say with any software, but I would say, especially with open source, you're going to have users going to be really vocal about like, "Hey, your tool is not working. This is the issue I have." But some people would just move to the next thing.

If you don't tell me the like, you have a bug and they have an issue, because no product's perfect, there's no way for me to improve, or maybe for whatever reasons, our team never had that huge case that caused that problem, and may never have. If you don't tell us, we don't know. We have some metrics when people are successful or not, and that really helps us to say like, "Hey, okay. Maybe this cloud in this particular scenario is not working super well. We need to look a little bit deeper to see what's happening."

[0:20:30] JBH: Interesting. I know it's early days and you may have only just started to engage with some big customers, or potential partners, but how are you envisioning adoption working in large organization? I guess, I should say, I think it's what you're doing is for large organizations. I keep saying that, but maybe for any business, or any buyer, how do you see this working its way into the organization?

[0:20:50] FH: It is a product for any type of organization, for the main reason that we made it easy for people to use. If you're a startup and you really don't have the knowledge, you can create your cluster with all the tools that we offer to you easily. Even if you're a small company, it's perfect for you. Obviously, you're going to rip a lot more benefit if you are a larger organization, because it's about saving time, it's about saving resources. You're probably going to need a lot more clusters, which means a lot more time, which means a lot more expertise, which means a lot more resources. If it's managed well, we can help you to save in resources. Sorry, what was the question? Sometimes I just go in all the direction.

[0:21:29] JBH: No, I asked you at the same time, kind of. That's my fault. I was just thinking about a big, like a company. Where do people start learn about you and start adopting you? Is it developer up into the organization? Is it cloud engineering at the top level, pushing it down into an organization? You may not know, but what do you think is going to be the way that the set of services works its way into the org?

[0:21:51] FH: Actually, what we're seeing right now is a mix of those. There are developers that want to rip the benefits of using cloud native technology. At the same time, it's not their expertise to be devops. They're developers, their expertise is to create software. Not that it's better or worse. Your expertise is to create software. Focus on what you do best and where you can bring the most value. There are developers that just want to go cloud native, use Kubernetes. They don't really know how to do it. They're like, "Hey, we're going to try Kubefirst and see what happen." They can focus on what they do, developers.

We had cloud engineers. They're like, "You know what? I've been building that at the previous company. I'm at a new company right now. I don't want to spend the next weeks, months, years to build the exact same thing that I did before, and that you're offering for free. It's open source. It's easy to do." We also have decision-maker, CEO. Sometimes it goes from top to bottom, where they're like, "Hey, you know what? We either don't have the resources, or we don't want our resources to focus on that." Because it's important to have the proper infrastructure that can scale, but it's a tool that's going to help you to put your product, or tool, or services out there. That's not what's going to bring money. That's going to be a tool that's going to help you to put your things out there. This is what you're going to put out there that's going to help you to make money.

Some decision-makers are like, "Hey, we're not going to spend time on this, if there's an easy solution to do that." I don't have a crystal ball. I think that's going to be a mix between the two, stakeholder, decision-maker. It's going to be like, "Hey, we won't focus on building an expertise in cloud native, but we need it if we want to compete against other people in the industry," and a mix between also, cloud engineers, or even developers of like, "Hey, you know what? I don't want to spend too much of my time doing that. There's a tool that let me do easily, or that at least, get me started." If it's not the end point that you want, that's a tool that helps you to get started. Don't come back on me on this in six months, or a year because again, I don't have a crystal ball, but I think it's going to be a mix of those two. This is what we're seeing right now.

[0:24:01] JBH: It's copious notes. If you're wrong, you need to find it.

[0:24:04] FH: I know, I know. I'm in trouble now.

[0:24:07] JBH: Kubefirst, right, is this core part of the overall Kubeshop portfolio, right? Which includes monocle for configuration analysis, test cube, native testing framework, tracing, open telemetry trace, which you just talked about and API gateway. Am I missing one? I don't think so.

[0:24:26] FH: Yeah. You cut out a little bit, so I'm not sure. Yeah, there's monocle, test cube, trace steps and Botkube and kusk.

[0:24:33] JBH: Botkube.

[0:24:34] FH: Yeah. Other entity is Botkube.

[0:24:36] JBH: You might not be able to talk about it, which is fine, but is there a gap that still needs to be filled here that either you're planning in a new release, or maybe another company offers there in terms of capabilities? Is there a capability gap there?

[0:24:50] FH: You know, I think Kubeshop right now has a pretty good offer, because we cover from creating your cluster to testing your cluster, but not just your cluster, also your code, too. Also, linting and having more information about your cluster to the management part with Botkube, where you can manage your cluster, and get information of your cluster, whether from Slack or Discord. Just an easier way to have access to your infrastructure. I think the offering is pretty good right now.

I don't know if there is other project coming, to be honest. I don't know what's next for all the projects, but I know, I can say that for Kubefirst, it's only the beginning. We're continuing. We're growing the team right now. The thing is that we have passionate people. I think it really makes a difference also. Not just passionate people. We have people that had those issue and had enough experience to want to solve problem that they have before. Jared and John, Laura the founder of Kubefirst. As I said, they got acquired by Kubeshop about a year, so now we're part of Kubeshop.

But they wanted to replicate a little bit of what they've done at a previous job, where they spend months to basically have that production-ready cluster. They were like, there is no way that every company has to go to that process. It doesn't make sense for us if we change job. We have to start again all that process. Obviously, it's going to be faster, because we get that expertise. We get that experience. But still, it's going to take time. We're like, no, no. We're going to create a solution that can replicate that process easily and fast and without too much knowledge.

[0:26:26] JBH: Interesting. Yeah, that's helpful. I should know this. You guys, you have a pre-product, or pre - your product is out there and you've got users. But from a business perspective, you haven't launched yet. Is that right?

[0:26:40] FH: I mean, it depends. If you mean by business, I like making money side of things. No. Right now, we're working on - we're in big discussion around that. We have a plan where we're going and it's in motion right now. We're introducing slowly from 2.0. We introduced some features that helps us to reach the point, where soon, we're going to be able to offer multi-cluster. Because right now, the limitation with Kubefirst is that you create one cluster and you can only manage one cluster, which is not super helpful for medium to large enterprise. For many people, it's enough.

The main feature that our users are requesting in multi-cluster. We're going with that. As I said before, it's one of the avenue we have right now for monetization. I would say, before the end of the year, we should have an enterprise offering.

[0:27:29] JBH: I'm so surprised by so many organizations that say they're doing - they're focused on enterprise and they don't have a multi-cluster feature set. I find it surprising.

[0:27:37] FH: Yeah. It's why until now, we're like, no, there's no way we monetize. We wanted what we call the Kubefirst quality level, which is like, hey, we wanted to have product that is solid. Not bug free. I don't believe there is any product out there bug-free, but good enough that it's production ready. We've got enough feedback from the community to know we are going in the right direction, from users to know we're going in the right direction. Now the next step is like, okay, now we have a solid foundation, let's move toward sustainable solution for Kubefirst and Kubeshop.

[0:28:11] JBH: That could be the shout out here. Any listeners who work for Fortune 500 company who would like to be a design partner can call you up, Frédéric, right?

[0:28:19] FH: Yeah. Yeah. Actually, we're really open to any type of feedback, good, bad and ugly feedback, as long as it's respectful. This is the only way we can improve ourself and be sure that we're going to provide the feature our users want.

[0:28:32] JBH: Wow. It's like, you're true blue open source. I like that. Let's switch gears a little bit. We've got a few minutes left. I always think it's interesting for people to understand your journey a little bit more, especially because you are a developer advocate. You already said, you moved from being a full-time developer into a developer advocate, because you wanted a little bit more human contact and you like talking to people. When you think about hiring developer advocates, what types - let's say, there's developers in the audience right now who are thinking, "Maybe that's for me, but I'm worried it won't be technical enough." If you were interviewing someone to be a developer advocate, what would you look for, or would you steer clear of in their profile?

[0:29:14] FH: When it comes to developer relation, or developer advocate role, or sometimes it's called technical evangelist, or technical developer, it's basically, for me, the soft skills for that role that you usually see for any type of role. They're the hard skill. Obviously, when I was hiring a developer advocate, I want someone who has developer experience for the reasons that it's a developer advocate role. You need to be technical, because you're going to write article, you may have to code some demo application, depending on your product. You're going to have to talk to developers and you need to be critical. You need to see what it is to try to create an application, or what it is to maybe work with customer. The joy and the pain of being a developer, so you need to have that experience, that credibility.

I care also a lot about the skills, the people skills. Like, how are you able to communicate? Are you able to relate to people? Do you have empathy? Because that's super important when you talk to the developer, because most of the time, they're going to tell you to have issues within either with your product, or different technology, or they want to get your guidance, or knowledge. How are you able to share with people? Are you able to, again, connect with people? It's super important.

I care less about the specific technology that I need to hire you for. Let's say, right now it's cloud native, so maybe it's a little bit different. If I go for a really developer advocate-centric role where your job is about a specific technology, let's say, Python, and you've done some NodeGS, you don't know that much Python, but at least you have a little bit experience with another programming languages. If you have the soft skills, which I consider hard skill for that role, you're going to learn the Python stuff, because you have experience as a developer. As a developer, you cannot survive if you're not able to learn new technology. I'm really looking for more the soft skill.

A good thing to start, if you want to do that role, but you're like, "Hey, you know what Fred? I have a little bit of experience as a developer, or maybe a lot of experience as a developer, but I don't have experience as a developer advocate," what I did when I realized that, oh, that role existed. It did not exist too much when I started. I was mostly a big company, like Microsoft, but I went to a conference. I set up Microsoft guy, called developer advocate and it did a talk about one DuckNet technology, I think, at that time. I was like, "Oh, wow. That's a role that exists." I'm like, how can I show them that I can do the job without having done the job before?

You know what? I started to try to speak at meetups and conferences to get some public speaking experience. I started to write technical blog posts about things I learned, how I learned things, issues that I had and solution I found to show my process of thinking.

[0:31:56] JBH: Start doing that.

[0:31:57] FH: The fact that I'm technical and I can write stuff. I started to organize user groups. There's things that you can do on your own on your own time, unfortunately. Or maybe you can find a way to do this job and building the experience that most people will look for when they hire developer advocates.

[0:32:16] JBH: I'm really glad you said that. I think that's right. Just get going on doing some of it, so there's nothing stopping you in this awesome open-source world.

[0:32:23] FH: It's true for everything. I often have, I offer a coffee chat where people can schedule 30 minutes with me to get advice, and they take what makes sense to delete what you think doesn't make sense for what I say. I talk with a lot of people trying to start a developer career and I say the exact same thing. Write blog posts about your train of thoughts and how you solve an issue. If you go to school, put your own work on GitHub. Yeah, their own work. Yeah, they may not be super advanced, but at least you can show code to people, code that you created, code that people can understand, like you can explain why you choose to do it like this, this part like this, or didn't choose to do it another way. Putting things out there, like having example, you can show to people even when you didn't do the job professionally, it's really a good way to start.

[0:33:08] JBH: That's great advice. I was also going to ask you this rule of technical product manager, if you wanted to get more technical, you could go the other direction, right, from an influencing people facing job to something more technical in the same way by just getting started and posting it out there and sharing it. I love that advice. Frédéric, it's been really great catching up with you. Is there anything else I forgot to ask that you definitely wanted to share with us about your company and journey?

[0:33:33] FH: No. I mean, you know what? If you are on our Kubernetes cloud native journey, give Kubefirst a try. If it's not the tool for you, let us know why. We want to know why, because like we try to cater to as many people as possible by being still focused on their mission and what want to do, but we cannot please everyone. But let us know why, because that can give us some pointers. If you have a great experience, we love those, too. Not just the, "Oh, I got issue feedback." Let us know. Yeah, I think that's it.

Also, the other thing I would have, even if you don't use user tool and you're new to the cloud native journey, you have questions about what is GitOps and more information about Kubernetes, or you're starting to use Argo CD and you have issue, again, even if you don't use Kubefirst, come talk to us. We have that expertise. We're really community-centric. We just love to give back. It's not just me because of my role. It's the old company, the engineering, the founder. Come say hi. Ask us a question. We're going to be more than happy to help you, again, even if you don't use our product.

[END]