Transcript for "The Reports of Open Source IaC's Death are Greatly Exaggerated": Hi, everybody. Welcome to today's ICConf spotlight. These are virtual sessions where we, have folks from the community submitting topics, and we give them the platform of IC Conf to present what they've built, what they've learned their knowledge, and share it with with all of you in the infrastructure as code, community. The chat is open on the right. Hello, Daniel. Thanks for, joining. There's some docs there, some links that Isaac here, who's the presenter today, has in his presentation, links to a git repository, some demos. Throughout the session, if you have any questions, just drop them in the chat. We will, answer those at the end. We've got a live q and a that we can run after ice... After Isaac has gone through his presentation. And then I'll also share some some some details around, like, what's coming up with for ICConf, once Isaac has wrapped up. For those of you who are new to ICConf, this is a community we've been running since May 2025. We did our first conference. That's an annual conference. We did the second one in in May '26, 15 speakers. And we do these virtual spotlight single sessions to, again, highlight a single individual, what they've built, what they can share with the community, as well as we do some some networking events, in person events, along with side conferences like KubeCon, of which I'll share what's happening, there, in November at the end of Isaac's presentation. With that, I'm gonna hand it over to Isaac, who's the presenter today, and, yeah. Take it away, Isaac. Thank you. Thank you, Garrett. Thank you to the Spaceless team for inviting me. I'm excited to talk to you about, well, the topic I gave was the reports of open source IAC's death are greatly exaggerated, but I'll explain myself. A little bit about me, my name is Isaac Johnson. You can find me on socials at, Mastodon at Isaac Johnson or I Johnson NLC social, LinkedIn at Isaac and Damon. And I'm an active blogger at, freshbrew.science. I try to commit myself to two posts a week. The agenda today is kind of in two blocks. So So I'm gonna give you a kinds of heads up because if there's questions, I'll probably pause after the first section to answer any. And the first one is really gonna be the talking points about why we see this purported death of open source ISE and open source tooling in general and why I don't think it's that way. And then the second half of our session is gonna show you some demos, kind of the meat of it for the people that want something to walk away with to see some examples of real open source tooling, what does that mean, and how does that work. And I'm gonna do some demos here in both Azure and GCP. Nothing against AWS or other cloud providers, but those are the two that I tend to use the most. So that's where my demos are going to be. Now every time I hear somebody saying open source is dead or dying, I mean, this is my attitude. I'm like, come at me broke. I'm an open source fan. And so this is kind of... If at all I'm guilty of anything, it's a lot of passion about open source and open source tooling. So the first way I've seen kind of the industry or or the the things at large trying to kill open sources with licensing. What I mean by that is these companies start to ditch their open source licensing strategy. So, Arman Dadgar, who is the cofounder of HashiCorp, had said in 2023 when they cut over from an open source license saying, for its part, HashiCorp simply grew tired of companies that are making money through services that rely on its open source projects. When Redis followed suit in 2024 with the BSL, they said, new source available licenses allow us to sustain... Sustainably provide permissive use of our source code. And, of course, the first big one that I can think of, though technically is an infrastructure as code, but it is a big cloud provider, was Confluent, who dropped Apache two in 2018, and they said, we think it's a necessary step. This lets us continue to invest heavily in code that we distribute for free while sustaining a healthy business that funds this investment. And in blue here is kinda like the summary of what they're getting at. They said, we must do this because people are taking our stuff, and we can use this license money to invest and grow, and everyone should should definitely win. How'd that work out? Well, the founders left HashiCorp. Mitchell first, Mitchell Hashimoto left, and he famously formed, started to build Ghosty. Immediately after they changed licenses or within the week, we we got two big forks. We got OpenBao, which is the fork of Vault, which is now today in production at NVIDIA. We have OpenTofu, which started strong and then was adopted by the Linux Foundation and quite frankly is what most suites out there are are using as their basis. As things kinda stagnated, IBM went and acquired HashiCorp in in this last year. And after that, they ditched HCP Vagrant and ditched the free Terraform cloud. Now I had a slide in here that showed cost increases, but, again, I'm not throwing shade. If you know it's IBM, you know cost increases are part of it. Confluent was acquired by IBM in 2026, so they lasted much longer. But by this point, most cloud providers have their own message queue. Whether you're talking about GCP PubSub, AWS MSK, Azure Event Hub. I mean, GCP does have a managed service for Apache Kafka, but be aware that is the open source one. And I wanna applaud Redis who did return to the AGPL in 2025. But by this point, VowKey is the default in GCP and only open source Redis and VowKey are available in AWS. Though there still is a Redis commercial offering in Azure. What we kinda saw here... You know, I'm focusing on HashiCorp because I think they're the big one that we think of. After they did their license change, they really thought that would change their patterns, and it didn't. That mean their their stock stayed depressed till IBM was able to announce their purchase, and then it held at what they said their purchase price would be. And IBM did... Or Armin did leave after 2026. And HashiCorp, which I had been to everyone since, like, 2018, it's gone now. It's now IBM Tech Exchange. Redis is a private company, and all I'll touch on this because you can get private ones through Hive, is it didn't really change their stock price a whole lot here. We we saw it jump a little bit, but after they've returned to open source, things have been improved. And so were the expected versus actual results. They expected that open source contributors would recognize the need and keep contributing. They expected that businesses would be emboldened and derivatives would voluntarily license, and they'd expect growth would continue. But the reality is open source contributors left preferring real open source licensing and companies not to relicense their contributed work. We saw the funding of open source development shift to the forks as did the derivative work as did the cloud offerings. And when all the movement moves over to the forks, it means growth slowed in those other companies. And it's my opinion that when those companies had slowed growth, they made them prime for being picked up and acquired for their intellectual property and license revenue opportunities. Another way that I have heard or I I see them trying to kill open sources with AI. And, boy, what I mean by that is this idea that you can just copy it with AI or Vibe code your own. AI will fix any open source bugs. There's no need to contribute. Stormy Peters, head of open source strategy at AWS said, I was worried that I'd kill open source software because I would generate this code or this pull request so fast, I wouldn't see any value in it. I generated in three seconds. You could generate in three seconds if you need it. Why would I spend time pushing it upstream when anyone could just generate on demand? And there's this idea that AI can replace it with some other tool whenever we want. I mean, the one on the right here is the one that's gotten all the press the last couple weeks about, the art craft forks of Adobe products. And how'd that work out? Well, what we see in production for big software, and I spot checked a couple things from Reddit, is once in production, you start to see things that, once the the leaders leave, that they have to start to to rework it and treat it like a black box. So the developers quietly start rebuilding its core modules by hand, and then it takes days because you need to do a quick refactor. The other challenge of AI generated code... And this isn't an anti AI talk. I use AI myself. But we see, cases of problems from some of these Vibe coded apps with security. So mold bulk leaking 1,500,000 API keys or famously the Replit CEO deleting his own production database. And there's a few others in there like Lovable Base 64. And there have been negative impacts. Right? So we see bug bounty programs have ended. You know, maintainers are 90 slower having to review AI code, which is 1.7 times more likely to have bugs. And we recall that curl ended theirs when their useful submissions dropped from 15% to 5%. We've seen widespread bans on AI generated code. So Codeberg, which I used to use regularly... I've had to stop using Codeberg because they say no generated AI code, and I'm respectful of their ask. So Codeberg doesn't want anything that's generative AI in there. Gen two Linux, NetBSD, QEMU. And and I'm sure you can think of more that have banned, LLM generated code. We've seen supply chain attacks. Right? We saw the hacker bot claw on GitHub, and we saw some GitHub action ones as well with some 500 PRs. That was pretty famous. And if we think about those GitHub ones, that's a lot like how SolarWinds got knocked down a peg when somebody got into their build pipeline that then exposed it, which kinda ended the company more or less. Not ended it. They still were out, but really knocked them down. So the supply chain attacks become a very common vector for hackers, especially with GitHub. And then a... LightLM having one with one of their modules leaking to AI, credentials to hackers. There's been some positive impacts too. It's not all negative with the AI. So we've seen a high use of open source frameworks. Tailwind CSS uploads are are up a 126. NPM is up 70%. PYPL is up 87%. We've seen some vendors come in here on the side. Chaingard has nothing to do with this conference, but Chaingard is one of the ones that I like to look to because they have open source, free to use con... Containers that are, zero CVE. And they've recently had a chain guard factory that will give you validated libraries, so that's a paid product. And lastly, the other positive impact I see as a positive impact is it teaches us to put on our big girl pants and think a little bit better about how we do pipelines. So just like you would never deploy real workloads to production with an at latest tag, you shouldn't use an at latest tag on your GitHub actions either. Like, it's just, we just need to do a little bit better job. We should listen to our Dependabot. I know I have some Dependabot alerts out there I'm ignoring. I'm pretty sure y'all have some too. It's a case where we could, you know, do a little bit better job on our dependencies. And last thing, there's nothing wrong with GitHub. I pay for GitHub. But if you're really worried about attack vectors, there's things like Forge Joe, Git t, and other Git tools besides GitHub. So in summary, kind of the summary of this this this first part is really companies who provided open source only to close the licensing saw real impacts, and a lot of them, at least the ones I highlighted, got acquired. Some did return to open source licensing in the end. As far as AI goes, AI has shifted some operating models. It's negatively affected bug bounty programs as well as caused projects to ban AI. However, we've got some new, opportunities in here. We've seen some companies like ChainGuard come out with some tools, and there are others too, and can... And frankly cause us all to do a little bit better DevOps, grow up a bit. So it's kind of the the first part of this, why the licensing and AI, I think, have not really dropped open source. So there's no questions. I wanna move on to the second part, which is a little bit of show and tell. So the first part was a bit about, why I think the reports are... Of its death are are bunk. But now I also wanna give you some examples. Right? Let's show some open source tooling in action. So I wanna focus on using some open source tools to manage and build infrastructures code that deploys to a cloud. And some of the things I'm gonna hold to is I want Git for my revision control. Yes. There's other tools out there like Mercurial and Bazaar, but we'll stick with Git. I want some kind of YAML code driven pipeline, though I don't really care. You can use Jenkins if you want or you can use GitLab or GitHub. I use Forge Show and GitT because they're open source, pipeline and repo tools. And then I'm gonna use an open source standard. So for infrastructure as code, I'm gonna highlight OpenToFu and Ansible. There are others out there, but these are the two that I would like to highlight here. The OpenTofu is obviously the open source, fork of Terraform and Ansible, well, nowadays, IBM owns a bit. Ansible is, in a provisioning language in the, YAML. And lastly, we're gonna minimize reliance on cloud SaaS. How... However, we're gonna allow for migration. And what I mean by that is, as I look through open source tools, I like to think about kind of the trade offs we can do. So for instance, with notifications, I do have pipelines that, trigger a matrix synapse notification thing, which is an open source chat tool. But they also go to my Discord and my Telegram, and my key base. So, essentially, send your notifications where they matter, where your users need to know that your infrastructure has an issue, because changing your notification path is really easy. So just go where your people are. If you're on Teams, use Teams. Secrets are effectively free. So I do have Bitwarden in my stack, and I sometimes use it. I don't feel compelled to use it, though. The reason is things like GCP secret manager, AWS secret manager, or Azure Key Vault, they're all basically free. I mean, you gotta hit them a million times before they start charging you money. And if you're going into the cloud, I mean, use the cloud. Why not? Lastly, remote state management, you can do it. I've done it on storage, on my NAS here in my network. But if I'm gonna deploy into Azure, I'm just gonna use Azure remote state management because if I... I'll just have a storage bucket with the state file. Why change it? And the other thing with state files, sometimes people get really worried about it. You can always rebuild it. So if you were using what you thought was durable storage, which wasn't that durable, you can always rebuild your state file. So some things I'm gonna hold to, though, is I'm gonna stick with OpenTofu or Ansible. When I'm at work and we have to deal with the other vendor or if we have to deal with IBM Terraform, I'll say nothing newer than the one dot six syntax because I don't want to ever be locked into to that. My build pipelines... This... And I'm gonna tell you. If you take anything away from my talk at all, take this away. When you make build pipelines, use bash groups. Don't use those preconfigured actions because if you build your steps to invoke bash or PowerShell and you have help with them, so when you run them bare, they spit back, you know, what they expect for invocation, and you put comments in them, then if you ever had to switch from, like, GitHub to Harness or from Harness to GitLab or anything like that, your conversion becomes a heck of a lot easier because it's just a series of steps that call bash. So I encourage you, use bash, use PowerShell. It will save you a lot in time. And lastly, accept the fact that drift will happen. It just will. You're gonna have somebody who needs an a storage access policy changed on an afternoon because the costs were up or somebody needs a secret access policy to a key vault. You're gonna change it on the fly and then have to remember that, oh, yeah. I forgot to change the terraform for that. So just, remember that. I like to quote Larry Wall, the three virtues of a great programmer are laziness, impatience, and hubris. Alright. So here's kind of the build system I'm gonna talk about. We'll have a forge show self hosted Git with an action server. The Git repositories will be in forge show, which just Git t by any other name. I'll have my Terraform code as open tofu in there. We'll be using forge show actions, which are a lot like GitHub actions. They will be building out stuff in Azure as well as GCP. We'll have local build infrastructure. I use Docker containers, again, running on VMs in my stack. And then the state management, I highlight that I'm gonna use a local NAS. I'm not. I'm going to be using Azure storage. For credentials, I highlight I use Bitwarden. I am not. I'll use anything that... Actually, these are just pipeline secrets. And then monitors alerts, they can go to matrix synapse. How that looks kind of in a nice pretty isometric diagram is this. You know, I have a series of laptops that run my k three s based Kubernetes. I have a local NAS that's attached to them supporting both PVCs as well as just managed, local path storage. And then I have Bitwarden running in here with secrets to Azure. And I like to do this because it... That's a really cool pretty diagram that looks really slick and nice, but that's the reality of what my Franken cloud looks like. So behind the wall where you can't see because I have a virtual background here, that's the Franken cloud that is that guy. So I always like to kinda highlight, you know, behind the curtain. That's what a lot of clusters, I think, for home labs look like. So here's my scenario. What are we gonna build? Right? If you're gonna build something, what are you gonna build? I'd like an Azure function stood up that can expose a containerized app for showing demos. It needs a public URL. I wanna easily update it with new images, and I wanted to easily destroy it when the demo is completed. And because, you know, you can't have a conference talk without saying something about an LLM, it's gonna do dad jokes that are generated from a local gamma model. So there's your LLM for the day. So I'll start off by creating a repo. That's kinda like you do in any other tool, though I'll make it public so other people can see it. And then once you have your repo, you can kind of initialize it or get clone. I'll go back to my Zed. So I'll fire up Zed locally. And and this is kinda where I'll show a little bit how I do a little Gen AI. I use the anti gravity plug in to Zed, and then I also have the Copilot plug in. So I kinda dance between Copilot and Anti Gravity. For work, I also have Claude in here. I like Zed just because it has VIM bindings, and that's just how I roll. And it's it's a very fast editor because it's written in Rust, but that's how I build things out. So I kinda built up this app. It's got an app file. It's got the CICD in here. It's got the Docker file and the requirements. And this is the code. I hope that looks okay on your screen because it is a little small, but there's links to my repos in the in the document as well. But, essentially, I say, olam host is this environment variable. So I have the host and the olam model. I know other people have discovered. I've left that open and unsecured because I can hear the gaming laptop kicking in whenever somebody hits this. And the dad joke is, tell me a dad joke about programming. And the way this works, it just goes to API generate with the prompt and gets it back and shows it on the screen. And if we look here... I'll read that because it is a little blurry, I'll admit. That's my fault. It says like a programming dad joke using gamma four e four b running on this laptop literally to my left. Why the programmer quit his job? Because he didn't get enough compile mentoring. But here's the one I do like. Why do programmers always confuse Halloween and Christmas? Because oct '31 equals decimal 25. I still find that funny. Alright. We'll move on. But you can see it's running, and this is just that app. That's essentially a containerized app. It says local host eighty eighty. So next, I built out some Terraform code, this tofu, and then I do a tofu in it. And you can see that it goes ahead and it grabs the Azure RM module because we're gonna be doing stuff in Azure. And I built out this IAC folder here. So you have the lock file, the functions, the outputs, the providers. This is very cut and dry. Just the functions is where the meat of the... How to deploy... Excuse me, how to deploy this containerized Python app is. And, again, I did use a little bit of the, Google anti gravity to build that out. Now as I did it, right, this is where you can't just vibe code your way to success. I noticed things like it had errors with the Python somehow had defaulted to two o. It need to be three one. And then the way you can do deployment of functions into Azure, you could do kind of a app service plan or Azure functions. So in the end, I did a zip based deployment where we'd zip up the function app at this level and deploy it, and then I could pass the settings like the Ollama host and the model because maybe I wanna change that in the future. I'd like to do it as environment variables. So now I have the Terraform. And because I'm using remote state management and Azure storage, you can see it. Here's my storage container. I've done it before. They're out there, like, from 2020. These things are, like, it scrolled off the screen a bit. It's, like, a 150 k. So it cost me, like, $0 to leave these things in an Azure storage bucket. So now I'm basically gonna do the tofu. So the first thing I do is tofu plan after I've done a tofu in it. And what it's gonna do is read that tofu code, the Terraform code, and tell me what it wants to do. So now when I say tofu apply... Now you don't have to do tofu plan anymore. Apply will do a plan first and ask for confirm. I'm just of the habit of the old style Terraform command line client. Zip ahead a little bit. So it starts to tell me what it's gonna make. So it's gonna make a random string. It's gonna make a random pet storage container, storage account, service plan. And after I've confirmed it is the things I want, I'll go ahead and say yes to apply it. Now one of the things I do as I run this... So a lot of times I do this in an Azure pipeline or a Jenkins pipeline. For this, I'm doing it on the command line because it's pretty easy to do. I will kinda keep an eye out to see if the state file is changing at all. So I'm looking at the date stamp on the, state file. Once we get moving along, because this is Azure, Azure bundles things and resource groups, we can start to see things. I'll skip ahead a little bit here. So as it's building things out, I will start to look at the, Azure portal to check its resource groups to see what it is making. So here I can see it's made in application insights, a log analytics workspace, the storage account, the app service plan, and they're all prefixed there with that that randomized name. Now this one did give an error. It was a very minor typo. Something I learned is that if you have the word prompt in capital letters in your Terraform, because I'm passing that as an environment variable, prompt is also a reserved word in Terraform code, and that was throwing off my plan. So lesson learned. But now it created and it made an app. And so now if we, that was how I debugged it. If we go look at the app, it's now on this... I think there was a link in the things here, but r o j d t something or other randomized azurewebsites.net. Here it is. And it's calling back into my cluster or back into my gaming laptop because I exposed it through my firewall to the, exposed port for Ollama and running this dad joke. I'm not gonna repeat this one because this one's pretty lame, but it does show that I'm doing a callback through an Azure function. And if I want to prove that the Terraforms... The thing that did the work, the tofu is there, I do tofu plan again and see the only thing going on here are some app insights tags. I will point out, should any of you be using Azure for your choice of cloud with functions, if you're using a log workspace, make sure you set your retention policy on there because that can get prohibitively expensive over time. Lessons I've learned, in my life. So that's cool. That's scenario a. We've we've built an app, Python, using an LM, does a dad joke, launched an Azure function. But now I'd like to do something else. I'd like a GCP cloud run instance to show an uptime Kuma monitor to monitor that Azure instance to tell me when it goes down. And because we're gonna do something different, you know, I could have done it with Tofu code. I'm gonna do it with an Ansible playbook. So I'll make an AWS Ansible... Or Ansible playbook to run-in AWS, which is the open source version of Ansible automation, platform. And it's gonna create that playbook. It'll create a public URL, and I wanna make sure I can update it easily and tear it down easily. So these are kind of the the requirements coming into it. So once I made that playbook, I go ahead and I create a project in AWS and I'm pointing to the same git repo on main. And in this one, I could pass some variables. So to the playbook, I have variables like the GCP project. I'm gonna store this in in the password uptime kuma because uptime kuma does have a password. The reason you're... I'm doing it here is if you have your Ansible as public code, which I do, I always like to share my Ansible playbooks, you don't wanna hard code your secrets in there. I just... Even at my old job where we used Ansible a lot, we had, like, a secrets wrapper thing. I hated the idea of secrets being out in a Git repo anybody could see, so I prefer to do variables in here. This is what the Ansible code looks like. Hopefully, that's viewable on your screen. But, basically, I'm just doing a series of g Cloud services command. And because Ansible's running a provisioning step on a known destination host, I can simply do a g cloud auth login application default on that host ahead of time. Now if I was running this on, say, in the febrile cloud instance or on some sort of docker container on a fleet, I might pass a service account JSON file to it and authenticate that way. But I didn't need to because this host is gonna run the Ansible and is already authenticated to g Cloud. So all I'm doing here is doing something like enabling a few APIs like the artifact registries and the Cloud Run instance or Cloud Run API. I'm creating a Google Cloud Storage bucket. I'm doing a a new repository, which is an artifact repository, and that's going to be, the source of Docker Hub. So this is essentially using GAR to proxy Docker Hub, and I'm doing a g cloud run deploy. And I highlighted in yellow here, the LUIS I'm uptime Kuma. I'm using somebody else's container, not mine. Right? So I'm using an open source monitoring container. I simply want to proxy it through Google Artifact Registry. We used to be called GCR, but it's now called g a r, but through g a r, and then run it in Google Cloud. And it's just a few set... Settings in here, like how much memory. One other reason, by the way, I'm using Cloud Run here. There is a reason besides just being a GCP fanboy. Cloud Run instances can run nonstop. So if you wanna have a container running like you used to do in, say, ECR, but you want a containerized instance just to sit there and run and not go away, Cloud Run is a really great way to do that. Basically, creating yourself a... An e two micro that's just running a container, but I don't need the VM. And I do a g cloud services describe at the end so I can get the URL from it because everything's gonna end in a run dot app. So once the output of the Ansible playbook is done, I can see in my output your URLs uptime, Kuma, some random string, .run.app. You know it's cloud run because it ends in .run dot app. So here's the full end. Like, this is the... This is all the pieces together. Here you can see uptime Kuma running, and you see that it was orange to start with because it launched an Azure function, which does go away when you're not using it. Now it's going to ping it, and I could say ping it every minute to see if you're up. And I could set up the notification channels here. You see that I'm in run dot apps. I'm in GCP at the moment right there doing the monitor. Something I realized by looking at my cloud budgets later is that if you have a monitor hit a serverless function every minute, it ceases to be a serverless function. It's just something you're paying for nonstop in Azure because it's always running. It never gets to terminate. So I end up costing myself an extra few bucks per month by just never letting the Azure function die. But But I can keep hitting go and go and go. So here I'm on the Azure website. Again, it's hitting my laptop. And, again, if I... If any of you guys watching this start hitting that URL, I'll hear the gaming laptops fans kick in. So what did we make? Slow down a second. Sorry. I was going fast. What do we make? We looked at two provisioning tools. We looked at, Ansible through AWS. We looked at Terraform by way of OpenTofu, launched interactively, but it could have been just done in a pipeline. And for clouds, we looked at Google Cloud, Cloud Run, and Azure functions. We put all the code in a single repo. It is public. It's out there. It's linked in the in the notes. But we can see that we have the the app itself with the Python to show a silly dad joke, and there's an, IAC repo that has the Terraform code in there. And there's an AWX repo that has the uptime playbook in there. And that was it. So we used an open source git repository, which built and deployed, to Azure functions. We then did our infrastructure as code in the git repo, and, its state file is remote in Azure, so I could jump from one laptop to another just a terraform in it. And, yeah, all open source. How we invoked it, you can see there's your your AWS playbook on the right and your tofu on the left. And then the last thing is kinda monitoring your cost. So as I did this, you know, I was like, oh, that's pretty cheap. $12 a month. I don't mind. Well, very quickly, it starts to go to, like, oh, it's now $13 a month because I was hammering it nonstop on Azure. But still, I think that's a pretty reasonable cost for an app to just be running. Cloud Run's a little more expensive. So this is where, logically speaking, it doesn't make sense to run this as Cloud Run over a long period of time. In a short period of time, for a few days, yes. But for a long period, not because it's a buck $6.78 a day times thirty one days would be 55 US dollars a month. Well, the cheapest instance that would run containers in GCP is closer to $64 a month. But when you add in continuous usage discounts, or you call them CUDs, you can bring that cost down to $40 by just having it running as a VM. So these are things to think about, you know, especially as you go to production. Sometimes a containerized instance that runs all the time makes more sense on just a VM. Right? So always think about your costs over time. As far as migration paths, like, one of the reasons you use open source tooling is if you're... If you feel like, alright. My project's done, but I wanna buy something. I want somebody else to deal with the maintenance of it, the day two stuff. You can go from Git, like a forge show Git to you to GitHub, Git GitLab, Bitbucket. You can go from AWS to, you know, IBM automation platform or space lift. You know, from Tofu locally to space lift m zero or IBM Terraform Cloud. You can go to other choices. I like keeping with standards because it's easy to change. You know... And the last thing, and I like to bring this up a lot, is that, if you use open source standards and you're a person who does like to use generative AI tools, if you're of that type, you can get a lot of help easily. You can ask the tools because it's a standard language that things know how to help you. Here's how it would look if we migrated to space. So I just kinda wanna show it. So here's some of my Ansel playbooks that ran in space. So I've seen here some of my Terraform. I do wanna show what the commercial side looks like. And that's that's about it. So, again, the GitHub repo is out there in Forgo, I think, because the link is really long. Garrett did a nice job putting a link in the notes. And there's the Azure function, which will be live for another day before I save some money and turn it off, and you can reach me. So thank you so much for your time. If there's any questions, happy to answer them. Yeah. Thank you, Isaac. We did get some questions, so let me, pull this up. Are you able to stop sharing your screen real quick? Absolutely. Yeah. You'll be stopped sharing. this. Alright. So, someone did ask if this was being recorded. Yep. It's being recorded. It'll be sent out, this afternoon, with the recording so you can watch it. And we'll put it up on the ICConf YouTube channel, later this week or next week as well. So one question here. Someone was asking about pyinfra. Have you used this tool? And know was earlier. on in your in your presentation. I haven't heard of... I I see it's a... An agentless, infrastructure tool written in Python. I see no reason why I wouldn't. I think part of the reason I lean in on things like Tofu and Terraform is there's a lot of modules and examples out there to make it really easy. I mean, another case in point is I love Crossplane as an idea. So Crossplane allows you to create your infrastructure as a provider inside your Kubernetes cluster, But it's not as common, so figuring out syntax on unique things becomes a bit more challenging. I probably will check out pyinfra, but I have not used pyinfra, for any of my projects. What... Just bringing up? bullets for, we did... There is ICconf back in May '25. We had someone do a a session specifically on... And cross plane and their experience with it. I just dropped that in the chat if, that is a popular one that comes up, and I think it creates a lot of discussion. So that that was an interesting session if you do have questions on on Crossplane. Alright. So let's do this next one here. So I did ask in the chat if there are any OpenTofu users. There's... Get some good response. Somebody asked, are there specific features of OpenTofu that you particularly like and why you prefer that tool maybe over some others? I like, OpenTofu because I kinda cut my teeth on Terraform. It's been around a long time, and I think a lot of us know that syntactically. There's also a lot of Terraform modules out there, so it's very easy to use. And, you know, one of the gifts... I'm gonna use that word, yeah, gifts that HashiCorp gave us before they got acquired is they put out some Hashi skills, and GitHub is, AI skills that are really, really good. So if you grab those Hashi skills and then point it at your tofu code code and run the kind of the Terraform skill to review it, it can do an amazing job. You know, I'm gonna speak for myself, cleaning up my crappy code. So I've used some of those AI skills for for cleaning up my code. Nice. Yeah. It's kinda the main reason. Alright. Cool. Let's see here. Another question on OpenTofu. In your opinion, how difficult is it to migrate a well established Terraform project to OpenTofu? I found it to be easy. My last company we were at, we were big Terraform enterprise users, and we moved to Space Lift, which is tofu based, and we didn't have any troubles. I think the only troubles were maybe on some permissions boundaries about who has what permission to... What repo or project because Terraform can get all fancy pants if your IT group is, restrictive. But from a language perspective, I didn't have any issues switching from one to the other. But, also, we held ourselves to, not make our Terraform code too complicated because it's... Okay. Except for one guy. But with the exception of this one guy, everybody else kept their Terraform very easy to read. If you wanna get fancy and have modules that abstract from modules that derive from modules, it doesn't matter whether you're in Terraform or Tofu. That's gonna be, an unpleasant day when you have to update that. Yeah. Alright. Cool. And then, yeah, if if you guys have more questions, just drop them in. We've we've got some time here to go through them. There was a question here about another open source tool, and if you've tried this one called, Forme, which I believe is from Platform Engineering Labs. No. I'm not familiar with Forme. I had heard of py... PyenTra before, but I haven't heard of Forme. Just... I'll have to take a look at it. Yeah. Always new ones coming up. Yeah. Actually... And I just thought of another reason why I tend not to use crossplane. Because it's more of a DSC, it would always catch me up. And because I'm a sloppy person, remember the whole thing about Larry Wall, and I'm like, oh, yeah. I forgot to add Abby to an Azure Key Vault access policy. Well, Crossplane didn't go fix it back for me. So I was like, I don't want you to be that proactive. I kinda like having Tofu code that I'm like, Friday will be the day I do a plan. Oh, crap. I forgot about this. I should go look at that before I delete it. So that was another reason I liked Tofu over crossplane is it's it's good that way. In fact, I do it... Gosh. I do it all the time because we have a bunch of stuff in Azure. And when you have people leave the company in Azure, they kinda, like, disappear. They're unpersoned. I'd make comments for their user, OID, right, from Azure AD, from AAD or intra ID. So I'm like, if you ever see this name again, that's Jim Smith, who's no longer here. Because then I'll find some sort of error somewhere that says this Azure entity has an access. I'm like, oh, yeah. Let me go look at my variables file. That was Jim Smith who left last Thursday. So that's also that could, be it? Yeah. I feel like that could be a good session just in general. It's like top... 10 top tricks for, making sure you don't lose knowledge when people leave a company. So true. So true. Alright. Redford here, asks, how do you see a city for IAC? Do you run your tariff from applies from tags or artifacts? My pipelines tend to be either, GitHub actions or Azure DevOps. I lean into Azure DevOps because I like to have gates. So what I do is I will have a ter... An Azure DevOps pipeline, That's what I have today that runs my tofu code for provisioning against a already merged to main branch, and then it does a plan and shows the, planned artifacts. So there's a PR policy that'll run against your your candidate. Right? So that'll tell you what the plan will be. But but after we merge, still on the main line in case there was drift, it'll run a plan and show the output. And then I have a a gate, an approval gate so that the idea is here, even if the pipeline was approved and even though we know the Terraform, somebody should eyeball scan the output to see did something change between, you know, yesterday when you approved the PR and right now when I'm running it. So I tend to run it off of a mainline branch, and I tend to have gates on my CICD to double check it. Does that answer the question? Yeah. Redford, if you have any more comments, you can drop right in the chat. He did have one other question which I'll I'll bring up here. Is, have you played around with the Azure service operator? And, yes, that did answer his question. So thank you. Okay. I have not used the Azure service operator. There's also a new thing that they moved from arm to bicep, and I haven't looked at bicep templates either. But a lot of what I'm doing... Again, where you do your stuff. When I do infrastructure as code at the level of tofu, I am building up the most basic layer. I am building the storage accounts, the AKS, the ACR, the, AKV and its access policies. It's it's just the guts of the cluster. And the moment I'm doing anything like launching an app, I'm doing Helm charts. I'm doing GitOps to do, like, an Argo CD setup to deploy out of GitHub. So there's a thing that I think we can do is... Especially people who are operations people, SREs, DevOps, whatever you wanna call yourselves that do this kind of thing, We can be, like, so excited about TOFU. We're like, oh, I have a provision that'll launch this and then do a helm deploy, and I'll use the helm operator inside a Terraform code. And, always think about what is basically the platform, the thing that needs to happen now, and what are the things that are gonna be iterating on through your development teams because they really don't belong in your infrastructure as code. If it's things like deployment of of containers, set that aside as things for provisioning tools and for pipelines. But... No. I'll I'll check out the, sorry. Sorry to riff on that. I'll check out the Azure. service operator v two. I have not. Alright. Great. Alright. Thanks everybody for the questions. Those were, the questions, that came into the chat. Just to close-up here, I mentioned I'd just share a bit more about what's coming up for ISC Conf. So the next, event that we're hosting for the community is at QCon, in Salt Lake City, on the Monday evening. You can scan the QR code or I've just put the link to register, in the chat. So if you're gonna be out in Salt Lake for this event, please join us. It's at a it's at a fun venue. It's, they do, like, simulators, so you have, like, soccer, golf, baseball. We did it there a couple years ago, and it's a great venue. So get to meet some people from Salt Lake in the, you know, IC community as well as those people attending KubeCon. So, hopefully, some of you can join that. We'll we'll be doing more of these virtual sessions, probably another one in in December, and then we'll be gearing up for the ICConf annual event in May 2027, and we'll be opening the call for presenters for that, within the next, month and a half, likely just after re:Invent, so in mid December. So definitely keep an eye out for that. If you wanna do a presentation just like Isaac has done today, we're always looking for new speakers. Again, the the biggest thing we hear from the community is people wanna hear what other people are building, real life scenarios. So if you've got something like that, definitely, put your hat in the ring because that's what people wanna hear. Isaac, thank you very much. Awesome job today. Thank you. everybody for, attending, and we will see you on the next one. See you, everybody.