1:48 Introduction & Welcome

1:48 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, and today, I'm excited to be doing Rawkode live as we take a look at Gimlet, a developer platform built around GitOps principles. To teach us more about Gimlet, we are joined by its creator and maintainer, Laszlo Fugas. Hey, man. How are you? Hey. Hey, David. Thanks for having me. Thanks for the intro. Absolutely. My pleasure to have you on today's session. I'm really excited for this one. I'm looking forward to just, you and I, we always have good conversations. So this is going to be a good

2:11 Gimlet's Origin & Philosophy

2:23 episode today. Yeah, we don't necessarily see eye to eye on every topic, but I think that's a good part of it. So I'm really excited to be here. Yeah, hello, everyone. Yeah, yeah, always see that as a great thing, though, right? Because we get to share our own opinions and as long as we're all wise enough to share them in a way where we can have an open mind and learn together, it doesn't matter if you win or change someone's opinion, but we broaden our experience as a whole. So, yeah, excited is definitely where I am

2:54 today. For anyone who's not aware of you, can you just tell us a little bit more about you and what you've been up to? Sure. So I'm Laszlo Fogash. I'm sitting in Hungary, very it's very warm right now, 35 Celsius. Hey, Alessandro. And, yeah. So it's end of the week. We've been busy. We have relaunched Gimlet's onboarding flow just a couple of weeks ago and, did a lot of marketing efforts recently. So that's what we are up to. We are a bootstrap company, so it's just the three of us. So it's not like a huge venture backed operation

3:31 with a plethora of developers and DevRel people and so on. We are bootstrapping, meaning we are building the the product. I am sort of the marketing slash product guy and and trying to figure out the direction and so on. There is a React developer and also Golang, so, like, full stack. He's building features. And then there is someone who is working with clients. So we we do consulting, Gimlet's related and bespoke consultancy as well. So like cloud things from Terraform to Kubernetes and doing all kinds of stuff just to, you know, keep the lights on,

4:13 keep the lights on. And they have been on for more than four years now. So it's a bit slow doing like this, but we are default alive. So it's pretty enjoyable, to be honest, to be in this position. Awesome. And sense of it. Yeah. Yeah. And and and we have Gimlet as our main product. It was formed around the GitOps principles. I started early on with the flux1.0 or or even before that. And, yeah, flux was amazing. And and GitOps didn't click for me at first. But when I've seen it in action with, I think in the in the Nordics community, in

4:51 the cloud native Nordics, there were many early adopters. And I I I kept fighting them, like, why is this a good idea? But then I I definitely joined the the the bandwagon. And and it was very obvious from the get go that the the GitOps is not a full solution. So it's it's a nice idea. But, you know, to to make it useful for your company, you have to build the workflows and you have to wire things up the way as your team works. And since I am doing consulting and I was doing consulting back then as a single person, like

5:23 a solo shop, it was very obvious that I I I need to build these components myself as well. And, yeah, I have a handful of customers using Gimlet in the Nordics region, in Copenhagen and nearby. And, yeah, like, ten, twenty, 30 developers each. And there's some open source of that production as well. Alright. Awesome. Well, maybe we can dive into what's different with with Gimlet. Right? You've said that you weren't on board with the idea of GitOps initially. You kinda slowly came towards the idea. And, you know, Gimlet does want to have a differentiator, be a

5:48 Discussion: GitOps Challenges & Kubernetes Complexity

6:04 little bit different. Can you go into that in more detail and tell people what we're gonna be looking at today? Absolutely. Maybe if you bring my up my screen Of course. So others can see as well because we just relaunched the website, which looks a little bit rough at the moment. But essentially, we threw thrown out a bunch of stuff. I'm just not sure if my screen is up yet. Yeah. If you just want to show what you want to show now. There we go. Yes. Yeah. Yeah. Of course. Of course. So so we actually actually, this looked

6:35 much more corporate before and all kinds of buttons and options and stuff. But we went really to, you know, just to the to the core idea. Yes. You should fire up a cluster on your laptop and yes, you should start Gimlet and yes, you should start deploying from the get go. And what's different? I think in the Kubernetes ecosystem, there are many tools which are sort of centered around the idea of of an inventory of pods and config maps and deployments and ingresses, and you see them in tables without much context. So your so your application

7:11 workflows kind of lost in the picture. You just see this list of, resources you have. And then, of course, there are custom resources and all those complex all that complexity that comes with it. And with Gimlet, I think you're gonna see later in the demo is that everything is centered around, like, your commits and branches you have. This is very similar to GitHub, so the look and feel is kind of what you get with GitHub's commit view. And, of course, you have a real time Kubernetes view as well to the to the to the very minimal

7:46 thing. So it's not like not like a full map of all the resources you have. You have deployments and pods and and that's it. Basically, there's a URL where you can click it. And, yeah, so so it was very early on. I think this was in focus that the UI has to be centered around the developer and their use cases, just a single repository they are working with. And, basically, they want to see their CI statuses like, is my build done? Is an automatic deploy is done? If I want to deploy manually to some environment, that

8:19 was the key use cases. And, of course, rollback and so on. And and the other thing is that that with GitOps is that it's great. You know, GitOps, I mean, the flux CDs and the Argo CD approach. So not necessarily doing Terraform triggered from a CI pipeline and so on, but more like, you know, the CD, like continuous delivery of Kubernetes, YAML. That's the that kind of definition. And with GitOps, it was very clear early on that there are a lot of details like file structures and folder structures. What file goes where, where is my base

8:57 customized layer, how does that come together in a staging environment and so on. And the whole thing is basically just a big exercise of copying files here and there, templating something and writing to git repositories. And some very basic things actually got broken on the way. So for example, once you have written into the git repository, it's often things are not connected back together. Like, is my application really deployed? Is the health check passing? And all those things you have to, configure yourself in in in Flexiteam and Argo as well. And, like, still today, I think there were some

9:38 GitOps skeptic articles many years ago, like three years ago as well. And some of those criticisms still stands. Like like if you go into, like, the GitOps room on the Kubernetes Slack or the CNCF Slack, Like, very often you you face the question, like, how do I do promotions? And then somebody comes in, tells, like, how is my folder structure looks and how do I move files in between and so on. And it's all very basic. Basically, we are missing one abstraction level and and how how to do a smoke test and and what what what happens after the deployment.

10:14 All these things you have to basically glue together in GitHub Actions or some CI solution you have. And honestly, we should do better. And, this is definitely a problem space where, Gimlet wants to wants to shine. And yeah. So so these are the the two two core, differences where what I wanted to highlight, and that's where we have very strong opinions like how things should be done. Plus, we are very much into Kubernetes. Like, you know, we want to make Kubernetes boring. That is sort of one of the north star of the platform engineering scene and the ecosystem and so on. But

10:58 you know what I'm bored of really is is Kubernetes means. Like, it's so complex. It's it's, you know, it's, it's too steep of a learning curve, which I actually don't think it's true, today. Of course, you can always go into complexity and and people have been bad at, you know, stopping just that they're good enough with Kubernetes. They have to do multi cluster failover over service mesh use cases, but not many people need those. So actually, with Gimlet, we we just want to focus on people who who get introduced to Kubernetes, and they just want

11:32 to deploy something. And, they don't care too much about, you know, container networking and so on. So that's Gimlet in a nutshell. I'm I'm pretty sure I I triggered a few people. Did I trigger you? I don't feel triggered. No. I think I actually agree with a lot of what you were saying. So two key points for me, right, is you you spoke about the status quo right now with get ups. Right? The flux CD and Argo CD. Those are the two most adopted. I'm I'm gonna say platform, but I don't mean that they they are platforms. Right? But

12:08 those are the two most common tools used for get ups. But they're building blocks or primitives, like you said. If you want to do blue green deployed, if you want to do automatic remediation, if you want to do gated deploys, none of this exists. And either of those tools, you have to then go use Argo Workflows, you have to go get flagger. You have to look at the captain project. You have to keep leading on more and more tools. And that's just the common frustration with everyone I speak to about Kubernetes. It's like, I just want to run some containers.

12:36 I just want to deploy my application. And then that leads right into your second point, which I also agreed with. And the Kubernetes community, and I'll make myself guilty of this. Right? We start talking about eBPF and network policies and fancy deployments, multi clusters, hybrid architectures. Yeah. Of course, some of this stuff is very, very logical for some subset of customers that are trying to have certain resiliency patterns. But the majority of people just want some containers orchestrated on one, two, three nodes, like not even large clusters. They don't need to know about falco and all these things. Now,

13:12 of course, security is but everyone has a different risk appetite and we don't really appreciate it or acknowledge that enough. And I'd say the vast majority of people just want to get containers into production and keep their customers happy. That is it. So, yeah, not triggered as well. Actually, you said a bird like Argo workflows. Like, I've been I go I go to many meetups and it's very often I hear that what kind of big machinery they built with Argo workflows. And and there were some examples which were basically just reimplementing a continuous integration server, which felt like, oh

13:47 my god, sure, you have these tools, but you don't have to do everything yourself. So so those those definitely not, the kind of Kubernetes things that I like. So I, I definitely want to focus on making it more accessible. Like, just a month ago or a little bit actually, it was two months ago, I was asking on Twitter, like, you know, the Gartner hype cycle. Mhmm. And I just wanted people to place Kubernetes on it. And there were a couple of answers that, hey, Kubernetes is fine. I use it. For me, it's in the plateau of productivity.

14:27 And for for, you know, more like toolmakers and people who are aware of the of the grand scheme of things, it's more like in, you know, in, like, on the beginning of going up that that that plateau. Yeah. Because we are we are missing a couple of building blocks here. We are we are doing a lot of complexity things. But eventually, like, if you reach this this plateau, like like, I believe I have reached it for myself and and and many people who are building these platforms. And and honestly, I much rather copy a cube CTI command

15:02 off of the Internet today than any pseudo do something on my VM kind of approach. So so for me, Kubernetes is the go to place, a go to go to platform. And I would really hope that we would have, like, maybe resources like the digital ocean blog or this this knowledge base like they built over the years. And because what you did, like, or maybe do today if you have a VPS or like a VM, is that you type, how do I install Postgres and how do I set, I don't know, like a max page size for the kernel?

15:39 I have no idea about the the the page size parameter in ETC for the kernel, but I just copy from the DigitalOcean blog and I trust them. And I I think we we might miss some of these in Kubernetes or I I I actually don't know or don't fully understand, like, why people see Kubernetes as complex still. Like, yeah, I could go on on and on about this. Yeah. I mean, I'll add just a little bit of flavor to that, but I don't wanna spend too much time talking about that is specifically. Right? We've got a really cool product to look

16:14 at. But you're you're great again. I work with a lot of companies adopting Kubernetes. Yeah. Beer break. That's a good good idea. Cheers. Yeah. We agreed to have a beer because it's a yeah. It's a it's a long weekend, a very warm one in Hungary. So yeah. Exactly. So, yeah, I worked with a lot of people adopting Kubernetes and, you know, they're not coming to me with with difficult problems or difficult challenges. You know, it's not like, oh, we want to apply stack comp profiles and approve our security posture. Like, that never happens. It's we we changed the conflict map and

16:48 our deployment didn't update. Like, what do we need to do? And it's like, yeah, there are loads of these little rough edges in Kubernetes that we need more knowledge bases and how to guys and just a place people would just look up and see how do I fix this? Right? No. Even if you say adopt a mutable conflict maps, like even the operation of a plan of their cluster is much more difficult and not where it needs to be today. So, yeah, there are just are loads of things like that. And I and again, everything

17:14 you're saying is right. I'm not triggered. I'm I'm I'm happy to hear that. Alright. Should we jump into the demo then? Yeah. Let let's let's take a look at Gimlet. Alright. So I will just roughly follow the documentation and encourage everyone to to retry it because all you need is just a Kubernetes cluster. Just that's again, you know, could be a a tall order for many. But we recommend k three d because it's it just works locally. So this is how I'm going to kick things off. I'm gonna straight into the documentation, gonna do installation,

17:23 Getting Started: Installing Gimlet

17:59 launching k three d, which is optional. Of course, you can use and other providers. And there is this comment how you launch a cluster. Usually, this is how you launch a cluster in our k three d guide. We tell, like, why to launch the cluster like this, basically. Could you zoom in three times, please? Could you say it again, please? Could you zoom in three times? Three times. Yes. Perfect. That's the one. Alright. Alright. So so this is how you normal launch a cluster with k three d, and we basically tell people to disable the built in

18:38 ingress controller component because we want to get ups everything. So that's just bytes longer than it could be. The terminal now. Simple. And, again, just to just to reiterate on the previous point made is that if launching a cluster is this complex, like, that's not bad. I mean, I've seen a lot worse. Definitely. Yeah. Lake K 3 d has a very handy tool. Exactly. And the whole ecosystem, which I believe is super super mature. So in commands like get and describe and so on, you can get very far. So we have a cluster and how you

19:30 install Gimlet. One of one of the easiest ways is just Kubectl apply a YAML off GitHub. What are the alternative options to install? Is there a Helm chart? Is there operators? Like, what what's the preferred way? There is a Helm chart, which is hosted on GitHub. It's actually values are hosted here. Basically, it's using a hand chart called one chart. This is our general purpose web application Mhmm. Chart, which takes a few values like an image tag, port, and a few variables like host. Like, it's running on local host. Okay. Cool. We don't do operators or anything like that.

20:19 That has been always a little bit far from the vision. Alright. So at this point, it's running in the cluster. You can copy a port forward command. That's rather quickly. And here we are. Just a initial page. And the admin key is in the logs. Currently, it could be put into the secret, which is on the list. I guess that's just generated randomly on deploy. Exactly. Exactly. This is just a and it's only printed until you you log in first and then then you set it up. Oh, I forgot to Yeah. Yeah. Go forward. Oh, no. My demo is broken. Like, the

21:12 first first first click is broken. What you see here, very basic. You're gonna see your repositories here once you once you integrated GitHub, and you have environments, and there's a built in one. It's called Profound Sky. It's a it's a random one, the the nice random name generator. So basic yeah. Go ahead. Okay. So as you saw, was logged into the UI for the first time, provided the admin key. The first two tabs is your repositories, which makes sense. Right? It's get ups. We have to add some sort of repository to apply to the cluster. But we also see

21:22 Connecting Your Kubernetes Environment

21:53 environments, which means, initially, I'm thinking, okay, Gimlet supports multiple clusters out of the box. So is the idea for Gimlet that you have, like, a control plane cluster that does it on workloads that runs Gimlet, and then you attach your workload clusters? Or would you run that and the cluster with the workloads all at the same time? Again, just due to simplicity, we tell people to run Gimlet in one of their clusters, whether that's staging or or production or preprode. I run it in the production cluster for for our Gimlet deployment. So there is no control plane cluster simply

22:28 because of cost considerations. But, of course, you can you could keep Gimlet on the control plane cluster. Okay. Cool. And and and these these environments naturally would be called staging production and then preprode. This is just this communicates that, yeah, this is just for it's it's like a sandbox. Got it. Alright. Let's do which one should we do first? Environments or repositories? GitHub or cluster. Let's do cluster. Let's do cluster. So Can you zoom in a little bit on this page, please? Of course. Yes. Alright. Good. Yeah. So, again, just the k three d command if you would need a cluster again.

23:00 GitOps Setup & GitHub Integration

23:15 If you, So Gimlet has a SaaS version. So there are some people who have not started Kubernetes up yet on their laptops. So they could do that. That's optional. You definitely have to install the CLI because there is this command Gimlet environment connect. It takes the environment, the server, and the token as a as a parameter. I have all the all these previous steps, so I just here. Do you see the bottom of the screen as well? Yeah. It says installing flux. But yes. So so Gimlet itself, all it does is just it has a

24:07 dashboard and it writes to git. And there is a GitOps controller required to deliver those YAMLs. And right now, we are heavily, invested in the flux ecosystem, primarily because it's much more modular. There's no UI. You can, integrate with it rather easily. Is that flux one or flux two? It's flux two, VR, I believe, on the generally available version, two dot one, which was released yesterday, should become next week. Yeah. Because I only went GA like, what, four weeks ago or something? Five weeks ago, I think it was. Yes. Yes. Yes. Yes. Yeah. Yeah. So I've been so obviously, we

24:57 are a small company, so sometimes we are behind versions. So we are not like super on top all the time. In in this case, we were very keen on doing the RCs as well for two to two. And, yeah, it was very easy to to upgrade for us. Yeah. I love the the way the flux two works versus flux one. The way that the the sources are all separated from the customizations and stuff. Like you said, it's very much love you. And the the OCI support and the s three bucket support is all really sweet. So Yes. Yes. Yes.

25:28 Yeah. Now that the environment is connected, we see a different icon, some more tabs and some information there. If you set up your own environments, it's actually interesting because now the screen is so large. If I just zoom out just a little bit. Never mind. Never mind. This was not a CSS issue. I know what's going on. Anyways, so if you set up your own environments, can have different, folder structures and, different amount of git repository. So there is some flexibility in the boot strapping part of things. But as of now, we have a connected

26:07 environment which maps to a cluster basically. We have clients where environments are mapped to namespaces. It's doable, not very well documented. So, I would recommend people to jump on the or to our Discord to, you know, to map a namespace to a Gimlet environment. And down here, it's basically just Flux statuses. If it's small, it's just we have two git repositories, and these are the latest update times and when things were applied and synchronized with Flux. And, of course, you can dive deeper into the Git repository and customization statuses. K. Cool. Yeah. Alright. Let's integrate GitHub.

26:59 There is some text like, no. We're not gonna steal your passwords. No. We're not gonna steal your code. We you don't even grant any any access to us. Basically, that's the whole text, and you can install it under your organization or your personal profile. I recommend everyone to just use their personal profile and only grant access even so even even if it's their own application that we are creating only grant access to just a couple of repos while they are evaluating Gimlet. So I select just two examples. System and I install and authorize. Now the permission list is quite excessive,

27:50 so that's why I recommend people that that just take the repositories that, you know, that you use to just test things out first. And then once you gain some trust, I hope this won't be a problem. K. So this was a GitHub application rather than throwing around any sort of SSH access key or or things like that. So I'm assuming we're gonna see a deeper integration with GitHub than what we'd see traditionally from Flux or Argo. Yes. GitHub, I believe, has a a very good integration, approach with the applications and application and installations, and I could go

28:30 on and on about this. Now we tried, to integrate with GitLab as well. And, like, eight months ago, it was working. However, since we don't have any GitLab customers at this point, it was left behind somewhat. So we had to, you know, have some push to to bring GitLab up to up to speed. And honestly, their integration approach is is more like a big bang approach. Like, they have an admin token and boom, you give access to everything. So so I'm yeah. I'm liking the GitHub way much better. Alright. So so if you are a developer,

29:09 this is where you live. This is where you land, repositories. I'm an Express JS, or like a Node JS developer, and I'm a test application. I came in here. I see that I have an environment. Probably my cluster administrator set it up, or I did it just with a different hat on. And there's no configurations, no pods running, nothing. I just see that it's connected to a cluster. I I should see things if there would be things on the cluster. And down here, you see branches and commits and whatnot. And, basically, this is the point where, you know,

29:52 this is an Express JS app. I would need a Dockerfile, a Docker container, maybe integrate with CI somehow, then a Kubernetes YAML file. And and all these steps we actually packed into just this magically colored button. Internally, call the magic deploy. Obviously, you can use all those things. So you can have a Dockerfile, you can integrate with CircleCI, all the CIs out there. But if you just want to see Gimlet or you just want to see Kubernetes for the first time, you just push deploy on the latest version or the latest commit. Okay. So I I wanna make sure I

30:35 First Application Deployment with Buildpacks

30:38 understood what you're saying there. Right? Are are you just saying that right now your express application is just an express application with no Docker file and no Kubernetes manifest? %. If I go to GitHub, it has a package JSON and a Node JS file saying hello. Okay. So are you using, like, build packs under the hood to deploy this application? Correct. Yes. We are using build packs, and, this is the image building, phase. And here is just the Buildpacks output. Nice. Buildpacks, is nice when it works. And when it when it doesn't, they tell you to to create a buildpack configuration file,

31:23 but it sort of defeats the purpose in my my view. And also, since everything is running on local host, if I I suppose you have a Mac with an Apple silicon architecture. For that, we had to do one of the few, core tech contributions to the world that, Buildpacks doesn't work on ARM. There we go. So Yes. So when you when we stop the stream and you go home and, I don't know, you play a bit of gaming and then then you come back to Gimlet, reported buildpacks for the Node. Js ecosystem to ARM. So obviously, this won't build everything, but, yeah,

32:13 like your node apps. Okay. Should work. Clarify a couple more things then. Yep. Okay. So we have a k three d cluster, which is running Yes. Gimlet. You added an environment. Is that environment that you added the same k three d cluster or an external cluster? No. I I have just a single k three d cluster. Okay. So does the buildpack run and the Gimlet cluster or the environment cluster? Even they could be the same thing, but assuming they're not. Exactly. If you assume it is not, then it is running in the environment cluster. Okay.

32:53 Got it. Cool. It's a I think later, you will see a little bit more, like, how things are configured. But, basically, right now, it's one cluster, but the this image builder is running on the on the target, like, the deployment target cluster. And if it's not running there, like the registry, if it's not running there, you cannot deploy with this magic button. Okay. So it builds an image, configures the deployment, and we're off to the races. Job done. Exactly. And it creates a GitOps commit. So this is where GitOps coming coming to the picture. There is a commit

33:35 which I could click and I will click rather soon. There you will see the whole YAML and all the things, and you see the flux state that it has been applied. And now you're back in in the repository screen where you see, yeah, I had a deployment three minutes ago. It was by me. This is the version I pushed. You can open this up, and, you can see, like, a little heartbeat of what was going on, like the release event and then the actual, version that was deployed. Alright. Nice. And here, this is this is a deployment,

34:17 which has a single pod. We're gonna configure it, guess. That's the classic scaling example. We're gonna, like, take the replicas slider and just increase it to 10 or something. And, yeah, you can look at the logs and whatnot. And here you can see there is this little little label, showing which version is deployed. And if we should we make a change in the, application or should we access the application or we can take this wherever from here. Okay. So let's talk about this generated commit. Is that to my express application or is there a get ops

34:51 Application Updates & Configuration

35:03 repository now where you do all of these automated things? There is a GitOps repository. Each environment has, by convention, two repositories, one for application stuff and one for infrastructure stuff. Now how many git repositories, how many folders? I think people can debate this endlessly. This is sort of middle ground that has worked well for us. Okay. So can we start by looking at the Kmet and see what was generated for us? %. Let me just do one technical thing here to to you know, you remember that this Profound Sky was in Gimlet just when we logged in. It was already

35:53 created. There we didn't have any GitHub access at that point or nothing. So at this point, this is this this is a Git repository, but lives inside Gimlet. But I can con but I can convert it to a real environment. And then if I push this button, it will be thrown onto GitHub. And the magic of GitOps and Flux and everything's gonna reconfigure itself. It's it's magic. Like like when like like like like when you update flux, you just update the version number in the git repository and it updates itself. It's like magical. Well, that's a really interesting pattern actually. Right?

36:30 Because one of the challenges with GetOps as it stands today, right, particularly around flux and Argo CD, is that the ability to spin up ephemeral clusters with preview style environments is a little bit trickier than it probably should be because it relies on a real get repository somewhere and then all of our environments need certain configuration. There's loads of little parks that need to be in the right place. The idea that Gimlet just runs its own internal get repository for this stuff and each environment kind of enables that pattern a lot easier. Yeah. Honestly, I we had like three or four iterations

37:08 on the installer and how because it's so many moving parts. I mean, it's Kubernetes, it's GitOps, it's it's everything. And this, by the far, the the the simplest. And, again, if I push this button, I convert it to a GitOps environment. This is the time when it goes to GitHub, creates the repo, pushes the manifests, updates the manifest to actually flux to point to this new GitHub location. So, actually, we should watch this. There is a bug actually here that it keeps jumping back to a deploy status. Yeah. So now the customization is, is updating.

37:52 Just waiting for some dependency and so on. So, basically, at this point, we have these two repositories. One is applications where you can see the Express JS test application, many YAMLs, from seven minutes ago. And there is the infrastructure one, which has a lot more, of of course. Cool. So if if you actually jump back to the deployment, these now are clickable, which surprises me even like I didn't refresh the page or anything and it just suddenly just works. But anyways, this was the commit that was made for for the deployment. Deployment service. And there is something called the release JSON,

38:38 which is a bunch of release information for Gimlet to display the version history efficiently. Alright. Nice. Okay. So shall we make a change? Yes. We can make two kind of changes. We can make a configuration change or we can make an application change. But let's do an application change first. Okay? So I think I have this one cloned. Projects. I should go to Express JS test app. Ignore this order for now because these are previous test configurations. But in the Node. Js, we're gonna say hello, Rawkode world. So this is the new version. Here on a you

40:10 wanted to say something? Yeah. I was gonna ask if this is gonna like, because in the first deploy, you had to push the button. I was wondering, does it know because you've done it once, start to automate based on the main branch, or do we still have to go in and click the button? For now, we're gonna click the button, but we can automate it in the next step right afterwards. Okay. Technically technically, we could do the automation. I just want to finish this this example. So you see the commit here on a normal deployment, which is not running a local

40:42 host. A GitHub webhook would have pushed this commit much sooner. But if you're local host, you can push this refresh and, it's gonna appear. Alright. So this is the latest demo with Rawkode, and this is the new one. And, again, it builds the application. I still haven't defined any Docker files or anything or not even Kubernetes YAML, but we're gonna soon get into that realm as well. Now it's trailing and now it's actually you see the pods flashing. The version is demo with Rawkode. Commit was applied. Actually, I click this, this is the GitOps commit.

41:27 Yeah. Some hashes were updated and yeah. The image hash was also updated. Nice. Kind of what you would expect. Alright. And maybe let's access the application first. Yeah. I could port forward for now, or we could do ingress maybe later. And you were asking if we can automate the deployment of things. Now this is the application configuration screen. So up until this point, everything was default, but you can take this default and make it yours. This is basically just a health chart, and we have UI rendered on top. You can start using a real image, not

42:18 just this built in registry. You can change the replicas. And you wanted to deploy based on a policy. Now I have to tell you bad news because this only works if if things are more properly set up with CI integration and so on. So actually, we are missing a trigger for this to work in this in this in this scenario. Okay. But if you build your own image, like on on GitHub actions, And your CI is running and that there is a point where your CI, like, today, maybe, does a Kube CTL apply or a Helm install or something.

43:07 Instead, there is a Gimlet, GitHub action, which would speak or talk back to Gimlet like, hey. There's a new version. And then this trigger would work. Like, hey. There's a tag on I don't know. We I got something. Okay. Right now, let me just make a change, like a configuration change, to three replicas and maybe set an environment variable which is, I. And there is this intermediate format, which is basically parameterizing the ham chart that we use by default, and it takes a few parameters. If I save this now this is the first time where application

44:10 configuration, like the the deployment configuration, is getting into my source code. Asafo c p h is editing this deployment config for the Profound Sky environment. It's placing a single file in your repository. This is the Gimlet manifest. It pins down the chart and have some values, or you could use customized patches or just raw, plain Kubernetes manifests. If I merge this, my team liked it. And I go back to to Gimlet. And since this is a local, I push this refresh button. The pull request is here less than a minute ago. And if I deploy this guy,

44:58 then remember we changed the replicas to three and we defined environment variable. Okay. Nice. So I'm assuming this one chart that is being used is really just I mean, we've all seen this time and time again. The way that we deploy an application to Kubernetes is almost ubiquitous. We have a deployment, you have a service, you may have an ingress, there may be a conflict map, there may be sequence. I'm assuming there's one chart just has value fails that allow us to tweak how those all speak to each other. Exactly. Very clever. It's actually it's getting some traction and some

45:43 get up stars. And it's been, you know, it's been out there for almost four years. And it's it's one of the easier to explain things Gimlet has. So I mean, all of them charts, they're they're all the same at the end of the day. But then every configurable, and they all regress to the same chart. Yet we all publish charts uniquely as if there's some sort of snowflake. Exactly. Exactly. And and of course, if you're a post SQL, you might have, you know, an setup which requires very intricate setups. But most in most cases, just I don't know. Yeah.

46:21 What you said. Yeah. Most people write a web application that exposes some port that needs a service, and that's it. Like, job done. Actually, I I want to do a plug. So we have a YAML generator, which is basically the Helm chart and the the screen that you've seen. You can use this online as well. So this just, changed the replicas to to three or five. Actually, five. Yeah. And you can send it to your friend with a base 64 encoded values and so on. And there's a static site option. This is one of my favorites.

47:00 This actually like a this is the all the parameters it takes. If you recall how Netlify works Mhmm. You set set the build command and the and the folder. And basically, this is what we did with the hub chart and the init container. So Yeah. Nice. That's that's Can you go back to the web app for a second? Yeah. Yeah. Of course. Because I see no. They're on your generator. There was a pot disruption budget. Right? Oh, yeah. Yeah. Yeah. Sorry. Where should I go? Should I go to the generator? Yeah. It was on your

47:34 generator. I just noticed the part disruption budget. Oh, that's fancy. Yeah. I don't see a lot of people deploying them, but that's a nice a nice little toggle button that just makes it work. Yeah. As I told you, we we operate many things for our customers. So things we need are in here. So here's the here's the secret self soft question. Right? Your spread pods across nodes is that pod topology spread constraint or is it affinities? I think the first one, but I don't recall. So how about I turn it off? I put it guy and put it here,

48:13 and and I turn it on and copy. Start a new one. Oh, this is something that people can't see very well. But, how do I do? Reopen the tutorial. Yeah. And please let let me scroll. This was the off and this is the on. This is a bug. Yeah. I don't think it's actually adding. It doesn't add anything. It's it's perhaps because of the replica count. Oh, yeah. Perhaps. Oh, man. At least we found something useful today. Well, is this open source? Can people contribute? Exactly. We should have a test, a unit test for this.

49:14 Right. So we need someone to fix the bug and someone to write an open policy. There we go. Exactly. So tests. I don't know, man. Yeah. I I I need to check this. Something is off. Maybe there is some extra requirement. Jump into templates and then let's open deployment dot yaml. Exactly. Deployment yaml and then See what we got. How how is it called? Affinity or something? Yeah. There would either be an affinity or a spread constraint. Put affinity, spread of those nodes. Yeah. Okay. Yeah. Based on these labels. Yeah. So this should be I will make my

50:06 first contribution to your chart this evening. Thank you. Thank you. Because there's a really nice new feature. Oh, I guess it depends on which versions of Kubernetes you wanna support with the one chart. Right? And Kubernetes one twenty six pod pod topology spread constraints were added, which allows you to replace all the old affinity stuff that we used to use to get at one per node. The problem with one per node is that if you get one on it and you need four and there's three nodes, you can't schedule the fourth. But with pod topology

50:32 spread constraints, you can actually it will put one on as many nodes are possible and then spread them again and again and again. So it layers them. Uh-huh. Cool. Uh-huh. Yeah. This was added two years ago. So, yeah, definitely not not one twenty six. Anyway, let's let's let's go back to the good stuff. So Alright. Yeah. Yeah. So so as as a as like a developer, you can roll back and you can set up your integrations with Git and and so on and all kinds of stuff actually. But this is the core. So like the view and and and, you know,

51:12 like the the field of things. Yeah. Very nice. And, of course, if you're a cluster administrator, we have like a marketplace kind of thing, like all GitOps bagged. Yeah. It's it's all GitOps bagged. So it's not like when you you know, you go to DigitalOcean, I think you you click one click deploy or one click applications. It installs it. But what happens afterwards? That that's a question mark. Like, how do you keep it up to date and so on? And since this is GitOps, all these components are just community ham charts. Like, actually, I don't have anything special here, but maybe

51:17 Infrastructure Management (Marketplace)

51:52 I'm gonna deploy NGINX just just so you can see it. But we have hand releases repositories. And, yeah, let me enable NGINX. There is, like, a one pager, like, what you can do with it. Enable. And we don't expose much of the, you know, the the wide options of all the Helm charts. What we have a knowledge base entry for and what we support is like a yeah. It's mandatory. We'll suppose and you can use these you can extend, these ham chart values in git. So now what is being placed into this repository is, regular

52:38 flux CRDs like helm release. And you can extend these values. We will not break it. We will not lose it. There is like a three way merge going on every time you we we we update these. So so you could have custom configurations in here. But if your peer approved this and merge it, Then, of course, flux going to pull it down, install, and it is visible somewhat again in this let me just push a refresh in this this view. So now this is pointing to the latest commit, and there should be a message here

53:30 that what why is it waiting right now. But, yeah, you can deploy components like this. And now that you have an ingress controller, of course, the world opens up and you have cert manager. And, honestly, just by Gimlet just puts YAMLs into a Git repository and builds on brilliant components and brilliant custom or Kubernetes resources. And just by this very thin feature set, we can support basically, yeah, all the needs that a small medium company needs. Of course, whenever you just grow out of Gimlet, you jump into these repositories and you you make modifications to the infrastructure components as you please.

54:23 For the developer part, we have a workflow. People might like it, might not not like it. And, yeah, they can decide for themselves. And and I really encourage everybody to to jump on onto the website because it's really all it takes is k three d and kubectl. Yeah. Awesome. Nice. Alright. Let me pop this over. Is it demo done yet? Alright. Okay. Cool. I think yeah. I I think at least until we have more topics to discuss, I think. Yeah. Yeah. I I like that. What I like about Gimlet is this hooking into the open source ecosystem.

54:44 Discussion: Gimlet's Value & Vision

55:01 It's just in flux under the hood, but is then, you know, you you kind of appreciate that flux as just a primitive. It's not a platform, and it requires a lot more work from developer teams beyond that. And Gimlet seems to just be sitting on top of that and say, well, let's make this easier. And so I like like that we I can't believe you gave that thirty seconds at the end of marketplace. Right? But that's a huge feature. Like, again, for people that just want to get stuff deployed to Kubernetes, they want to get Kida involved. They want to

55:29 have an ingress controller. They they want to deploy a post grids, whatever that might be. They there's no framework that can do that. Those things don't exist in the marketplace just now, then someone can just go and add it as an open source contribution. So we're building, you know, an entire product that the community can benefit from that makes life easier for the people that don't wanna be in the nagery all day. I like that. The UI and the syncing and all of that is really cool too. And using Buildpacks. It's very cool. I like

56:00 Thank you. Thank you. Yeah. So so you mentioned Keda and you install Keda. It just went, you know, just graduated in CSCF. And so I set up Ketaph for the fifth time for in the past two years or something. And the use case was like, hey, I have a queue. I need to have a worker processing just one unit unit of the queue. And they should auto scale this. And this is a very complex thing. And I told the guy, this is gonna be fun. Like, join me, screen share. We were done in an hour.

56:39 And and this is when I when I say that Kubernetes is, like, crazy major in some areas, of course, and we are lacking a bunch of things elsewhere. But but as you said, like, from from those marketplace, that's once one building block. I would really like if Gimlet could be the content place as well, where people could get this operational knowledge. Hey, I need SSL. Hey, I need an auto scale job with a ready SKU. All these things like what Digital Ocean did, I mentioned earlier. So that's definitely part of the vision. But we are a bootstrap company and, yeah,

57:17 life is always in the way and so on. So yeah. Yeah. I mean, every time I talk about Kubernetes at a conference, right, there's always the people to see it, but there's a lot of complexity. And what if you don't need that complexity? And my answer to that these days, right, is that Kubernetes is what? Seven years old, a lot of fat older than that. Right? It's got to the point where it's almost ubiquitous if people are deploying web containers. So now you've got a choice as a small organization. Either use the thing that everyone else is

57:46 using or you just use Docker or some other tool that's not as complicated however because everyone else is using Kubernetes. All the evolution is happening here. All the contingencies are happening here. You're gonna lose out on tools like KEDA and Captain, Gimlet, all of these things. Monitoring is drastically easier with Kubernetes because you can just install Kube Prometheus. Right? So you sacrifice all that stuff and yes, there is a bit of complexity, but we're fortunate enough to have people like you and others in this space who are building tools to make this easier for the

58:16 people that just want to get shit done. And I think that's really cool. So Kubernetes has complex, but it's worth it to take advantage of all these amazing evolutions. David, you're studying saying this better than I am. So thank you for all this. I'm taking notes and I'm gonna watch the recording and put all this on the marketing page. So thank you for this wonderful summary. Alright. Well, before we finish up, why don't you tell us you know, you've mentioned division of Gimlet a couple of times. So maybe tell us what's coming next, what he's working

58:41 Future Plans & Getting Involved

58:49 on, what's exciting. Yeah. What what's the future of Gimlet? Many things are exciting. Right now, I am honestly, we are getting Google searches on things like how do I deploy static site on Kubernetes. Like, if we've wrote a static site blog post in April and that's the highest performing one. Also, the CML generator you've seen is is also on the top three from where we get we are getting traffic. So it's not exciting from the product product's perspective, but it's exciting from the business's perspective that that we should funnel in all those people and maybe widening this

59:32 this audience that that could come to Kubernetes. So definitely, that's one focus area of mine to to help these people and and really, yeah, help them and, you know, like, getting adoption and and users and so on. And obviously, on the product side, there's so many things, we can do and we probably should do, like, like application troubleshooting, like, if the pod is in crash loop, like, what to do, like, either with with content pieces or, like, well placed warnings. I don't wanna go, like, a like, % in, like there are startups on this niche

1:00:12 alone. So I don't want to do all that, but at least covering the basics because I think we should do a lot more than what we do today. So that's definitely an interest area. And then comes the the brilliant use case of, you know, if you could provision cloud resources like an SQL database or a cloud Redis instance with cross plane or, we actually had something working with the Terraform controller. But now sort of not not not prioritizing that too much at the moment. Yeah. So so those are those are like, I'm an engineer and and I just love

1:00:49 that use case. Then we have it working and it's super simple and it just comes down again us creating a YAML file in a git repository and the wonderful ecosystem of Kubernetes. All those controllers just just work. So I I just love that. So most likely we're gonna do marketing and and and nailing the developer workflows and some observability and troubleshooting. I think that's that's very much in focus right now. Polishing the big things we have, filling in the gaps because we have gaps. Alright. And lastly, if people want to get involved, they want to contribute, or they would just

1:01:33 want to follow you for all of your takes on Kubernetes and complexity, Where do they go? They go to Gimlet. And launch k three d and launch Gimlet. That's that's that's the most important because we are we are so hungry for feedback. And we have a Discord channel. You can find that on the on Gimlet. We have Twitter, Laslow CPH, and we are on YouTube live streaming and hoping to pop up, yeah, everywhere where people are, KCDs. We are going to Austria in September 25. Sadly, we we have to miss Sivo Navigate. That's just not good timing wise and yeah.

1:02:16 All kinds of things. But, yes, come find us on Twitter, Gimlet underscore and Laslow CPH. And also GitHub. Yeah. Everywhere. Alright. Just go to Google, search for Laslow and Gimlet. You you won't miss. Exactly. Exactly. Well, thank you so much for taking time out of your evening, for joining me, for having a beer, and for talking some really cool tech stuff and showing us an amazing demo. Thank you very much, David, and all your really cool summaries. It has has been very cool. Thank you. Alright. And to everyone watching, have a great weekend. We'll see you all

1:02:41 Conclusion

1:02:51 soon. Until next time. Bye.