 All right, so from config management to infrastructure as code, and now CDK, as with all things in cloud native, even our IAC landscape is continuously moving target. It's past year alone, saw seismic shake up with the changing of the most popular tools licensing, Terraform, to a source available license. This was a catalyst for the forking of the open source Terraform project, Open Tofu, which was contributed to the Linux foundation and soon to the CNCF, which end of zero are one of the early and supporting full-time engineers on that project. But this ecosystem itself has seen its fair share of shifts and changes from on-prem to cloud serverless Kubernetes and everything else, and you can find a lot of interesting data on these trends in the IAC report from Firefly, you should check it out. And there are myriad tools, languages, methods for deploying technologies, and so that is why I have invited this esteemed panel of experts to help us unpack all this, how all these IAC changes have impacted our workloads, our cloud native operations directly, we'll explore and pontificate a little bit on what's coming next in the world of IAC, cloud native ecosystem where this meets the ICD, the worlds of Solomon, and even incident management and things like that, and where new developments are coming into play, open source trials and tribulations, challenges we still need to overcome, and you are most welcome to grill our panelists, that's what they're here for, so don't be ashamed to ask your own questions, we'd love to have audience participation and have you all kind of join in on the discussion, this is what it's for, this is when we bring the community together to actually ask and learn together, so without further ado, I would like to introduce our excellent panel here, we'll allow each of them to say a word about themselves and kind of what they love or hate about the IAC ecosystem, so we'll kick it off with you Mandy. Okay, yeah, great to see everybody today, oh my gosh, so I'm Mandy Walls, I'm currently a DevOps advocate at PagerDuty, I'm here though because I spent eight years at Chef before I started at PagerDuty, so been working in this space for a very long time, so excited to talk with you about what we've seen, what we've yet to see and what we hope to see. Hello, my name is Aran Bibi, I'm the co-founder and chief product officer at Firefly, in Firefly we are helping teams to get better control over the cloud and accelerate IAC adoption, and I will be here to share some of the insights that we found in the report that we recently released about the state of the IAC. So my name is Bonnie Franci, I'm a director of engineering at NF0, and at NF0 we do, we help you govern and deploy and scale your infrastructure as code, any kind of infrastructure as code at scale and with confidence, and I'm really here actually as one of the founding members of Open Tofu, we're here to kind of fill the pulse of the community we've had our first Open Tofu day yesterday, which was very, very exciting, and that's it, we're here to kind of hear how everybody feels. Hi, I'm Solomon, I'm the co-founder of Dagger, and we do CI pipelines as code, and actually we're discovering in this conference that people are using us for all sorts of pipelines as code, not just CI, which I think is scary and also interesting, and Docker before that, and yeah, I love the trend of everything as code, so let's turn everything into code. Yes, so yeah, so fine lineup here, quite a roster, so definitely tap into them if you have any questions, but yeah, let's get started. So wow, big year in the IAC space, this year was actually 30 years to the OG CF engine, who here has used CF engine in their lifetime, we've come a long way since CF engine, but also the year that the poster child terraform changed its license and all that, and the consequent fork, Chef has moved on from the world and a few other things, well not really, but kind of, and then we also have Docker that's evolved over time for open tofu, let's unpack this decade I guess of the IAC revolution kind of you know, like highlight the things that to you were like the most important milestones I guess, and the things that kind of changed the game in a sense. Yeah, okay, so I can't go back 30 years, I have used CF engine but only painfully, and yeah, I think over the past 10 years-ish starting post CF engine, Puppet and then Chef came in and we decided to have a programming language in a DSL versus like straight up like proprietary config language and that sort of changed things there. We also had a license split, like if you weren't a part of the Chef community at that time, there's still an open source fork of Chef called the sync project and those folks are are still pretty active, I talked to some of them last week at scale in Pasadena, so like everything old is new again, things maybe don't repeat but they rhyme and yeah, and we see now that I work at PagerDuty, we're sort of part of your tangential infrastructure and we see a lot of our largest customers relying on terraform to configure all their components even though we're not necessarily infrastructure but we really are infrastructure for that, so. I can share what we see in the recent report that the landscape is fragmented and we see a lot of people that are considering shifting between the current ISC that they are using into new ISC framework, so noticeable stuff will be people considering to adopt crossplane and also moving from terraform to open tofu or really I think one of the challenges in that specific ecosystem of other ISC is that there is a lot of tools but the community is still evolving so it's not like there is a consolidation, there is a fragmentation and I think this is one of the biggest challenges in managing cloud right now that we you have teams that are choosing the right tool but other teams within the same organization maybe taking a different approach, a different tool, a different concept and we see that being a trend in the industry right now. So yeah I very much relate to that, I think well first of all we've come a long way right from body of scripts which are completely stateless to managing our infrastructure and then kind of sharing those scripts and recipes and then evolving into a stateful deployment that is owned by a proprietary cloud or another and then something that evolves into much more than that with terraform and we see back from kind of going back from declarative code into imperative code again via CDK so we see all sorts of changing tides coming back and forth and we see that within teams, we see that between different companies and I think I very much relate to something I've also heard you say in one of your podcasts that kind of think that used to be in pass before Docker which kind of notion you had was you need to kind of separate the platform from the actual container right so not kind of solve two things at once and kind of focus on trying to be able to support the different preferences people have as to how they want to govern and manage their infrastructure so that's interesting. Yeah I you've talked about CF engine that that was a blast from the past really yeah 30 years yeah I mean it's funny because I didn't expect Docker to be relevant in this conversation but I mean I started out my starting point was being inspired by configuration management and the idea that you could sort of write down what you want your server to be you know describe the state that you want and then it would just happen and then cloud was just barely starting to happen right and you had CF engine puppet and but puppet was very server centric and I think you guys at chef were the first to say this DevOps cloud thing you know let's let's try to build a tool that's native to that you know and and that I mean so much happened and there's a lot of big events but I mean more recently what I'm excited about is that I think we're sort of figuring out that niche custom DSLs are great to start but at some point you need to go where the biggest ecosystems are you know the biggest ecosystem wins and mainstream languages just have the biggest ecosystems so if you can find a way to fit and connect to those ecosystems everything just sort of becomes easier you know because you're solving a problem together with a larger group of people so we went through that transition at dagger we started out with a DSL and then you know we're forced to go to mainstream languages because people wanted to use that so I yeah I feel like now the APIs are becoming powerful enough that you can you can you can actually do that and the state part I mean we don't have states you know so I'm I feel lucky in that way because state is a pain so we'll do the stateless pipeline you know pipelines and everyone else can figure out the really difficult state management part that's my strategy yeah so it's good that you touched on that you know the difference between a good question and a great question it's uh when it's in the presentation it's a good question but when it's the next question it's a great segue so on that note I was actually going to ask about like kind of the trend towards a cdk and programming language as infrastructure is actual code and not just uh their own domain specific language do we see does the world of cloud uh need a specific language I mean we've seen historically things like a dark lang that tried to actually be a cloud native programming language wing cloud out of televiv is doing the same sort of thing uh and I'm wondering do we need a cloud specific cloud native language to to rule them all do we want to just migrate over to programming languages and forget the whole dsl format what do you think is going to be the winner in all of this shake up I'm say yamal no please wrong yeah that was on purpose um and and I will say that because um I have a lot of ptsd about trying to teach people just enough ruby for chef and and then talking to our customers who are like hey we wrote this thing to turn yamal into terraform that then talks to our apis and all this stuff can we take it from us and maintain it because we don't want to maintain it um I think there's a certain amount of exhaustion among especially application engineers for specialized tools and the ability to the desire to abstract a lot of that stuff away from the frontline engineers is very very prominent right now especially with our largest customers I got a lot of shaking heads like you're probably seeing this especially if you have very very large engineering organizations no one wants to spend time across 20 000 engineers teaching everybody yet another tool and like we're seeing a lot of that pushback with our larger customers as well like they're just people are exhausted and they're tired of learning little bits of pieces just to address one component of their infrastructure or one component of their job um so I'm encouraged by all these other meta tools and other things that are going on that um we can pull folks back out of that and get them back into the innovation and creativity and service of the customer and not in service of addressing the infrastructure yep I definitely can agree with that I think it's really about how you are structuring the responsibility within the organization whether the actual developers are responsible for cloud infrastructure or you have a central team like the platform team or a DevOps team that is doing that for them or abstracting and providing those self-service flows so if it will be developer definitely the developer will prefer a common language but what I see right now is again a shift where developer is less responsible for the provisioning and this is being abstracted for them so the platform team really can decide whether they use YAML or they use other type of language in order to provision and maybe this is the way moving forward and again I agree people don't like to learn more and more languages and there is a barrier of skills and usually this is what is being considered as the way to do in a specific account so I very much relate to that I think it really all boils down to your organizational structure right who owns this this piece of code and who who should be maintaining it and what level of obstruction you want to offer we've seen all kinds of paradigm shifts right I mean cross plane is one which you've mentioned YAML I mean whoever uses cross plane thought it was a good idea to use that and and it's probably because organizations who use heavily used Kubernetes are very much used to that language and all right that's one less thing to learn and it also can be told about Go or TypeScript or JavaScript or Rust or whatever language or CDK supports right so in that sense it really depends on who your target audience is right and I think that's a good thing that you can actually support them all and let the organization decide how they want it to be structured right and what level of structure they want to offer if they want to own more of the coding side on the developer side or actually more of a less more an abstraction and more familiar tools in the DevOps world yeah I I think all that's true I also think the the DevOps and infrastructure community when it comes to ecosystems is thinking too small because we're we're so used as a community to the platform we're not really used to real platforms anymore because if you dig through the layers of scripts in YAML it's still Linux you know and bash I guess you know it's bash on Linux and everything else is just glue around it and that's been true since CF engine it hasn't really changed and and so I think we're we're doing a great job at solving the problems that don't really need a new platform and that's the problems we're talking about like provisioning provisioning the cluster provisioning the buckets you know some some gluing together but as soon as you it becomes pipelines of course you know I see pipelines everywhere now so sorry it's biased but you know provisioning the stuff in in Terraform is kind of the easy part now uh then you got to glue everything into that because you need the application to get on there and you need to build 10 different pieces and run integration tests and all that all that glue and sometimes you try to do to do that glue with Terraform or whatever infrastructure tool you're using um and that usually it not only goes so far because it's not really made for that and then or same thing for communities operators like you can only do so much composition of operators you know so I I'm sure some people in the room disagree but I think sometimes the answer is well communities is the platform no it's it's not a thing to program I mean you can extend communities but um if you want to know what a real platform is you go as developers you know like iOS is a platform Java is a platform uh we just need we need platforms like that it's just really hard to do uh and it requires um like you know you got it when you can write real code in a regular language and the you know the API docs make sense you know and the SDKs make sense it is a really hard problem to solve I think I credit Pulumi a lot for pushing you know building momentum in that direction um it's just I don't think we're there yet it's it's um yeah it's it's hard to do but my point is simply that we have to remember that we're not there we have to set the bar higher because a bunch of scripts gluing Terraform and 30 other tools together uh that's not the like it's not supposed to be like that you know we gotta we got some work to do yeah yeah that's actually a good point that's a good direction I actually did want to touch a little bit more on the Terraform and open TOEFL but we'll come back to that in a minute but you touched on something you keep bringing back to other things but uh let's talk about abstractions for the cloud like I think that that's what you're getting at in that there's so much complexity you talked about the complexity and the fragmentation and that in the report it just is getting worse and harder and and eventually infrastructure is supposed to just you know serve a higher order goal right and there shouldn't have to be so much work and complexity at just having your infrastructure run so let's unpack that a little bit and why we're failing at the whole abstraction for the cloud part and making it a lot easier maybe I can share that as I see it it's not just about putting infrastructure in the cloud it sounds easy you have access you do some click ops you have stuff but in the real life you need to make sure everything is in the right governance and it's not a policy violation from a security perspective or even from cost perspective and you need to make sure that you have that blueprint so you can replicate it so there is a real need to make sure that you have that template in place and it probably modifies the way that your organization allows to put infrastructure and this is one of the item that makes stuff more complicated so it's not just writing a manifest and then everybody can use it you need to make sure that manifest is whitelisted and approved and you have that pipeline that is making sure that it's okay to provision and give you the thumbs up and this is okay to go to the cloud and to make it right and to make it consistent you need to have a very good framework and discipline and somebody to really care that this is how stuff need to be done in your organization yeah so I think that's very true I mean configuration at the end of the day is is terraform and those kind of languages are not just about deploying infrastructure we're seeing providers for page duty and we're seeing providers for pretty much anything else so yeah the easy part is deploying infrastructure but there's there's more than that there is configuration infrastructure that you want to maintain the way you deliver it right you want to maintain a certain policy in the organization that can be different in different teams in the organization and could be exclusive to everyone so different configuration different policies different governance at the very organization level are very very important beyond just infrastructure and yes it's true at the end they want to deliver applications but there is so much around them that really much revolves around the same paradigm which I think is where these these kind of tools shine best yeah that's good to say too vendor lock-in right like all the vendors have their preferences they want to keep you around and keep you paying their bills for them so pushing you to a place where your switching costs are increasing because you have invested a whole lot of resources into addressing their particular end points is super important for them right but also like looking at that looking at some of the apis that are present in the industry and in the marketplace for cloud in particular some of them are an absolute nightmare right and you think about apis have been around forever but as a disciplined practice and as part of the product management of the products apis feel very nascent like they feel very infantile in a lot of places where product folks are just now thinking about them as sort of a first class part of the product so that you're only just now starting to get consistency and predictability and the kind of behaviors you're expecting out of those end points so I feel like we're at an infancy part of this sort of like getting to better ways to address all of these complex structures because the product just hasn't been there it hasn't been part of the discipline I sense that you have input on the things that Iran would talk about a little bit about the workflows and the yeah yeah I think I you made me think about a few things like the I think that is one huge potential benefit of turning all of this mess into code once you have code you can start open sourcing some of that code and and then you can have a commoditization process where some some things that you're that are black boxes proprietary services that you're paying a lot of money for usually there's a core that's really difficult to do and it makes sense to to pay someone else to do it but then you need to expand the subscription you need to add value and so you have all these additional satellite features that come with the black box you know an example that I'm familiar with because I see it all the time you know is a deployment service they host your application that's great but they also build for you but maybe the build is a little extra you know and then you think well I can build my stuff but you know it kind of comes together and then if if you can you can implement your own build logic but it's going to be a bunch of scripts but if you know as apis appear that allow you to express more and more of your workflow in your stack as codes then from there you can say hey I wrote the code who wants to use it and I think it's a natural pushback against the expanding black boxes and it kind of reminds me of the early days of linux you know when I mean red hat was the catalyst for this you had a lot of proprietary unix systems and and then linux appeared and red hat sort of created the packaging ecosystem the platform around it to say you know what we're going to open source a lot of stuff that used to be very expensive now you know and the adoption of that platform the red hat platform I think now we tend to forget a lot of it was cost reduction it was the buyers pushing back against proprietary vendors so I think that's the opportunity now you know turn all that into code and then we can start pushing back a little bit okay but I'm going to bring us back to our original topic of infrastructure as code specifically no no what's happening in this ecosystem right now because I still think there's a lot to unpack there so first of all I just recently read an article from ohad may switch the CEO and co-founder and zero about how he spoke about the terraform binary becoming maybe the HTTP for I see now that there are two variants in a sense and and they have become kind of the most popularly de facto adopted kind of way of configuring and provisioning infrastructure what do you think about this about these two competing and complementary in a sense almost formats of running infrastructure as code and also how it's going to play out for other industry players who aren't kind of aligned with that syntax and like Pulumi and crossplane and the others that you and yeah so so as I said I feel like there's a constant shifting of the tights right we that there was there's a there's a great promise in in terraform and what it does and what they deliver and we can see that you can see that Pulumi also has support for terraform providers we can also see that in even in crossplane right so it it kind of almost as if terraform providers are now used in open tofu in terraform in crossplane in Pulumi so that that that's a that's a big deal right that means that something in that contract role works really well for several technologies and you mentioned something about vendor locking which I think is very important to say right at the end at the end of the day and you also mentioned it in the sense of choosing a a commodity programming language I think what the important part is you choose something that will make sure that whatever you write you can deploy it and you can govern it and manage it manage it and you can eject from one vendor to another whether it be a type script or something else or but so long as the technology allows you to lift and shift between different offerings and different platforms and you can deploy this code in really any way you like in any provider or vendor or platform that allows you the best value and the best value for your dollar then yes absolutely that'd be the one I would choose so it's interesting as as we spiral around between very declarative language that starts to pick up some imperative thoughts and then back to imperative languages who who start governing then another twist around to the declarative language with yarmals so that's fine I mean everybody has their preference so long as you can lift and shift I think that's that's key and yes in the end of the day we also see a collision between these words where providers are used on very different platforms so yeah that's that's my opinion on that maybe to add something about specifically the dilemma between you know terraform and open tofu that was basically open top was split out with terraform I think the migration effort between IAC tools is something that always need to be considered as a significant effort and people that are now in that dilemma whether to adopt open tofu or not as I see it I think this is the time to make that decision it will be easier to migrate and choose the right path for you now because they are relatively very similar but moving forward when the community will take open tofu into another path I guess it will be a different type of tools correct me if I wrong yeah so right now there is no migration path right it's just a drop in replacement so you can go ahead and try it it's relatively easy but let's say let's say like two years from now four years from now I will assume you will never know but I will assume it will be two different tools and the migration if you will take the time to take the decision will be harder and more time consuming so there is that dimension of taking action right now this is what I think this is what I suggest for companies that are asking me about open tofu whether I should adopt I'm just pushing them to really evaluate evaluate that decision in the near time frame because it will be harder to take a decision later on so I think it's very true and like I said right now it's a very it's simply a drop in replacement and the key part is you you really get to choose you get to choose you get to turn back if you want to we really keep an eye on that and we want the tools to evolve right now in ways that we offer additional opt-in features right nothing that will ever break compatibility and like I said providers are used in so many different ways beyond open tofu and terra from so you know you're safe there right otherwise it'd be a completely different complete different story so yeah that's a good point were you asking about declarative versus imperative at some point go right ahead favorite we're gonna go rogue no no by all means I feel like I'm asking the question for you no no good I'm actually interested but you have to say about that no because at some point you guys were talking about choosing one model versus the other and the back and forth um yeah I think what one thing we've seen is choosing imperative languages but then not having uh the underlying apis to support it in our world we have Jenkins and groovy and so when we say hey we do see eye as code we'll say okay I've done that before where that road leads you know madness but but but I think in that case the problem is there is no declarative api underneath the good example is if you write a web application in php or any imperative language you're gonna make queries your data in sql which is a declarative language you know so that I think that's the right model you know the the hybrid of an imperative language that lets you query declarative apis I think in the long run wins my opinion because you get kind of the best of both worlds right so interesting do you have any thoughts I don't want to go imperative during this declarative I feel like I'm back in like 2008 we have had that discussion so many times but like I'm glad you still love it it's amazing I'm listening about the open tofu stuff though because like the we have a fork like that like you can't assume that whatever the corporate entity is going to do is going to stay static forever and we probably all seen in the news the past couple weeks some of the tremors about what's going on with with hashi and what question right who knows right if they get bought if their structure changes or any of those kinds of things that could impact things downstream now in the long term it's better for hashi to keep an eye on open tofu and see what's going on there what's popular see what they could pull in what their product managers missed that the community has taken the effort to implement themselves to say oh yeah this was something we probably should have looked at and pull that stuff back through it's almost gonna be like an inception like a terraform distribution of itself yeah well that'd be interesting um yeah but I mean our focus really was to begin with we keep saying four but it's it's really to preserve the preserve terraform is open source right and preserve people's ability to to influence on it as well we've we've very recently added a feature that was very much a high demand one in terraform for a while you know secrets sitting in your state in plain text it's kind of a big deal and so we were able to actually push things like that forward or actually not us it's the community actually was able to actually get behind such a pull request and push it forward so we're very humbled by the support we've gotten and we actually see how it can positively affect that project and I'm sure we'll see the same of kind of affecting terraform right back and forth yeah absolutely like that's one of those features that's like from an enterprise software perspective like it's something that everybody wants but nobody wants to actually say they want to pay for so while it takes a bunch of resources to implement it on the corporate side like you don't have the justification for it because it doesn't add to to your pipeline to your licenses so like it's then you get this like proof of value from right directly from the community like hey we really want this even though you don't want to build it for us and I think this kind of thing can only happen when the project really is owned by a foundation and not by a commercial entity I mean we're in zero we don't own this project it's a little foundation who do there are other commercial vendors behind it there are other open source spread vendors behind it but everybody kind of pushes there in a certain way but Linux Foundation kind of enforces us to sit down as a committee and make sure that what's being done is done by the community and being published to be very transparent about it so that's that's very good by the way you mentioned you mentioned the the inception you know hashi corp being a distribution of itself yeah open tofu maybe and maybe they could have done that themselves that that's kind of how we all got here with Docker being its own right I mean the CNCF started out as the open tofu of Docker right we spun out Runci and OCI we spun out container D and a few others but I mean container D turned out to be the most important and I mean that was a very happy transition container D is a very successful project it's exactly like you know open tofu it's not the whole product it's a component but Docker to this day is a happy downstream distribution of container D you know and it's so much better that way so maybe we should have done it earlier this is going to be my last question and I'm happy to see if anybody else wants to chime in and ask some questions but uh so it's funny kind of another inception but I listened to the IAC podcast about the IAC report the state of IAC report um and one of the things that one of the data points that was actually interesting to me was kind of this trend of migration away from the the traditional tools the terraform and the cloud formations etc and then I guess the most controversial question of them all is uh was this miscalculation on hashi corp's part and we're also hearing that the buzz of maybe looking for you know um buyer and uh you know moving on I don't know uh so I'm wondering what are your thoughts on how this might play out and uh right move wrong move it's hard to say but I just wondering it's it's hard to say uh right now I think it's too soon uh to see whether existing customers of hashi corp will take a different path and um I think they uh well considered all of the options by doing this movie including uh people getting upset about uh that specific action of them but eventually this is you know a corporate decision and um I think in one or two years from now it will be very clear whether they did the right decision or not commercially again for them I think eventually for the community with having open tofu uh came to life uh it's good to the community and is it backed by um the lynx foundation so it's now free from any risk of being uh closed uh in the future uh so right right now we have that dilemma whether to migrate or not it's a it's a pain I know but eventually for the long term as you mentioned uh features that was highly requested by the community now being accepted and implemented so I will consider that a good news for the community and not very sure about how ashi will the future of ashi will be on that specific topic I so I don't really have an opinion on whether it's good or bad for hashi corp but it it's been very helpful for me because we have an open source engine and we have a commercial strategy that involves not changing the license it's a pain to do it you don't have to red hat didn't have to anyway so we that's our model and I don't think we'll ever change it I think it'll be very successful but the one question I can't answer is what if you change your mind later you know what if you get bought what if you get fired and a new CEO comes in and changes the plan you know I can't really answer that you know because I can't tell you I can't tell you the future but now I can say well that's what happened with ashi corp and it was it went fine right and got forts there's a foundation so you know if we do that in the future I guess that's what will happen so you'll be fine so it's actually very helpful as an answer to that what if question you know that it played out okay so thank you they chanced it and they put their neck out and everyone else now has a better answer about that that's great uh any questions from the uh from the audience for this esteemed panel of experts anyone how much time how do we how are we doing on time we need to wrap up or time's up is that a time's up sign do I have one more question yeah okay so bonus question since uh we can't have a panel on a on uh I see without asking about AI the future game changer is it going to change the way uh we work is it going to free up engineers to do higher order things is it a high cycle uh for now I think it's a very good shortcut again if everything is described as code and AI can generate code so you can generate infrastructure as code and uh the most popular models are doing a decent job of course there is always the lag between the latest and greatest and new resources uh that been introduced into terraform for example are not uh available in the AI models so there is a lag however I think it's a great shortcut and we also see that in the report when we ask how people provisioning and creating new manifest so AI was one of the answers and I think this trend going to be popular and we also talked about the skills gaps so I think this is another way to reduce the skill gaps everybody can you know use natural language to ask for a manifest for an EKS cluster and he will get something that is I guess close enough for uh uh being used this is my fault so I see it as as a catalyst really because at the end of the day I mean we've said infrastructure as code is so great because and I'm saying saying this from an engineer perspective who kind of made some transition I was able to see wait but so of course you have to have your your um your changes be governed by Git and you have to have approval flows and you have to have this transparency and you have to have the ability to roll back and you have to have all of these things that are very commodity and basic and for anyone who's coding for for a while and then to learn that infrastructure is not it was not managed like that for a long while was okay that's a that's a surprise so um here's another thing we can we can basically earn now um we all all of us in the coding world we use AI all the time as with co-pilot and and things like that to help us out there's obviously a great reason to use it with uh any kind of code we're of course being it a commodity coding language a programming language uh but not just right so yeah yeah I I kind of agree like especially for small and medium sized organizations like it's going to be the most helpful I think when you get to scale and have a lot of engineers you're going to get more benefit and more control and compliance and those kinds of things by maybe doubling down on an actual platform practice if anybody wants a platform engineering day on the first day and and and those kinds of of um projects like piling up those kinds of teams um to go pave the golden path for people so that you're not just downloading or predictive texting your way into infrastructure that may or may not meet your compliance and regulation needs just making sure that everybody is following the path that they're supposed to and putting your resources there rather than hoping you're going to pull stuff off the internet that works right any concerns about quality always yeah always absolutely like are we gonna wake up in five years with like tons of like garbage code and uh we already have that but we got it from stack overflow instead of co-pilot so I stack over for a keyboard of copying pacing right I think actually that the so there's all of that 100% you know oh it's code oh it can generate the code wait what what does that generate code but it's going to get better I'm sure but I think we're we're we're also underestimating generating code is the obvious one uh there's the counterpart also hey this this DSL is terrible but chat GPT can generate it so maybe I don't need regular code so I think for a while I was worried that you know gen AI was going to slow down the adoption of uh you know the switch to mainstream programming languages because it's less urgently needed but I think actually that's there's so many other reasons like we talked about but separately from all that I think one one amazing feature of gen AI that that's being slept on is function calls you know the whole agents thing for now it only works really well with GPT for the open models are not really caught up but it it it works really well I think everyone's going to catch up and you don't need to generate code you can hook up these function calls to apis and then you can have the lm do things on your infrastructure without having to go through generating code I think that will work better for a lot of the stuff we're talking about yeah sure a little break still but okay it looks like we're out of time lights are up so thank you all for joining us