Infrastructure as Code

A Decade of Infrastructure as Code

Abby Bangser: Hi everyone. Welcome to this chat I'm going to be having with Kief Morris. First I'll quickly introduce myself. My name is Abby Bangser, I'm a principal engineer at Syntasso, where we're building an open source framework called Kratix to help people build their internal platforms in a faster, safer and more efficient way. I've had the pleasure of not just working with Kief or being friends with Kief for over the last decade. And I'm so excited to see that his third edition of his book has come out. But for those that may not be as familiar, Kief, would you mind introducing yourself to everybody?

Kief Morris: Sure. I work at ThoughtWorks. We worked together on a couple of projects in the past, before you moved on to where you are now. I've worked at ThoughtWorks for the past 15 years. I'm based in London, although I'm originally, as are you, from the US. We're both transplants to the UK. I've worked with infrastructure as code as a user for ages probably since around the very early 2000s with CFEngine I started out with and then Puppet and Chef and so on, and then as cloud, and DevOps and continuous delivery, all this stuff emerged. I was especially really into that stuff. The thing I'm known for is I wrote the book Infrastructure as Code, which is published by O'Reilly. And as you said, it's the third edition that just came out. So that's my jam right now.

Abby Bangser: Some things can make you feel older or younger, different ages. And I feel like the fact that I was sitting in a client cafeteria with you almost exactly ten years ago, maybe nine and a half years ago, as you were putting the final touches on that first edition. It makes it crazy to me that you're onto your third edition, that it's been ten years, and all that. And it just makes me think how that's both a blink of an eye and also a lifetime when it comes to software and technology, and all the changes. So I guess I'd be curious if I'd fallen asleep after lunch that day and woken up in 2025, ten years later, what would I think I would be surprised? What do you think would surprise me? What do you think would look familiar to me? Ten years on from that?

Kief Morris: That's a good question. I think the things that have changed a lot are back then, we focused a lot on the server configuration that was around provisioning operating systems and configuring them. So Chef and Puppet and those things were the main thing. And CloudFormation and Terraform were out and starting to be used. But that was the newer thing. So the first edition had a mix of those. I think the subtitle was Managing Servers on the Cloud. Obviously got a lot more. I think probably one of the more interesting things is that containerization and all of that. So we're a lot less focused on the operating system level stuff, although it's still there, and there are a lot of places where people are still doing that, they're still building the virtual machines and the physical servers and all that and using these things for that. But the whole containerization thing is what has exploded and changed the landscape.

Then I think also just the amount of stuff that people are doing with it and the complexity of what's being built, because back in those days, it was still a little bit niche. It was still most companies that have been around for a while - I think we worked in a bank, right? And they'd been, I think that was even a couple hundred year old bank, here in the UK and what was being done with infrastructure as code was fairly small scale and even startups and internet, digital natives, it was still fairly small. I think just the proliferation of stuff, proliferation of what's available to you on a cloud platform, the different services and stuff that's available on the different tools and things. It's just gotten more and more and more. And so I think I probably would - I don't think that would necessarily be anything that surprised you in terms of the nature of what it was. But just the amount of it might be a bit shocking.

Abby Bangser: You're so right. The complexity of what we do with it and the move from cattle to pets, or pets to cattle. The other direction that we often talk about is the idea that when we were first starting going into infrastructure as code, the industry, when I say we, the royal we, a lot of the things that we were thinking about orchestrating were things that were long-lived. They were things that need to be updated over time. And then, in those first couple of years, we worked across a number of clients together. We saw a lot more of that move from pets, those things you had to take care of for a long time, that each had their own literal names that you knew well, they had their own personalities, into that idea of cattle, that idea of something that lives for a short time, that can be replaced and so forth, horrific as that seems as a metaphor.

Recommended talk: Building Evolutionary Infrastructure • Kief Morris • GOTO 2019

The Challenge of Abstraction Layers

Abby Bangser: Do you think that with that changing of the way we work with infrastructure, not infrastructure as code per se, but with infrastructure that moves from servers to containers, from containers to serverless to functions of the service and edge compute and all those things? Do you think that infrastructure as code, as a model, has been able to keep up with the architectural pressures that are coming in? The requirements?

Kief Morris: Because I think it's layers, isn't it? Layers of abstraction that have been built up. And part of the thing, even with the early virtualization in the cloud in that basic sense, the idea is okay, I'm worrying less about the stuff, the tin, and the wires and stuff. And so that stuff can come and go. And I'm worried now about the conceptual. So the virtual server is this thing that sits, and I don't really care where it is. Right. And then containers, now I don't care what server the container image is running in. Serverless, I don't even necessarily care about the container.

I think the piling of stuff is, it's a big mess. There's a lot to it. And I think that there's been a lot of stuff lately. I like people writing articles and stuff around infrastructure as code is dead, or what's next, and that kind of stuff. And I think it's all valid just in the sense that it is hard, especially with the tools that we currently have. So the infrastructure as code tools that are out there, the way they approach this doesn't really - I think it's still in a way, I almost use this phrase “snowflakes as code”. Right? Which is just the idea that you take some code, Terraform code or CDK or whatever it might be, and you use it to define an environment, but that is still static. There's that one environment, and here's the code for the environment. When you need another environment, okay, I'm going to copy the code and I'm going to tweak it. And so you're maintaining all the code for these things. And it's very low level. So, infrastructure code, when you look at it it's really a thin wrapper over the API of these clouds. Right. So the things that you define in Terraform are just, well, there's an EC2 instance, there's a subnet, there's this, it's all very low-level stuff.

It's just getting harder and harder to work at that level. And so there's been a lot of, I guess, or a lot of people are out there thinking about what how to improve on that. And I think some of them are looking at things like, so there's the language thing of okay, maybe for features like a regular programming language rather than a declarative language, it might make things easier. I think that still ends up being you're still writing code that is dealing with the low level infrastructure. It's tough to deal with that. There's some cool stuff coming out, the likes of System Initiative and Config Hub and so on where they're looking at what if we do away with code and having code sitting in GitHub? And if we look at the data structures that represent our infrastructure. And so I think the emphasis like if you look at System Initiative, if folks haven't, I'd recommend giving it a looking it up and having a look. It's from the founder, Adam Jacob, founded Chef. And he's moved on to this with some other folks are building this cool stuff, and the emphasis is you look at it, it's GUI stuff. I'm doing drag and drop. I think that actually that's just a superficial thing that what's interesting is that it's the data structures and the models of stuff where with something like Terraform, we have state files, right? The state file represents we run our infrastructure code and then it gets turned into a model in memory of the tool of there's the desired state. And then that gets, the state file is some data structures that represent what it thinks the state of the real infrastructure is. And it tries to reconcile all of that.

That whole loop gets messy. They're saying, what if we just take that those data structures and we just work on that and we expose those and make it so it's still, you can write code, that's programmatic and generates data structures or reacts to changes in data structures. And so it creates some really interesting opportunities, I think. But I think there again, I think as useful as that is for maybe moving beyond some of the limitations of infrastructure as code, I think the real issue is around those levels of abstraction of what we are working with? How are we thinking about it? So if I'm a developer and I'm trying to deploy some software or define what my software needs, I don't really want to have to wire up those really low-level networking structures, to be able to make connections in and out of it. I just want to say I need a connection from the internet. It needs to be secure. And so it doesn't matter really whether you're using a declarative language or a programmable language or even if you have a GUI interface to help you manage that stuff. Still, working with that low-level stuff is a pain. And so it's how do we bundle up with whatever tools we use.

My take on this is infrastructure as code. Whether it's dead is maybe it is, maybe it isn't. It doesn't matter. It's the changes that we need to make and how we abstract infrastructure and manage it, and to automate everything like that. I think that's, we can use different, different tools for how we build those abstractions, and those will evolve. And I don't know which direction it's going to go.

Abby Bangser: You're supposed to have the magic ball, the magic, you know. Well, it's super new. You had a few really interesting threads there, but I think where we sort of wrapped up, was the conversation around the abstractions of infrastructure as code. And one of the things that always goes through my mind when I'm talking with you or with anyone about this is like, is it okay for something to be really powerful in the domain, that it is really powerful and not have 

One of my favorite analogies for this is the floating platforms. I think the complete word is from Gregor Hohpe. But you can think about floating anything where we are perpetually commoditizing things. We see this in the idea of Wardley mapping where things are not static; they move along in evolution from innovative through to becoming commodities in the market. And if you were to say to somebody 50 years ago that power cycling of the data center and cooling of the day is not going to mean anything in 50 years to 99% of people in technology, that would be surprising in some ways to some people. But actually, 99% don't even think about that on a daily basis. But there is still that 1% that still does. We are still running on someone's machine somewhere. The things that help with data center management are still powerful and still run the world. They just do so from below a certain line of visibility. And so I wonder when it comes to infrastructure as code in this sort of changing needs. So the changing needs from infrastructure that is very low level, the EC2, the service accounts, the VPCs,s and those things. There is infrastructure that is more conceptual, the test environment, the staging environment, the application and its dependencies and so forth. Do you see the infrastructure as code fits better or worse in those different domain models? Do you think that one of the challenges is just trying to shoehorn in the same tools to work across domain mentalities? And actually, that's why we're seeing this break in tooling for the different problem spaces.

Kief Morris: It's really interesting. I think there are a couple of things. So one is the as-code thing, which doesn't have to be about infrastructure necessarily. Right? So we can define all the things as code. We can define our pipelines as code. I think when we talk about infrastructure as code, we're often talking about specific tools. As I was saying before, they tend to be the tools that are working at those low-level resources that are exposed by the infrastructure platform or the cloud platform or whatever. I think the challenge we're seeing is that if we're trying to build those higher levels of abstraction on top of it, but using the same tools in the same mentality, and I think that's where, I think some of the issues are, and where some interesting stuff is, is how do you that interface or how can you maybe used to write low level components using code infrastructures code as we know it now? But you write it in a more reusable way, and that kind of thing. And then maybe there's a different abstraction level on top for things like I just say environments. How do I define what's in my QA environment? And the language that I use for that might be quite different.

Because the person using it can be quite different. I think that's one of the key things, actually, with all of this is thinking about who these are for, because with infrastructure code, I think the mentality is still pretty much that the user of this is an infrastructure person. It's somebody who knows the infrastructure deeply and knows how to connect up subnets and routing tables and all that kind of thing. And so I think when, when all the times with the tools, when they're trying to appeal to say developers and say, oh, we're going to provide you with this level of abstraction. They're still doing it in a way that is suited for those, for systems, administration types.

I think that's what's got to change. But to think about who's using these things at which level, and then what they need to know? Another thing I wanted to say, just because we're talking about the abstraction layers, something I always think about with that is that it's important. Abstraction shouldn't hide an illusion and make it accessible to stuff below it, right? We often need to know that. Right? So you might need to know things about your, the power in your data center, or whatever word power usage may be of the things that you're doing. What's the impact? So, Martin Thompson wrote ages and ages and ages ago, a post on mechanical sympathy. Right. Which is just this idea of as you're writing at these levels, these higher levels of stuff with, he was using examples of Java code. It's really useful to understand what's going on underneath. And so he gave some examples of understanding the CPU architecture and how big are the caches? So that when you think about defining, your variables in Java, there's ways that you can do it that will really, can really optimize in some cases. You need to know that in some you don't. So I think of abstraction as being about, it's a cognitive, not cognitive load that's a popular face these days, but the cognitive scope. I want to focus on the business problem. So I want to be able to work at that. I want to focus on the environment, defining what do I need tested and testing my application. I want to talk about that and think about that. I want to be able to switch down if suddenly there's a performance issue. I need to drop down and look at, okay, what's going on with those networking things, I want to have the ability to do that. I just don't want to have to do it when I don't want it.

Recommended talk: The Evolution of Infrastructure from Code • Adam Keller, Elad Ben-Israel & Eric Johnson • GOTO 2024

Progressive Discovery and Domain Modeling in Infrastructure as Code

Abby Bangser: I actually that's a really interesting concept. I've been looking into a bit in the platform space around the, there's a term called progressive discovery I think is the term, and it is an idea of the idea that you should be able to do the easy thing easily without having to worry about all this stuff. But the idea that over time you're going to grow in your needs, you're going to grow in your customizations and in your optimizations and things like that. And so you can progressively get deeper and more integrated into things. But I think that's a really interesting challenge when it comes to anything as code or anything as design abstractions and APIs. How do you create that in a sustainable way? So I guess, maybe this is more of a tactical question than we often get into, when it comes to structure as code, but do you cover or do you think about with your clients and with your book and so forth, any of those conversations of how to do progressively? Someone wants to start with a small database, but over time they want to be able to optimize that database in more aggressive ways or more complete ways. How does that work when you're designing and architecting infrastructures as code systems

Kief Morris: It's a good question. I do talk about that a bit. So I talk, in the book about application driven development. That's just the idea of starting with your thinking about the application, what does it need and then designing down. I think that's part of it. And then I think what we're talking about is probably the incrementals or the slices, and so you and I have done this when we were on another project that we were on, we did this thing where we were trying to build out, make a roadmap. Basically, they're building out all the infrastructure that was needed for an organization that was going to the cloud for the first time, and doing their development and deployment and delivery in the cloud. And the idea there was to try to rather than mapping out here's all the things we're going to need and to be done. And so then building those out in some, it's what's the first task that we would like to be able to do? And then what is the minimum amount of infrastructure that we need to do to implement that? And even for some of that infrastructure, other simpler implementations. So it's like, I think I remember in that case, it was there was an aspiration, they want to use Prometheus for monitoring. And we're like, okay, that's cool. It's going to take a while to build that, right? From scratch, and build out all the infrastructure to host it, all that. So let's start out in our first iterations with these using CloudWatch because it was on AWS. And it's like we can get that up and running quickly more quickly. So we can get to the point where deploying an application, in a simple way or a simple application that maybe then the first time, the first instance doesn't need a database. So we're going to, what's the simplest slice that we can start with. Because the infrastructure always just balloons out the even the simplest slice of application functionality is the infrastructure is like an iceberg kind of thing. You have to build all this just to get to that. And the more you can do to shrink that,

Abby Bangser: I might still have scars from looking at application logs in CloudWatch, but it was the right call because, as you say, large icebergs. You have to sort of slice things eventually somewhere. But it's what's interesting is you're talking about these complexities and wrapping around them. What I'm sort of hearing you talk about is essentially domain modeling and domain driven design kind of things.

I think that's one of the really interesting things I've found now that I'm starting to get to as, as Bridget likes to say, a gray braid, rather a gray beard. But, we often see that this swing of things, when something new comes in, it's throw away everything we've been doing, go straight to this new thing and almost have to relearn a lot of the same lessons that we've learned previously. And, and there I think one of the real special superpowers that you and I have and anyone who's worked in consulting has, is seeing patterns across domains so much more quickly than if you are working traditional jobs with 3 to 5 years experience and seeing one domain, and then maybe even staying in the same domain at your next job and so on.

So with that in mind, you're talking about infrastructure as code evolving. You're talking about new tools, System Initiative and other things. What do you think we can learn from our years of infrastructure as code or our editions of the book on infrastructures code, our decades of experience that we can apply to make these new models even faster, to be efficient. Right. You know, faster to be scalable and successful.

Kief Morris: I think so. What I often think is in addition to us having worked, is consultancies are getting exposed to a lot of different organizations and domains is, working at ThoughtWorks, it's primarily a software delivery consultancy. And so it's always been a big focus on, software architecture and software delivery approaches. So continuous delivery, microservices and all of that. And I think with infrastructure, it's been so it's like different people doing that. So infrastructure people, even those who are working with say, agile software delivery teams weren't necessarily applying those same concepts, to how they built the environments and all that. And then being able to do that with code then opened opportunities to think about things like automated testing and TDD pipelines and all that kind of stuff. And so I think it's that kind of thing. It's looking at, what are the things that we've learned from software, general software development and architecture and delivery and how can we, bring more of that to bear? And so you mentioned domain driven design, and that's a perfect example, right? Because it's like, one of the things I often like to do on a project is, so first of all, I like working with the teams that are building the applications and thinking about that, because we again, we're starting a application driven development. We're starting with that. We're doing, say, the domain modeling for the business domain.

And then we start, building down from that. Okay. What needs to be in place in terms of, say, technology domains? So, monitoring and availability and storage and these other things. And so you think about those domains as well as a domain, part of the domain model that extends down into from the business capabilities to the technical capabilities.

And so then, I think that that leads natural to think about things like so microservices. So right now, one of the things that people often do with infrastructure as code, is they build big projects, and maybe they modularize it code wise, but then you still end up with when they run, when you run the command to, terraform apply or what have you, it can take an hour or two hours, for it to run and then something breaks halfway through and you're like, it's all posed.

So I think that kind of thing of can we move away from monolithic, deployable units to smaller, whether it's micro microservices or somewhere in between. But just things that are more, I guess, tractable, which also helps with then doing things like automated testing and with using pipelines and all those kind of things. As with software, right? We found that, all of this stuff went together. You can just we're going to do TDD and write unit tests for a big spaghetti code base. We had to organize it better and break it down into injection.

Abby Bangser: Need to come it and. 

Kief Morris: I think we're still figuring all that out for infrastructure. I think we're still not there yet in terms of how to best make use of this, because it is there's a lot of the concepts that that apply. But you have to apply them maybe in different ways. And so, I think we're still learning as an industry how to do that well.

Abby Bangser: So do you think that given in the end, I don't think anyone I'll start with saying, I don't think anyone would challenge you on that. I keep my my background is starting in, in software testing. And I would say that's still a challenge whenever you get into conversation about infrastructures code, it's what does testing look like? Am I testing that my declarative code has done the thing that I declared because in some ways, and you're just testing the framework you're depending on or whatever, right? So there's all sorts of questions about that and the feedback cycles and the cost of both your pocketbook and the environment. If you were to create test environments and on every push and all those.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

AI and the Future of Infrastructure Management

Abby Bangser: Lots of challenges that are domain-specific to infrastructure, when it comes to those auxiliary requirements of delivering code, right, like testing and, and so forth. But I'm wondering, given that we haven't knocked those on the head, we haven't actually figured out exactly what that looks like in the infrastructure space, with this influx of code generation through AI. And, interaction with, code via servers and access and more and more of things, do you think that infrastructure is as poised to take advantage of that, in a positive way as software would be, or what do you think would be the challenges there, of applying the same sort of thoughts into the.

Kief Morris: I think there's a really interesting potential, with using the LLMs and, and other technologies. I think some of the biggest opportunities that we've seen people exploiting are in the troubleshooting and that kind of thing of, all this information in the couple together and, and make sense. So that's a really interesting area I think for creating infrastructure I think so I know there's, there can be some naive approaches where it's like, okay, can you make a chat bot? As again, as we were talking about earlier around moving beyond infrastructure as code. You can just use chat prompts as, as infrastructure. Can you just say make me, a server instance, make me a gateway, and this kind of thing, and, have the AI do it for you. And I think there is some I think that can be useful in some ways, as with code, but I think, it's with software code. But I think there are some things we shouldn't forget. So it's funny. So I was having a look at this, and then I was looking back over the, the production code book and the early chapters, the first couple of chapters, where I talk about, principles of infrastructure as code. And I was thinking about, oh, if you're using AI, are those principles going to apply or did I because I'm like, I was just it wasn't that long ago, but it was a long time ago. And, technology years, that I wrote those chapters, probably a year ago, I wrote those chapters, but I went back and I found, I think they they do hold up pretty well just in terms of it's not just about code. It is. So it is things like make sure you can repeat the things that you do.

So when you create your infrastructure in your development environment, say you want to be able to have the same infrastructure created in a consistent way in each of the further environments, maybe tweaked a bit for things like capacity or what have you. But you want to be able to reproduce it. You want to be able to then modify it. All those kind of things still apply. So I think when we're looking at how to, how to take advantage of, of AI, we need to make sure that we don't just do some code-assisted click ops. AI is just a click ops.

Abby Bangser: It's just getting into that same cycle of, of horribleness of, needing to to back ourselves out of that, turn that click ops into something that can be managed fleet manage over scale and something that can be abstracted in a more effective way. And all those things that we've been fairly plagued with since always, it's just evolutions of it in technology. So what I think would be.

Kief Morris: Cool, I can, picture again. So it's going again with these themes of building up levels of layers of abstraction and stuff or new components that people can use. So I could, for a developer, again, work on okay, I've got this application I'm building, and it's going to need a database, for instance. And selecting the component and how to configure it. So again, you don't want to have to build it from the ground up. But as a developer, you don't want to have to think about that. Right? You're not doing anything really groundbreaking. But there are some things that you do care about. So you might care about what kind of data am I going to be storing in the database? Is it going to have personal information? So does it need to have things around it for compliance and security and those kind of things? How durable does it need to be in terms of backups? Does it need to be is it okay to back it up, once a day, or is it the kind of thing that needs to be backed up continuously? How transactional is it? How much, so there are things that you ought to know as a developer to be able to specify, and so you can give that component. So what I think in terms of code is just if you build components that have those configurable options, because those are the things that you care about. That'd be cool. And then, where I can come in that is coaching you on that. Right? So it's oh, I need to add a database now and then I can be asking you these questions, and I just ask you what's what are you going to store in it? What are you gonna use it for? What's it look like? And asked, guided questions to help select the right options or might even look at your code base and say, hey, I see you're storing some personal information here. I think you ought to use this, so I could see some places where it could be quite useful and quite, helpful to, to people. But I think it has to come in again, in this context of thinking about how you're designing and, and building infrastructure and making the different layers available to.

Recommended talk: 10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023

Business Alignment and Platform Engineering

Abby Bangser:Whether or not you are in Europe, you're going to handle personal information differently than in America or, and so on. So these things are can't be just generic AI's either. There there's going to be entire. There are currently I'm working with them, working with businesses that are building their internal platforms to be able to manage, the infrastructure in such a way that is business specific rather than just generic to the cloud, generic to AI and so on. But what I love that every time I get in a room and chat with you is that you and I are nerds. We we get straight down into the tin. As you might say, we both work in the infrastructure space and and, pretty artsy back end side of things, but actually when you think back over this conversation and I think back over our many years of conversations, so much of it has very little to do with the tech, and it has to do with the world around the tech. And I think that's why we both have been attracted to become team topologies advocates and be engaged in the team topologies world, which is looking at that wider, wider aspect. So talk to me a little bit about we haven't worked together in a few years. What does today look like for you when you're working with clients and you're in different engagements? How much are you working on architecture and business architecture and what that might look like versus, infrastructure, architecture? How do those two worlds meet in your experience?

Kief Morris: I think it's so it's a big emphasis for me these days is, making sure that that, we have a space to talk about that, that we connect it because I think there is, still this idea that, well, infrastructure is just plumbing. It's just, so as a business, we're not here to build infrastructure, infrastructure as a means to an end. And so it doesn't, and we would like it to be, a utility, that we don't have to care about it. And I see both on the, on the business leadership side and then on the technology side that believe leading to to issues where the technology is I'm just going to build the infrastructure. I don't need to worry about what what's running on it. It's just standard infrastructure. I'm going to make landing zones that look like this. Same thing I did at the, a completely different company, and it's just gonna look the same. And then it's not my problem if people getting, trying to make stuff run on it and then you get the business people saying, oh, I don't really care about that. I just want to have it available. But then you get all the pain that comes from, it's like, well, you get the business people when I talk to them, it's why am I always having to worry about infrastructure? Why is it always in the way? Why is always taking so long to set up new environments? Developers are always complaining they don't have access to, or to test or whatever. And it's I think it's because that those conversations aren't happening. And I think it's, I think we need to have this recognition that there is a connection, from the, the business value down to what's going on with the infrastructure.

And I think that the, that layer, that layer of where you can treat it like utility is, it's much lower to me think it's basically at the cloud layer. Right. This is what, AWS and Azure and all the other cloud providers. They have found. This is what we can provide, wrap an API around it and not care about what you're doing on top of it. Right. And then I think we like to think that, oh, you can just have a platform that you deploy on top of it, a PaaS or whatever, and then, buy one off the shelf and drop it in. And then our developers can use it for whatever. And it's like, well, there's a reason why we have platform engineering now and why we have, we've had DevOps and we had people talk about developer experience and why this is such a massive thing. And we keep finding new names for it, new ways to tackle at it. It's because it still isn't. Your business still needs to think about it. You still need to think about for your business, what's the right stuff for what you're trying to do for your domain? What are the variations on that? It isn't generic at that level. And so I think that's what I spend a lot of my time doing, is trying to persuade people who, maybe were asking me to come in now, can you help sort out our infrastructure for us? It's too slow. And then go away and do that. It's like, okay, no, no, no, you're going to need to come in the room with me and sit down and everybody's gonna need to talk about it together and work it out.

Abby Bangser: I mean, I started, as I said, my my career as a QA, the number of people who said, we just need you to come in and write some automated tests, and I'd get there and be like, what? That is not the problem. Let's let's talk about that. But, no, I think what you're getting at is something that, I actually wrote something about, which is platform internal teams have to worry about what is unique to their business, and they can't just take from the cloud and, but is they can sort of optimize across their business. Right. So that it's across teams. And I think Gregor Hohpe says the same thing- the platform is your business tech layer. I think a lot of that is starting to solidify in more reusable language, and Team Topologies is part of creating that language and allowing us to identify those patterns, which has been super powerful.

Abby Bangser: Unfortunately, we're getting to our time today. It's been really fun to catch up with you and all the hard work you've put into the third edition. I can see the evolutions across them as I've been a reviewer of these, and I'd love to see how we're continuing to grow in infrastructure as code. Congratulations on yet another refresh. Any last things you want to share before we say goodbye?

Kief Morris: Not really, other than feel free to reach out on LinkedIn or whatever. I'm always interested in talking with people around the challenges they're having and the things they're doing. The reason I write these books is because I'm learning from other people. I can't come up with this stuff on my own, so I'm always happy to chat with people.

Abby Bangser: Amazing. I can vouch he's a very friendly guy, so please do reach out. It benefits the whole community when we find ways to amplify people's stories. Thank you again, Kief, for sharing all of those stories and your knowledge in the books and here today. Thank you so much.

Kief Morris: Thanks, Abby, and thanks folks for listening.