Is infrastructure as code now widely adopted?

Most organizations that are doing infrastructure, especially those using cloud infrastructure, are using infrastructure as code tools.

Now, how they're using it, how effectively they're using it is a different matter.

How come even though we have cloud now, things are still kind of like still complex?

Code is kind of a painful way to work with, storing it in your Git repositories and all that kind of stuff.

Why didn't cloud magically make it, so we can just have infrastructure when we need it and how we need it?

Kief Morris is a Distinguished Engineer at ThoughtWorks, best known for his foundational book, "Infrastructure as Code".

And Kief is back today to talk about the same book.

But you know what, it's been in the third edition now.

People working on infrastructure are kind of like, well, it's plumbing, right?

It's often very disconnected, right?

Business folks, "This is not what our business is, right?

Our business is not infrastructure." They're very frustrated by finding that infrastructure and environments, and all that kind of stuff is kind of a bottleneck.

It's kind of a friction point.

What about AI in infrastructure as code space?

So what do you see the trends coming?

I don't think you wanna vibe code your infrastructure.

You need to understand what's going on there.

If you're using AI to kind of create infrastructure for you, or you create infrastructure code for you, having that knowledge, it's important to get the levels right.

And I still hear an organization where the people were saying, "We can't automate this task because it's too sensitive, it's too compliance and stuff.

We can't trust the automatedness." You trust humans, instead?

Rather than saying, "We're gonna go slow and carefully inspect everything".

And that's how we're gonna get good governance.

In order to go fast, we have to get rid of governance.

Actually, you can have both.

That's the secret sauce.

Hello, guys.

Welcome back to another new episode of the Tech Lead Journal podcast.

I'm very excited today to have another repeat guest.

Today, I have Kief Morris with me.

If you are a long time Tech Lead Journal listeners, you probably still remember Kief actually appeared in episode number five.

That was almost like five years ago.

So it's been a long, long time since our last conversation.

And Kief is back today to talk about the same book that we talked about last time, Infrastructure as Code.

But you know what, it's been in the third edition now.

So when we talked back then, it was in the first edition.

The second edition is kind of like up and coming.

And now we are in the third edition.

So hopefully we are gonna cover a lot of things that have changed in the infrastructure as code world and what are the things, the important things that we can learn from the new book.

So Kief, welcome back to the show.

Really excited to have you.

Yeah, thanks a lot, Henry.

I'm glad to be here.

It was fun being in the early days of the podcast, so it's really, it's really cool to be back now that it's been going strong for so long.

Right.

Kief, maybe if you can, uh, just give us a little bit of, I don't know, like updates, what have you been up to in the last four to five years since our last conversation?

Anything interesting that you have been working lately?

Sure.

Um, so yeah, so I'm still at ThoughtWorks.

I've been and still in London.

So I think my role has kind of evolved a bit as the company has grown.

I'm now what's called a distinguished engineer.

So basically my role, I get involved in projects.

I get involved in talking to potential clients, existing clients, people outside, partners.

Basically, it's all about, for me, it's all about exploring ideas, finding out about how people are doing things, what they're learning, and sharing that around.

So yeah, I've really been enjoying that, 'cause it's just given me the opportunity to get involved with a lot of different teams and different situations.

Right.

So now your title is kind of like Distinguished Infra E ngineer, right?

Distinguished Engineer.

I know that in some companies they also have these kind of titles.

In your view, what actually defines a Distinguished Engineer?

I think it depends on the company, obviously in the organization.

Um, it's mostly, so the other distinguished engineers are people like Neal Ford and, um, Birgitta Böckeler and James Lewis and a few others.

And it would tend to be people who are sharing information externally, whether through books or speaking or, you know, combinations of things.

So I think, for us, that's a big part of it is, it is kind of helping to kind of gather and synthesize ideas and, you know, new ideas as much as possible and sharing it, right?

It's all about, yeah, sharing ideas, learning and sharing.

Right.

It is, again, my pleasure to have another Thoughtworker in the show.

So, Kief, let's start to go discuss about the topics today, right?

So infrastructure as code.

I know that we talked about it last time, but maybe let's start with the definition again, right?

Because, uh, maybe things have changed.

Maybe you have a new definition.

Maybe if you can define what is infrastructure as code today.

Yeah, so I think usually when I describe it, I say it's something about using tools and techniques and practices and so on from software engineering and applying them to managing infrastructure.

Now that's probably still accurate.

I think there's a lot of interesting stuff going on now if you look at infrastructure management and automated infrastructure management, that kind of as code paradigm, there's a lot of kind of experimentation on trying different ways that aren't necessarily directly about code or used in different ways.

So I think there's something about saying that, yeah, it is about using code as the means for specifying your infrastructure.

And yeah, I think that's, that's probably a fair definition.

I'm, I'm tending to kind of talk a little bit more now and use the phrase infrastructure automation and infrastructure orchestration just to kind of be a little bit more all encompassing of, of maybe some of the other kind of techniques and things that are emerging.

Yeah, so when we speak about code, right?

So, so many people would associate it to like programming language, you know, write kind of like scripts and things like that.

I, I think in the last few years we can see the tools in infrastructure as code mostly are kind of like a yaml, you know.

Some, some form of DSL and things like that.

So maybe that's probably where, you know, some of the analogy of code maybe breaks.

But although recently there are a lot of tools also written in programming languages.

Things like Pulumi, CDK, and all that, right.

So probably we'll talk about the tools later on.

In your experience consulting with clients, you know, you've seen different parts of the world, is infrastructures as code now widely adopted or is it still something that is hard for people to practice?

I think it is.

I tried to do a little bit of research on this, but it's a little bit hard to find concrete numbers.

I would say most organizations that are doing infrastructure, especially those using cloud infrastructure are using infrastructure as code tools.

Now how they're using it, how effectively they're using it is a different matter.

But, um, you know, I think it is pretty much the default these days.

Right.

So if you can elaborate a little bit more.

You have written three editions of the book, right?

Maybe what are some of the major changes?

Maybe starting from the first to the second to the third.

What are the key themes that you see changing such that you want to write a new edition?

Yeah.

So the first edition was 2016, second edition was 2020.

And the first edition, it was like servers was a big part of it.

And that was like the subtitle of the book was Managing Servers in the Cloud.

And so Chef and Puppet and Ansible and these kind of things were the main thing, even though things like Terraform and CloudFormation had emerged and people were starting to use those.

And that was, you know, that was part of, what I talked about in that first edition.

Servers had like, you know, multiple chapters covering servers.

And then in the second edition, servers were still in there, but a lot more of the emphasis now is on what are these things you use to orchestrate, you know, cloud type, like multiple resources, including servers in the mix, but like all the kind of other things around it.

So again, Terraform, CloudFormation, CDK, Pulumi, those were the kind of tools that were a big part of the focus.

So the third edition, it's funny, so when I first kind of undertook to do the third edition, I was thinking, well, it probably doesn't need to change that much, you know, some refresh and updating and all that.

But I found that actually there was a lot more to talk about than I'd expected.

I think one of the things was around kind of thinking about how to align what we build with infrastructure to kind of business needs and business value and thinking a little bit more about that and bringing that more into it.

It's become...

Infrastructure and infra, you know, cloud and all this stuff has become a lot more pervasive.

Whereas previously it was kind of something that maybe a, you know, one part of the business was doing or like, you know, startups and these kind of things.

And now, it's become so much more pervasive that I think it's become really important.

And also with kinda like the slowing of growth and so on where it used to be everybody going and building as much as they can and getting everything digital, you know, digital transformations and all that.

And now, I think more recently there's been a lot of thinking about, well, how do we kind of reign it in a bit?

How do we consolidate all of the different stuff that maybe we've chucked up on the cloud?

So that's been one theme.

Another theme was design of infrastructure and how to design more complex infrastructure states using code.

And the third is what you could call kind of orchestration.

So this is thinking about if you use Terraform or OpenTofu, you have, uh, these TACOS, this idea of things like, I dunno, Atlantis and Spacelift and Terrateam and loads of different things out there to help you to kind of manage your infrastructure code and deploy it, and update it and all of that.

So I think that's been a big shift and we're still kind of underway, I would say in that, it used to be that we would write loads and loads of custom scripts to manage, like to, you know.

So we might use a tool like Terraform, but we would be writing scripts, Makefile, shell scripts, Python scripts, whatever, to run the tool to kind of pull everything together and configuration and all of that.

And so I think we're moving towards a little bit more, I think an aspiration to standardize that.

So an aspiration that as a team you shouldn't have to hand roll all of that stuff.

But I don't think we're quite there yet.

So I talk a bit about things like, so what are some of the tools out there and the different angles and aspects of orchestration that they focus on.

Also things like team structures, team topologies, I, you know, make a reference to and use their kind of, um, language and kind of visual ways of representing team shapes and interactions.

Cause I think, again, that's important to think about so it all kind of comes together.

How do you deploy it and deliver it?

How do you organize your teams to use it?

How do you design it?

So yeah, so that's been kind of overall the theme of this third edition is all of those things and how they kind of interrelate.

Right.

Thanks for summarizing that.

So definitely very interesting, those key themes, right?

Hopefully we can get to cover most of them, if not all of them, right?

So I think one of the interesting thing that you just mentioned is about...

the theme about aligning infrastructure as code or infrastructure in general to the business value.

So I think probably this is so rarely spoken about.

Typically, people talk about application service, you know, architecture, microservice, monolith to the business value, domain-driven design and all that.

But infrastructure, kind of like maybe lesser talked about with the business value.

So maybe tell us a little bit what kind of, I don't know, like misalignment that happens in the industry or what kind of business value that is not driven yet by infrastructure as code.

Yeah, I think it's often very disconnected, right?

Because it's seems quite distant.

So...

and I think there's an aspiration we tend to want to think about.

And people on both sides of like say business leadership, technology leadership, and then people working on infrastructure are kinda like, well, it's plumbing, right?

It's, you know, it's basic stuff that doesn't really matter what it is that runs on it, you just kind of build the same, you know, servers, databases, networking structures, and then let somebody else come in and deploy their applications onto it.

Or in the case of like business folks, it's just like, this is not what our business is, right?

Our business is not infrastructure.

It's whatever it may be.

And so we just need to have stuff that works.

And so I think that kind of gap, that kind of feeling of both sides that like, well, we don't really need to think about this too much, leads to mismatches.

And that kind of manifests as if you talk to kind of business leaders and technology leaders and say product leaders, often they're very frustrated by finding that infrastructure and environments and all that kind of stuff is kind of a bottleneck.

It's kind of a friction point.

It's like, well, teams don't have the environments they need quickly enough, or the environments are very messy.

Or the costs run outta control.

Yeah, or things like expansion is a thing.

So like I find that a lot of companies are looking to expand geographically and they think we're gonna deploy into all these different regions.

Well, we use cloud so we can just use that.

And then that becomes a big pain point where it becomes a kind of spaghetti of code managing all these different environments and different places and stuff isn't updated consistently, and you end up with more people...

having to hire more people to keep stuff running.

And so it kind of feels like, you know, why didn't cloud help?

You know, why didn't cloud magically make it so we can just have infrastructure when we need it and how we need it?

And I think, for me, it's just that there is that kind of piece in between of like, well, how do you assemble?

So I think the cloud vendors have been very clever about they've worked out what is the undifferentiated stuff, you know, servers, you know, subnets and.

You know, all these kind of like basic level things.

Like those are the stuff that you can put behind an API and tell somebody go and, and use this API and it doesn't matter the people building it, being the cloud vendors don't need to worry about what you're gonna use it for exactly.

But the stuff on top of that, then, well, how do you put it together?

How do I run my application?

How do I make updates and configuration changes to the things underneath it?

I think this is why we get, you know, platform engineering is such a big topic and why I think it's a kind of a recurring theme with new names.

We had DevOps and then we had SRE and then we have platform engineering and we have developer experience.

And all of these things, I think, are ways of kind of pointing at, we need to figure out what come, you know, what to put in between, how to make that, those raw, you know, primitives that we get from the cloud vendors useful for getting work done without people having to spend loads and loads of time rolling things by hand and maintaining it by hand.

So I think it's that gap.

And so I, for me, the kind of key is to think about, well, what are we trying to do as a business?

What, you know, is it again, is it geographical expansion?

Because that means do you have to think about something?

Do we expand by growing, you know, more infrastructure for each customer?

Do they need dedicated infrastructure depending on the business model or not?

Do we need to think about consolidation?

Is it that we've grown so much and we have, you know, 50 different Kubernetes clusters built by different teams in different ways and we need to think about how do we kinda like, you know, reign that in?

So I think thinking about what those kind of needs are, and then thinking about what happens, what's the kind of day-to-day things of like, what is a, you know, a, software team have to do?

How often do they have to build new services and deploy them versus just making changes to existing services?

How often are they building entirely new products?

And so the, those differences in what people need to do, then affect how are you gonna design your infrastructure?

Where are you gonna focus?

Are you gonna focus on being able to spin up new environments for new services very quickly?

Or is it more kind of optimization or other things?

Yeah, definitely very interesting and, makes sense, right?

Because, again, it's kind of like applying engineering practices such that you can kind of like scale much, much faster, right?

Rather than having to do it manually one by one or even like error prone, ClickOps, those kind of stuff, right?

So I think definitely makes sense, right?

So investing in automation, you know, kind of like codifying the infrastructure, definitely is very, very important for business.

So I was kind of like a little bit laughing when you say that, how come even though we have cloud now, things are still kind of like still complex.

And I think the trend these days, like there's so many advancement, you know, maybe from cloud itself, like it used to be like infrastructure as a service, right, so like VMs and all that.

Now comes to the cloud native era, like containers, Kubernetes, serverless.

But I feel still complex if you kind of like wanna build like a more distributed architecture kind of systems, right?

Especially when you have multiple teams working together.

Security, compliance and all that comes into place.

So with all these new advancement, maybe tell us a little bit more, what kind of complexities are we dealing with?

It seems like the technology is supposed to make life easier for us, but how come it's still kind of like challenging for us, even though we also apply infrastructure as code and things like that?

I think it's in how it's presented.

So if you look at it where I think it's useful to start when you're kind of looking at the, in what infrastructure and how to design it, you look at the workloads you're gonna be running on and how are those structured and what are their requirements, and so on.

And so I think, what often happens is if you're looking at that level and like, so one of the kinda ideals, um, that I think we have as well, and maybe developers can build their own infrastructure, right?

And so this is kind of one of the motivations behind tools like CDK and Pulumi where it's like, well, let's give them programming languages that they're comfortable with to be able to work with infrastructure.

I think where that kind of falls down is because that the language isn't, I don't think, really the challenge.

It's one of the things that's maybe a little bit off-putting to see, like you say like YAML or whatever, or some declarative language.

But I think the really challenging thing is an understanding, you know, those nuts and bolts of the infrastructure.

I've gotta set up VPC and subnets network routes and all these kind of things.

And that becomes, you know, figuring out how to put all that together, even something as simple as an S3 bucket.

There's zillions options on an S3 bucket.

You can configure it completely differently depending on what you're gonna use it for, right?

Are you gonna be storing sensitive data?

Are you gonna be doing analytics on it?

Are you gonna be, is it just storing static content to serve, you know?

So each of these kinda different use cases you would want to kind of configure and tune it differently.

You also need to think about how to kind of, the security policies you should have and governance and so on.

And so there's a lot of complexity.

And so for a developer to have to think about that, it's going into a lot of detail that maybe you don't wanna have to think about at that point in time.

So I feel like one of the things that we need to focus on is those kind of interaction modes or those, say, abstractions.

So as a developer, I know I need an S3 bucket.

Probably a few questions you can answer as to like what am I gonna use it for?

I'm gonna use it to store static files for website hosting.

Okay, that's it.

Pretty clear use case.

Once you know that, you can then kind of roll out, okay, here's what needs to go into the S3 bucket.

Or a few questions about, again, what kind of data?

Is it personalized data, is it regulated data and so on that might be on there?

What are the access patterns?

So I think providing these things, you know, providing something for developers to be able to just kind of like specify in terms it makes sense to them and that makes sense to the use case, you know, and they care about.

And then say, fine, you know, this stuff will be provisioned for you accordingly.

I think that's really useful.

With the caveat by the way that when we talk about abstractions that can become very dangerous when there's something that hide or like stop you from accessing it.

So to my mind, it's about kind of headspace or, you know, cognitive context.

So it's like, okay, I'm working on my application.

I care about this level of stuff.

At some point, it might be, okay, now I'm finding and see the performance isn't what I need it to be.

I need to be able to then go and look down and drill into that.

I need to be able to do that.

So it's not about hiding stuff from people, but just kind of saying when I need it, I want to be able to get at it.

When I don't need it, I don't want to have to think about it and spend a lot of time on it.

Yeah, thanks for adding that plug, right, because abstraction can be dangerous.

In my experience last time also, like for example, I, there's a Kubernetes platform, but we are not exposed to any of the kubectl, you know, or any kind of a Kubernetes native way of working.

So I think that kinda like defeats the purpose, right?

But I think an abstraction with some kind of like an opinioned way is something that probably can help organizations, especially when they grow larger, right?

Because if everyone is doing the same thing in the different flavors, definitely, it's gonna be difficult.

So you talk a little bit about the tools itself, right?

So obviously when we hear about infrastructure as code, many people associate, you know, things like Terraform, maybe now kind of like CDK or Pulumi are kind of like into the trend as well.

But what do you think are kind of like some of the go-to tools that people are using these days for infrastructure as code?

And what are the, some of the new inventions in infrastructure as code that people should know about?

Yeah.

Okay.

This is, this is an interesting one, yeah.

So I think Terraform and, for some folks, OpenTofu, are still often the go-to for a lot of people.

Probably, the one I'm most familiar with.

We look at things like CDK, that's gonna tend to be like platform specific.

So if you're working with AWS, you might go that way unless you've got kind of skills on the other tools.

I think Pulumi is quite interesting, not just because of the languages and the fact that it lets you use different languages to write your infrastructure code.

But I think the kind of tool set and services that they're creating around it, so things like ESC for environment management, and some of the automation things and some of the stuff they're doing with kind of development portals.

That goes back to what I was saying before about orchestration and I think that's where a big, that's what we kind of need to work on next, right?

So I think as much as thinking about the specific tool, you know, that you're gonna be coding in, if you think about like what I was just saying about abstraction, so how are you gonna provide that to people, right?

What options do you have?

So being able to kind of create a package, S3 bucket package with the parameters that's useful or that can be referred to even in code, application code, I think that's really handy.

And then having the ecosystem around it.

So that's one of the reasons why, and I've, you know, I'm talking about Pulumi.

I talked with those guys a lot and I'm doing a couple of events with them.

So that's kinda like, I guess, a disclaimer of yeah, I, that approach is I think quite useful and quite interesting.

And then I think there's some kind of things coming out that are being worked on as kind of next generation, probably a post-code.

So you have the System Initiative which is led by Adam Jacob who made Chef and a few other people.

There's a similar ish, you know, conceptually, some of the folks behind Weaveworks and Kubernetes itself and Google, have created a startup called ConfigHub, which I know less details of.

The Systems Initiative stuff, I have had a chance to play with.

It's, you know, they've got an open beta.

But essentially, these premise of these things are like, code is kind of a painful way to work with, storing it in your Git repositories and all that kind of stuff.

And that kind of, especially that kind of lag between, okay, you've got what's in your code, what's the reality, and then these kind of interim things that you might have state files or you might have, you know, when you run the tool then it kind of creates a desired state and does comparison and things can get out of sync.

And so I think the premise of this kind of new generation of tools is to say, let's look at the model, the data structures that represent, you know, the real infrastructure and work with that.

It's almost like if you take on, say a Terraform state file and you say, let's make that live.

Let's make that the thing.

And so then you can kind of update the state file, you know, or compare it with what's in the reality and decide what you wanna do when they deviate.

And then you can kind of work with it through whatever interfaces, including code.

You can write code that then updates that model.

Visual interfaces.

So certainly, system Initiative there kind of the thing that you see there is a kind of drag and drop interface.

And then you can write code that reacts so it becomes a little bit more event driven.

And so Adam talks about graph, I think he said infrastructure as graph, I think he said at one point.

Which is interesting because it's those relationships between the different elements.

And so I think all that's really cool.

And I think, you know, that can be really powerful.

And it's gonna change completely how we think about, you know, building these things.

I think it still needs to, so in itself, that still comes down to, well, how am I gonna wire together all my low level resources of infrastructure into something useful?

And so I think it's really important still to have, and this is when every time I see Adam I kind of go on about this, needs to have that kind of, you know, whether it's a component model or whatever it is, to help people who understand the guts, you know, the nuts and bolts to build these kind of components that then somebody else can make use of.

You know, again, the developers can say, gimme a couple of those and here's the parameters I want.

So I think it's gonna be really important, it's still gonna be really important to have that.

That's my hobby horse these days is like I think that's what we really need to focus on.

So I haven't heard those two.

So System Initiative and ConfigHub, so definitely people can check them out.

It sounds to me a little bit more like how the way Kubernetes works as well.

I mean it's kinda like declarative, right?

And you have like, I dunno, like a control loop that keeps on checking whether the state that isn't...

Yeah, it's quite related to that infrastructure as data thing where you're using the controller, you know, in Kubernetes, defining your infrastructure code as like CRDs and those kind of things, so you can just refer to it.

And I quite like that as a model conceptually of like, because, again, I can deploy my application and say, oh, my application by the way, it needs a database instance, it needs some message queues or whatever.

And then the system kinda works out, okay, now I'll go and provision that for you.

And so I think, yeah, I think you're right.

I think it's a natural kind of next step beyond that really.

So definitely, uh, the next thing to check out, right, for people who like to...

Because I know that infra people, whenever they hear new tools, they will check it out and, you know, see how does it work, how cool that is, and things like that.

So speaking about Terraform, right?

So I think still it's the biggest, you know, majority people still use kinda like Terraform and now we have OpenTofu as well, and they kind of like diverge, I think has been a while since the fork and the diverge of the version.

So what is your take here, for people who are, I dunno, still using Terraform mainly, right?

So should they stick with Terraform or should they change to OpenTofu?

What is your view?

Yeah, I think it's an interesting one.

I mean, I can certainly see a case for sticking to Terraform, particularly, if that's if you're in that kind of ecosystem with the HashiCorp tools and so on.

You know, the licensing change was a bit unsettling for a lot folks and working out like, what does this mean for me?

I think one of my concerns with the licensing change was that it would impact, so even if you as a user, so this was as a consultant like I was concerned with, okay, what does this mean for my clients?

Well, most of my clients aren't affected because they're essentially end users.

They're not building like a service to provide kind of Terraform hosting.

So those kind of TACOS servers and those kind of things are the one really that I think, licensing changes were aimed at.

But I think it has an indirect impact of, or, you know, my concern is, well, what's the ecosystem of tools look like as a end user still?

It's like am I gonna have the ecosystem of tools available to me or are they, those vendors gonna be maybe not providing as much support for Terraform because of the potential cost or liability or whatever they may have from that?

So I think OpenTofu, I'm still, I'm not kind of up on exactly where OpenTofu is at in terms of adoption.

Like how widely is it used?

It's supported by most of the vendors of these kind third party tools that were originally kinda the Terraform ecosystem and have kind of, as you say, they've kind of diverged, they've kind of forked, not just the, core tool, but like the ecosystem is potentially, you know, forking and diverging there.

So I think there's a lot of vendors and people and, you know, an ecosystem there that is behind it.

And so I think it's quite promising from that.

I would kind of like say it's something to experiment with and look at and see how well it suits you.

It'll be interesting to see how it, how it does diverge, right?

Because I think one of the kind of, I think there was a little bit of mixed messaging from the OpenTofu folks originally around, well, is it gonna be kind of like a drop in replacement for Terraform.

But I think, inevitably, what's happened is like, well there's a desire for new features, for maybe features that Terraform wasn't gonna support.

Things around kind of encrypting secrets where it's like they want you to use the hosted platform and so they OpenTofu folks are like, well, we'll just build it into the client.

So there's a lot of things like that where it is gonna start to diverge more and more.

And HashiCorp as well I think are building a lot of features into Terraform that integrate with, you know, their cloud platform.

They really want you to be using the cloud platform, so things like Terraform Stacks and so on.

And so this is, I, you know, I, I think people are gonna have to pick a horse.

Originally there was kinda this idea, hopefully, we can just kind of like use OpenTofu or switch back and forth or whatever we need to do.

And it'll all be compatible.

But I think I don't think that's gonna, you know, it can't do that in the long run.

And really that's gonna be the, I think, the compelling thing for the Open Tofu users is gonna be the things that they can offer for maybe more, um, inexpensively or what have you than they could get from Terraform.

Yeah.

So definitely something to watch out, right?

So over the time, so I'm still using Terraform by the way as well.

So am I, for most of my either small projects that use it mostly, and whatever my clients use.

And most of my clients are still more Terraform, the CDK.

I can't think of having certain, I haven't worked in a project where it's OpenTofu.

Not yet.

Yeah.

So one thing you mentioned just now as well is about the orchestration or kinda like deployment, right?

So like applying the infrastructure changes, right?

So definitely the trend that you picked is kind of like orchestration tools and things like that, maybe in a way that applying like CI/CD pipeline or kind of like GitOps model for applying infrastructure changes.

So what trend do you see around this?

So, because I think many people still in different maturity, right?

Some kind of like just applying it from their local.

Some apply it in a CI/CD pipeline or maybe some other things.

So what do you think people should do if they wanna start IAC the right way?

Yeah, I think it's important.

So I think one of the things that's useful to kinda distinguish is the actual deployment.

So I think a lot of the tools that are out there that like we're gonna help, you know, deploy your infrastructure code and all that kind of thing, they tend to be very focused on just the deployment part and maybe directly running a plan and then a deploy or those kind of things, which I think is useful and important.

So the GitOps thing or the infrastructure as data or what have you, where there's like the code and then your tool is making a, you know, the control loop kind of make sure that, you know, drift happens and is, or drift is corrected right away.

So that's one part of the equation.

And then I think the other part is, well, how do you get, how do you deliver changes to your infrastructure code across environments where you have, whether those are environments to test software, testing and QA environments, and staging and so on.

Or the environment you use to test the infrastructure code itself before you put it out to developers.

So I think it's something I think that we've struggled with in the infrastructure industry and infrastructure as code kind of field, is how to make that work nicely so that we don't end up with essentially separate copies of infrastructure code for each environment and kind of copying and pasting changes from one, say one repository to another.

Or even merging branches.

Often, you know, it becomes messy.

So I think that's the part that's still a little bit tricky in that, you know, again, some of those kind of tools out there that do the orchestration, you know, in promoting across environments, some of those are addressing that and providing different ways to do that.

But I think it's still very much in flux in kind of like this, there's not like an established, okay, this is the one right way to do it, the pattern that most people agree on.

And so I think that's where things tend to get and, you know, most of the clients I've worked with, that's where things are messy.

Yeah, so I could imagine like these kind of things definitely is kind of like the details of implementation that differs across organization, right?

So some people like to, I dunno, create modules that can be reusable, but you know, like modules itself has to evolve, right?

Especially if you make some changes.

And then how do you backport it to existing infrastructure and things like that.

So that's always kind of like difficult.

And writing tests, right, for infrastructure as code.

I'm not sure how many people do that diligently.

Because like there will be resources that gets created or maybe if you use some kind of, I don't know, like mock things like that, maybe that could happen.

But ideally, it also never tested in the real world, right?

So I think definitely these kind of things tends to be the challenge for people.

And you mentioned about platform engineering, right?

So I think these days everyone is talking about platform engineering.

What is platform engineering in your view?

Because I think this term, kind of like DevOps and all that, right, being used interchangeably to describe certain things, especially from vendors, right?

So maybe in your view, what is platform engineering?

Yeah.

I think for me, it's about providing the things that software teams and developers, and also people who do support operations of software.

What do they need in order to get their jobs done?

And particularly...

So it's A, it's about making their, you know, easier for them, empowering them.

And this is where we go back to like we were talking earlier about abstraction.

Because, you know, one of the things a platform can do when it goes wrong is disempowering and making it difficult for people to get their job done.

So it really is about empowering as a number one thing.

And then there's also that thing of kind of sharing implementations and resources.

So like, not every team needs to build their own monitoring tool set.

Not every team needs to kind of build their own databases from the kinda low level.

What can we share?

And all this has to be like in a way that is useful and helpful, you know.

So it's not like, well, you're not allowed to use a different tool because we are providing this tool, even though it doesn't do what you want and the way that you need it to work and so on like that.

It is about what's truly helpful.

And I think that's the reason why platform engineering is such a big topic and there's so much out there about it, 'cause it's hard.

It's hard to do that well.

I mean, it's so easy to fall into traps or I think one of the big traps is you try to do too much, right?

So you wanna, I'm gonna provide this platform that will do all things for our developers, and it's, you know, it's too ambitious.

And so you end up not, you know, building a small piece, small piece and not having enough, and then people turn elsewhere.

Or you're just, you know, it's too restrictive and people can't get what they need done.

And so like there's a lot of kind of traps, I think, from that.

So to me, the way to kind of succeed at it is to think about it in terms of how to enable other people to build, say, platform services.

So rather than saying one team needs to build all the services, it's like, well, if different teams or the database team that's an expert on that, and another monitoring team that's focused on that, how can they build stuff and how can we provide them with the things to kind of easily connect those things together nicely and to kind of manage the things that, again, those teams don't necessarily need to build everything from scratch themselves.

Like what do they need?

And so I think that's the interesting challenge.

Yeah, and especially the underlying platform itself evolve, right?

So let's say if you use cloud as the basis, right?

So the cloud itself also change.

New features, new changes, new deprecation.

So definitely supporting those things are kind of like difficult as well.

And I think when you mention about building platform engineering, right?

So some people kind of like also associate this with like internal developer platform or something like that.

So the idea is kind of like build tools and, you know, services and platforms such that other people can use it.

Maybe in the team topologies is like enabling team, platform team as well in a sense, right?

So have you ever seen, you know, success stories of people building such team and capability?

And if so, what do you think are the key recipes for them to succeed?

Yeah, I think, I mean, I have, and I think, I think the key things are really focusing on the user.

So this is where the kind of platform as product comes into play.

So again, pitfall is, okay, I'm gonna build this platform or this component of a platform, whatever, and I'm gonna just go away and build it cause I know what it, what it should be, right?

So I'm gonna go and build the Kubernetes cluster to rule all the Kubernetes clusters, and I'm gonna go away and build that.

But I think it's important to really have that understanding of how are the teams using it and what are they using it for, and what are their journeys and what's common.

So you see oftentimes people will optimize for things that don't happen all that often.

So you'll see like, okay, we're gonna make this way so that it's easy.

We're gonna have like a, just to create a new application, right?

A new server application.

And so we're gonna have the, you know, the template project.

You can go to your developer portal and click a button and you get a new repository created in a new pipeline and all that.

And then, you know, you look at it and you go and talk to the teams and it's like, yeah, we do that maybe twice a year.

But we have these other things that are painful for us and like, you know, and so it's, okay, let's look at what's painful for the teams and what they're doing very often and try to solve that.

And so I think the teams that are most successful in doing the kind of platform, you know, developer platform or whatever you call it, wanna call it, is that just that really kind of close relationships with the software teams, the development teams.

Often they're, these stuff comes outta the development teams.

So they might be embedded with the development teams and working on stuff that is a, just that team is using.

And then over time, okay, here's something that maybe can get another team needs.

And so you kind of evolve it.

It's reusability rather than trying to start out by here's a, you know, a feature that we're gonna provide, a platform service that we're gonna provide on demand and easy click, which is a, again, a very ambitious thing to build.

And actually, their first iteration is just, well, here's some documents and outlines of how to build it so that you know, like, okay, how do I use RDS to create my database, right?

We don't have to necessarily create a wrapper around the RDS service, you know, as a platform service, but we can just kinda say, here's how to do it and here's some example code maybe that you can use and modify.

That's kind of the first step.

And so I think thinking about, you know, those progressions and evolution of maturity of a service and how kind of more polished you can make it as it gets adopted and used more and you've learned more about how teams are using it.

I think that's important.

Yeah.

So thanks for mentioning, you know, platform as a product definitely is kind of like the way, the go-to way to build proper platform, right?

And yeah, and the other message is about, you know, don't be that ambitious, right?

So sometimes, we, you know, we engineer likes to build, you know, gold plated solutions.

You know, one click everything automated.

It's that classic incremental, iterative delivery.

It's hard to do with infrastructure and platform services because like, even if you take a simple application and you look at, okay, what's the vertical slice of platform and infrastructure you need for that?

It tends to be, you know, it's like an iceberg, right?

You need to build a lot of stuff just to get there.

So I'll often do things like starting with...

like monitoring is one of my favorite examples.

It's like, okay, you know, we're starting out and like we wanna use Prometheus.

But like building a Prometheus cluster and all that kind of stuff is gonna take, you know, a lot of work.

So we might just start with CloudWatch or whatever we can get out of the box.

And yes, it's not as nice to use, but it'll get us up and running quickly.

And the software team, the development team can start working.

And then over time, as we get to it, we put that on our backlog.

And we're gonna reach a point where it's like, okay, now we really need to do the fuller featured, you know, Prometheus or whatever it may be at that time, might even change, because we're starting to hit the limits of what we can do.

So yeah, but it's hard.

It's really hard and really challenging to identify that thin slice.

And then, yeah, as you say, to resist that temptation of like, man, you know, I really wanna mess with Prometheus.

Wanna learn how to set it.

Sure, I can do it.

At least, in my weekend.

Yeah.

Resume-driven development, right?

So speaking about application, right?

So I think this is also one key consideration, right?

So when you build a team, right, do you have infrastructure engineer also together as part of the team building the kind of like infrastructure as code together with the software features and things like that?

Or do you have a separate team?

And do you actually run the CI/CD pipeline together, application and infra, or are they different pipelines?

So maybe these are some opinions that, uh, we can learn from you as well.

Yeah, but I think the answer is that it varies, it depends, maybe where the organization is, the size of the team and what they are doing and the kind of maturity.

So I would say, in the early days, for smaller, um, organizations, it makes sense to have them combined, right?

So having, if you have like one development team working on, you know, a handful two pizza team or whatever you wanna call it.

So one team working on the software development.

Having a separate team building infrastructure might not be the right approach.

Because they're not developing, they shouldn't be developing a reusable platform that is gonna serve the needs of a lot, and, you just need, what's the minimum infrastructure we need for this application right now?

Build it in a way that you can evolve it, um, and replace it and swap things out.

So, you know, use good design and good implementation.

And so this is where, yeah, pipelines and automated tests I think have really helped to kind of make it easier later on as that starts to kind of like, okay, now we've got three teams, four teams, five teams developing things.

And becomes, you know, you can't really kind of replicate infrastructure specialists across all of those teams.

And also think about how to, you know, how can we be sharing knowledge and expertise across those teams better and so on.

So that's where you say, okay, maybe let's kinda split some of those into another team.

And there, again, I think it's really important to think about what's the interaction model there.

So even with the smaller organizations, we have a few teams.

I think still, you know, high, you have opportunity to do high communication kind of stuff.

And so I think the best models are ones where when you look at like what is the development team trying to get done?

How can they just kind of get on with it and not have to then wait for somebody else or put things in somebody else's backlog or what have you?

And so you look at, you know, you're just looking for those things.

Okay, what are we doing a lot of now?

What are we having to wait a lot of now?

How can we make that easier for people to manage themselves?

And so I think that's where you start getting more into the kind of more sophisticated things of, right, we're gonna have something that's a little bit more self-service for these tasks, or we're gonna start making more tasks self-service again, as it gets bigger.

It's like, you know, more things get folded into that.

And where that, you know, going back to what I was saying before on platform teams they should be doing, again, it isn't necessarily that one team is building all these things.

But it's like, okay, so what is that motive?

How does a developer specify my application needs this?

And so you'll see like, teams might be using a, you know, a platform or framework, something like Kratix or Humanitec or what have you, where it's like, okay, these are kind of ways to let different teams build platform services and share them in interaction.

Or they might be doing something in-house a little bit more simply...

Like the pipelines, I think it's interesting.

I think, as an application goes through its pipeline, it's useful for it to be able to trigger the actions that it needs in terms of infrastructure.

And so particularly where you wanna get to as, you know, as you have a lot going on, is it's like you wouldn't necessarily wanna be kind of sharing environments or having static environments.

You might wanna be able to kinda spin up infrastructure, a minimum set of infrastructure to test what I need to test at this point.

And so having a way of triggering that from the pipeline, saying my application needs this, can you, you know, and it gets provisioned, that I think becomes useful.

And so where I kind of, to my mind, a good kind of mature way of working in pipelines for this is the components, the infrastructure components have their pipeline and you treat it almost like a library or a tool or what have you, where is, okay, here's the component that builds, you know, my S3 bucket that I keep talking about, right?

So here's the component for that.

Bring a couple of different components for different types of S3 buckets doing different things.

And so you have a pipeline that as that infrastructure code, test it, try, you know, in different scenarios and then kind of stamps it and puts it into a repository within the application, teams then can pull it, you know, into their applications or into their pipelines and so on.

So they then have the ability to kind of provision their own infrastructure, not be held up.

But you also have another, one of the big concerns that often comes up around all this, these things is governance.

You don't want your, all of your development teams kind of building their own S3 buckets because they might do it wrong.

They might forget to set the encryption option or what have you, or just not do it in the best way.

And so saying, okay, we're gonna have an expert team provide something that, you know, has the stamp, it has passed the kind of, you know.

And then we have, we can validate and show to, um, compliance, you know, regulators and auditors, if we need to.

That's quite powerful.

Yeah.

I think it's also a good segue.

You brought up the topics about governance, right?

So definitely, an extension of infrastructure as code.

So many people talk about, you know, shifting left, you know, security.

Right now, people talk about policy as code, compliance as code, everything becoming a code now.

Governance is definitely very hard and challenging, right?

There are so many things that we could change and that there's so many things that are insecure and maybe less in terms of compliance, in terms of organization policies, right?

So what is the approach here that you would advise people in terms of creating infrastructure but still kind of like govern and compliant to the standards that organizations have?

Yeah, I think there's a couple of places where that can fit in.

And so like, one of it, as I say, if you have components that are reusable and you can have kind of tests on that and validation that like, yes, it passes these things.

That's a good point.

Tests that can be run in, in the application pipelines as changes are going through, again, making sure, you know, nothing can happen that shouldn't happen.

Things are in place.

Also recording changes who made changes and all those kind of things can be really useful there.

I think you also have the things that you build into your kind of infrastructure at runtime or, you know, whether it's monitoring or other kind of mechanisms that can detect something's been deployed.

Hey, you know, I'm able to access a port.

I shouldn't access what's going on there, right, raise a flag.

I think there's those kind of different layers of protections and so on.

I think a key thing is like, for the people, so the, you know, the experts, say your security experts, your governance experts and so on.

Even people in other kind of areas of expertise like performance and so on.

I think a lot of, you know, still to this day for a lot of people, their way of exercising their governance, the control and all that, is still based on kind of manual inspection and gatekeeping of changes.

And I think the kind of the trick for these people is to understand how to use the automation tools.

Again, you know, the, should I say policy as code?

How do you kind of write policy checks?

How do you make sure that those are implemented and that those are acting as gates in pipelines and production deployments and where else they need to?

So how do you make sure that the right things are in place and to make sure that they're running so that you don't need to inspect every change to make sure it's compliant and you have the kind of confidence?

And I think, you know, these things get you to the point where it's like you actually have more control and more, you know, it's much more rigorous, the old ways.

And I still hear, I heard just the other week, an organization where the people were saying, well, we can't automate this task because it's too sensitive.

It's too compliance and stuff.

It's...

We can't trust the automatedness.

Like, you, you trust humans instead, you know?

So yeah, I think it's just that mindset thing of just like, you know, this stuff can make for much more.

It's actually, it is interesting thing because it's kind of flips that trade off rather than saying, well, you know, we're gonna go slow and carefully inspect everything and that's how we're gonna get good governance.

Or else if we get rid governance so we can go, you know, in order to go fast we have to get rid of governance, we have to loosen up on it.

Actually, you can have both, because the automation can run very fast.

It can run on every change, tell you much more quickly if something is wrong, tell you much more quickly where things have gone wrong.

So it's easier to kind of fix.

And so it can be more rigorous and faster.

And I think that's the kind of secret sauce that people need to, you know, need to realize is an advantage rather than something to be scared of.

Yeah, and I think this space also kind of like advances quite rapidly, right?

So security, compliance and all that.

And I know there are a lot of tools that can do even automated scanning, right?

So sometimes when you wanna govern, right?

It doesn't necessarily mean you have to do it like a gate keeping check, you know, like check whether this can go through or not.

Sometimes you can detect kind of like drift to your policy or maybe violations to some rules or compliant things, right?

And you kind of like detect and raise that to the team.

I think that can also work sometimes, right?

Because all I find, you know, with engineers these days, there are so many things that people need to understand and know, and it is very, very challenging to understand everything, right?

So I think having these kind of tools that gives you the signals, the clues will definitely be helpful.

So I was kind of like laughing as well when you mentioned like, those people trust human instead.

These days there's an AI element, right?

So what about AI in infrastructure as code space?

So what do you see the trends coming?

There's interesting stuff.

I mean there's a whole category of how you can use it in operations side, in troubleshooting and monitoring and all that, which I think is very interesting.

But for the actual kind of building of infrastructure and automating it, I think there's a couple of angles.

So one is, so I think the code assistance, like as we have with regular programming, um, being able to have something whereas you are working in a code is kind of advising you doing auto complete and coming up with solutions to things, can be helpful with all the caveats that covers software development there.

It's like, you know, I don't think you wanna vibe code your infrastructure.

Um, I think you wanna, you know, you want to, you need to understand what's going on there.

Yeah, you can have something that generates some code, but you like, you really need to understand what it's doing.

And so I think it comes back to what I was, you know, again, what I was saying earlier around, like there's that knowledge thing.

And so I think if you're using AI to kind of create infrastructure for you or even create infrastructure code for you, you still, you know, having that knowledge, you know, it's important to get the levels right.

And so I think there probably still is.

So there's a couple of things.

So one thing I've seen people experimenting with is using kind of chat bots to say like, okay, provision me that S3 bucket, and then it provisions it for you.

And I think that the challenges there are the same things we have with, you know, goes back in infrastructure.

And so I was, I was looking at this and tools that do these kind of things, and now is...

I went back to the book, right, already like the, you know, third edition just came out.

But I wanna like, double check like the things that I said in the early chapters of the book where I talk about principles.

I was like, oh, I have to rethink these in the light of how you might be using AI in these, right?

Part of it actually hold up.

Those early level, you know, the core principles are things like you need to make sure that you can do things repeatedly, you'll have consistency in, you know, across environments.

And that there's transparency so you can understand what's going on.

And so this is where I'm kinda less keen on something that is like, make me an S3 bucket and it does it, and then the S3 bucket is there.

Like you know, I wanna see how it's done and I also wanna know that, like, it could be repeated.

So, okay, I have my S3 bucket in my dev environment.

Now I'm gonna wanna put it in the QA environment, the staging environment and production.

I don't want it to kind of come out differently every time because, even with the same prompt.

Even if you're reusing the prompt and promoting your prompt, 'cause you could do that, right?

Put a prompt in the code and then, you know, mark down file or whatever, and promote that.

It can still do different things in those different environments.

And so I think there's something about, my kind of like picture of how I see it being used in this, as a part of this, is kind of similar to what you might be doing with like a developer portal or with these things that I've mentioned.

Let's say you have like a descriptor as an application developer that says, I need a secure S3 bucket that I'm gonna store, you know, personal data in and do analysis on.

And so it's that level of like, okay, what do I care about?

And then something that then, okay, I'm gonna provide that.

And so that thing is a repeatable thing.

So you built a component, maybe you used an AI assistant to help you to kind of write the code or whatever it is that is a component that will create the S3 bucket.

But every time that that is executed to create a, you know, an instance of that bucket, it's done in a deterministic way.

So I know in every environment it'll build it the same way and the same options.

And then for the person using it, it might be, say a developer, it's like it might give them the kind of coaching things.

It might say, hey, I noticed you're using, you know, I'm looking at your, you know, I'm an assistant that knows you application code base, and I see that you're storing something.

Maybe you should use an S3 bucket.

Or maybe there's a different storage thing, you know, option that you should consider.

And here's the library of things that have been kind of provided, you know, to help you pick between those and understand how to use them.

But still having that kind of different layers of abstraction, I dunno if that's quite the right thing, but that interface, right, and, you know, all that.

So I think it's exciting, right?

I don't think stuff is there, like even for the coding assistants, most of the, the a, you know, the AI coding assistants for that work with application code aren't great.

Yeah, so I, I have that experience as well.

So even though I use Terraform, which I assume like many open source projects are having Terraform code, right?

Still kind of like doesn't perform as good as programming languages like typical JavaScript or Java and all that.

So I think there's a like gap in terms of using coding assistant.

And I don't know whether we can even vibe code infrastructure as code, you know, like just, you know, ask AI to keep on creating resources, you know, spin up, spin down and all that, right?

Because also, there's a risk, right?

If it's misconfigured and if you have data loss, I think it's a big challenge for the organization.

So apart from coding assistant, probably people use it for, I don't know, like you mentioned, monitoring, support and all that.

Are these tools advanced enough now that you can actually use it to kind of like troubleshoot, figure out the root cause analysis and things like that?

I think it could be helpful for sure.

And it's, as with anything with this stuff, it's around the data, you know, make sure it has the data available and then getting the kind of prompts right and the queries right.

But yeah, I know, and it's a skill also like again with you have to learn how to use it well.

But yeah, I definitely see people using it.

And we've got people in ThoughtWorks in our demo group, which is about operations, where they're working on some kind of an agent based system that pulls this stuff together and they're like, you know, even having stuff where it might be able to generate like a pull request to correct an issue and all of that.

I don't know how, I'm not as close enough to say I, you know, is that how much of that's being used in anger and all of that.

But I, you know, I definitely know it's being used for things like, again, those kinda logs and metrics and all that and, you know, to answer questions.

It's, you know, human in the loop, still.

Yeah, so definitely always involve humans still.

So Kief, we have talked a lot about the new stuff in infrastructure as code.

Is there anything that left out maybe that you think we should cover as well?

Um, I think we've covered a lot.

I'm sure there is, but I think we've covered all of the cool stuff.

Right.

So I have one last question for you.

I think if you still remember back then, I asked you this same question, right?

I call this the three technical leadership wisdom.

So maybe if you can think of it just like an advice that you wanna give to the listeners.

What kind of three tech lead wisdom that you wanna share for us today?

Yeah.

Okay.

I don't know if I, I don't know if I have it as like three items, but I think it's kind of a broad thing.

So one of the things I've found as I kind of change and grow in, in my career and roles and how I relate to.

So like, you know, first, there's that like becoming a team leader and then there's becoming maybe somebody who's managing multiple teams, managing team leaders.

A lot of what I'm doing these days is kind of advisory to teams.

So I'm in teams in a very senior role and as a kind of a leadership role, but I'm not necessarily in that kind of line of command.

I think it's really important to think about what your role is now in the, and, you know, what is it that you need to be doing?

Because it is very different, right?

It's very different that that first step of going to being a, a team lead, a tech team lead, is now very different because it's not up to you to code all the things.

You want other people to do that, and you wanna get outta their way from that.

And that's always the hard thing, right?

How to get out of the way of the things that you're comfortable doing that you see people doing and maybe they're not doing right or they're not doing in the way that you would want or whatever.

And how do you kind of step back from that?

That's a thing.

And then as you get into the, where you're managing people who are themselves, team leads, again, that becomes different.

And the things that you're doing as a team lead of like, you're caring about the quality of the code and you're coaching your developers on that.

As you move up, it's like, okay, I'm doing less of that now, right?

And I'm, you know, I'm more focused on, you know, maybe again, it's that kind of business.

You know, what is it, you know, we're looking for in terms of kinda business problems that we're having to solve?

How do we go about doing that?

How do we coordinate across teams?

That becomes a thing.

When you're in kinda an advisory role like me, it's a little bit like I'm stepping aside and I'm kind of noticing things and noticing, okay, this is the thing.

And it varies by situation a lot, right?

Okay, this team needs my help for these aspects.

Oh, and then now another team I'm with, they've actually got those aspects down pretty good.

Like so, you know, maybe it's making the technology decisions or the architecture decisions and designing the overall solution.

You know, maybe one team needs more guidance on that because they have less experience with that.

And now I'm with a team where they're, they've got that down, but it's like, well, there's a lot of challenges with stakeholders and so I need to kind of work on, okay, how do we communicate to the stakeholders what's going on and how do we kind of bridge that?

So I think it's kind of like one answer that I think encompasses, there are different things in there of like letting go of what you used to be doing and being attuned to what, what's needed now, and where you can, where you can bring your kind of strengths and experiences into the mix.

Wow!

Thank you for such a great elaboration of this, uh, you know, intermixed, I would say intermixed kind of attributes that you need as a leaders.

So I think that's really important.

So Kief, if people would like to contact you, ask you about the books, or maybe ask you follow up questions, is there a place where they can reach out to you?

Yeah, so, um, I've got my website infrastructure-as-code.com with the dashes in between the words.

And there's like kind of contact stuff on there.

Probably LinkedIn is the main social that I'm on these days.

And so yeah, you can kind of ping me there.

I'm occasionally on Bluesky and stuff, but not as active.

Um, I tend to be more in Slacks these days, more kind of community, you know, technical community Slacks seems to be in as some of the big social media sites that I used to do a lot, I've kind of pulled back from.

So now it seems to be more the, the smaller communities, which is an interesting phenomenon, but a topic for another day maybe.

Right.

So always a pleasure, uh, learning from you, the new stuff about infrastructure as code.

I think you are like one of the forefront in this area.

So definitely thanks for this conversation and yeah, goodbye for now.

Okay.

Thanks a lot.

Appreciate it.