Before we start our episode today. I have an exciting news to share with all of you. I am having a massive giveaway of jetbrains. All products pack, personal licenses for free. Each personal license is worth two hundred forty nine US dollar. Yes. You heard it right jetbrains. All products pack personal licenses, its 100% completely free to enter and I will choose three lucky winners to win those licenses, for more information
on how to participate, please. He's check out this URL Tech lead, you know, that Dev slash jetbrains Dash giveaway. Here's the link one more time. Tecla journal, the dev slash, jetbrains Dash giveaway. I wish you all good luck with infrastructure is code. You're not trying to kind of reverse engineer. Understand what ended up somehow onto each system. You're actually saying, this is how the system is built and because it built from that code. So there is no difference. Hey everyone.
My name is Henry Surya. Juan. And you're listening to the tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello everyone.
Welcome to another episode of the tekhelet journal with me Ojos, Henry Surya. Without one tackle, a journal is also now available as a YouTube channel. So for those of you who love listening your podcasts on YouTube. Please know that these podcast is also available for you to like And subscribe and if you are enjoying and have been benefiting from these podcasts. So much, consider becoming a patron of the Tecla Journal by
visiting the technology node. F / Patron, I will sincerely appreciate your support so much and your valuable support will help me a lot to make the production of the upcoming episodes. Most sustainable and frequent as a patron. You also get exclusive access to Patron. Only contents, including direct personal access to me. So, please, please, please pledge your support at technology. Know, the left / Patron. So, I'm very excited to have Keith Morris for today's episode.
Kiev is the Cloud Technologies at thoughtworks and also the author of The O'Reilly infrastructure as code book. A book that I highly recommend if you're into devops cloud and infrastructure Automation. In this episode. I had an enjoyable in-depth discussion with Keith regarding infrastructure as code. And I personally learned a lot from his massive experience and expertise in this area.
We discuss things like infrastructure as code principles patterns and the patterns pipeline pad versus And the latest infrastructures could new tools. We also discuss about his upcoming second edition of the infrastructure as code book. So, without further Ado, let's jump right into the episode. I give thanks so much for joining me in this episode, or in the tekhelet journal podcast. I had drink. Thanks for having me on.
Yeah, so it's a pleasure to meet you because I read your book few years back infrastructure as code. I must say that it's one of my favorite technical books. So I read it end to end and I got the opportunity to have the book signed by you as well, serious back. So before we go into the infrastructure as code, I want to ask you about your career Journey. How did you start your career? What are the major turning
points in your career? And what led you to dealing with infrastructure as code and ended up writing the book? Okay. So how far back we want to go? I mean I started out not in it, but I was doing it as a hobby. I was running a bullet. Board and doing that kind of thing. And then decided I was enjoying that more than what I was doing. I was managing, like movie cinemas. I was in a movie cinema company and so I decided to go back to University and got my master's
degree in computer science. That was around the kind of mid 90s. The internet was a thing, but it was only just becoming a big thing in the u.s. At least before it kind of started growing bigger. So it's still quite knew it was still kind of a niche, but it was a lot of fun. And so I learned about Out Unix. And I learned a bit of programming and all this kind of stuff. And so I worked, I got a job actually in my computer science department in the the systems
Administration team. And so the same time that I was taking classes and learning how to program an understanding computer science. I was also getting to actually work with our computer systems and because we had the vendors, like, son and HP and all of the kind of particularly Unix vendors would give us equipment. And so, you know, we got to kind of do quite a lot of interesting stuff and play around with lots
of stuff. That was kind of how I got started in infrastructure in a way and coding was a big part of it. It was scripting like, the way I learned. And that team was very old-school. We compiled applications to make them available to users. So we had to learn how to do that, which meant we had to learn how to debug sometimes code. It was a very kind of, I think good introduction. So I wrote like Perl scripts and things like that to do systems Administration tasks.
And after that around 1998, I finished and I moved to London and I got a job in an industry and This was the.com days were just starting, especially in London. It was a bit slower to pick up that and the us but then did pick up and became a very big thing. And so I worked in different companies over the probably 10, 12 years from there. I worked for several different companies that were what I would call like post startup.
So there are companies that were maybe like 25 to 50 people when I joined and then they grew to maybe a few hundred people. So it's very much about taking something that was already kind of established, but maybe not. Immature and then building it out. So, even when I working across roles in software development or systems Administration, I might work in either a role because it was before devops before you
could do both of those things. But I always kind of found myself drawn to the other side of things. So if I was a systems administrator, I be looking. Okay, how do we build and deploy applications? And then, if I was a software developer, I was looking at, well, how do we kind of configure our environment? So that the thing to stop breaking in one environment when they work in a different environment? You know, how do we make our environments more consistent?
I was always kind of attracted to that kind of thing. And then it was probably around 2008 or so was I think when devops became a thing and infrastructure as code became a thing and when the cloud was very, very early on becoming a thing AWS started up. So all these things kind of converged and they were all like right in my interest areas like, oh this is perfect. And then I came across the continuous delivery book. Actually.
It was in the early release as we do and as we've done in since, with my books, where you can go on to What was called safari and is now called the Riley, an online learning platform or something like that. You can get a pre-release draft of the book, basically, so I found that continuously every book and I was like, wow, this is exactly such exciting stuff for me. It was written by a couple of guys just humble and day Farley, who worked that works.
And so I said, hey, I want to go work with that company. I want to go work with the people who are doing this stuff. And so I joined thought works. I was about 10 years ago. Now. I've been at thoughtworks ever since right. It's very interesting history. I didn't know that you actually interested in writing the book because of the continuous delivery book both. Both books are really awesome actually. So yeah, it's one of those must-read books. I must say. Yeah, I definitely inspired me.
I don't think at the time I had in mind that I would write a book but it's one of those inspiring things. And certainly know what I did decide to write a book. That was one of the ones I looked at as well, as, obviously, Martin Fowler's books for inspiration.
So in terms of, you know, how the book kind of came about, it's funny because, as I said, I've had all that interest in this area and writing infrastructure as code and using cloud and virtualization and everything and working at thoughtworks, I would go and work with Clients where they're asking us to help them to do continuous delivery.
And so, we have to work with their infrastructure teams, their operation teams to say, okay, we need to have environments that are set up in a very consistent way and hey, here's a cool thing. You can do to make that easier for you. You could do infrastructure as code. And so I would be trying to kind of persuade people to do that and I always thought oh, I was waiting for one of the experts right because there are all the people who are the well-known experts and infrastructure.
As code, those people like Andrew Klay Schaefer and Patrick DuBois and all these kind of people these devops people. I was expecting one of them. It eventually write this book that I could then give to these people that I'm working with to
explain. Now, here's how to manage your environments in a nice consistent way so that you can do continuous delivery and eventually at some point, I think some excited, done some blog posts and editor approached me and asked me if I would want to write a book on devops and I said, I tell you what, I know a book, I would like to try to write and so that's what happened. Yeah, I did that. Right, right.
The rest is history, right? They said, yeah, so during that time, what kind of tools that actually exists that let into the whole the creation of more than One tool. So during that time when you set about doing scripting post scripting, are there any tools that stand out from the past that led into the creation of multiple modern tool set that we
see these days. I think the one the first one that I really got a hold of. So I'll tell you that my source of information for this stuff before infrastructure as code was, a thing was a website called a chemical infrastructures dot org or infrastructure dot-org with or without an S, there different sites, but it's hasn't been changed since I think 2007. So it's interesting just as all this was taking off that Like whoever the maintainers were
didn't really kind of carry it on, but it talked about like, automatically provisioning servers and automatically configuring, the two tools. They talked about that I started using. When I read that, where one was called Fai install, which was for Debian Linux. I was using physical servers for this. We would take a server that was in a rack.
You would boot it would hit like the depending on which brand of Hardware. It was might be the F12 button or the F2 button when it boots and you would have configured a
DHCP server. So that when you do that and it boots, it would like download a little installer and then it would install the OS and then the other two will You would use then was CF engine, which is written by a guy called Mark Burgess, who's probably, you know, like the God for the grandfather of infrastructure as code again before it was called that. And that was a server
configuration tool. Very much like so following on from that came, kind of puppet and Chef and ansible all kind of followed in the footsteps of CF engine. So that was kind of how I started doing this stuff. And uncf engine was certainly one of the precursors to all this. And then I discovered puppet when that came out and I thought, oh, this is really
cool. And then later, on, and a team that was working with one of my My colleagues found chef and said, hey, let's try using this idiom OS and it just kind of went from there. Right? So let's start with what is infrastructure as code. Then. OK? Infrastructure is code. So you can divide different ways. People to find different ways. I think it's basically about the idea that the way you manage
your infrastructure, you define. It is kind of in files that you can manage and treat like source code. And so, this is the idea that these things are external to the tool itself. You can put them in a source control system. You can use any text editor, you can use any kind of Tools that manage and interact with text files to do cool and interesting stuff. And then that enables you to do things like take software,
engineering practices. So things like test driven development, continuous integration, continuous delivery, you can start using these techniques for your infrastructure. So that's kind of my basic definition of it. And now I think these days there's a big kind of, I'm not sure if controversy is the right word, but there's a big kind of movement around. Well, should it be coder, or is it configuration? So I'm working on the second edition of the infrastructure as
code book, right now. Now, and one of the topics I'm trying to kind of articulate in there is so we know what are the different types of languages you can use and when are they may be appropriate because so tools, like starting with CF engine, puppet, chef and then the more kind of cloud oriented tools, like, terraform and cloudformation. They're all declarative right before that. We wrote scripts, where you mixed in, how to create the infrastructure with what you want.
So you would have like the kind of Loops in the create the thing, provision a server, and then you would loop on like is it created yet? Wait for it to be created it. An error and all those kind of things you had to do, all that kind of logic around it, but these tools kind of separated that out. So that the tool handle the logic. You just say, I want my server to look like this. I have this much RAM this many CPUs and so on just declare that.
And now it's interesting that we're seeing an emergence of tools like plumy and a double CD K which are bringing in kind of general purpose. Real programming languages that you can use typescript, JavaScript python, whatever Within These tools and that's interesting because in a way it looks like it's going back to the old scripting of infrastructure, but I don't think it really is.
And the reason these tools are popular, I think is because you get these, if you work with much of these infrastructure tools, if you work with like terraform or ansible, you'll see people trying to kind of turn them into procedural languages. You see the languages themselves that the makers of the languages start adding in like, oh need to have conditionals and loops and
and things like that. And then the code gets just really terrible, really terrible because it's kind of declarative and kind of not it's a big mess but my thinking on this is that it's not so much that like one type of language or the other is The right language to use for infrastructure code.
I think it's that there are different concerns different things going on in an infrastructure codebase and some of them are more appropriate use of declarative language and some are more appropriate to use some more kind of general purpose, procedural and object-oriented language. I think as a kind of field of infrastructure as code.
This is all still very new and I don't think we've found the kind of right form this to say like, oh, okay, here's how to organize your code into different concerns and to use different tools and different languages for each. I think we're still discovering that which is quite exciting, really? Really to be kind of doing this at this time and kind of exploring and discovering an
industry. Yeah, so I find myself as well like every few months, should I say probably that new things coming up as well in terms of infrastructure as code. So, previously, I used a lot of ansible scripts and over the time move over to terraform and then with Cloud native deployment manager, and so coming up with like kubernetes config connector, and communities itself is also in a way of format of infrastructure as code, right?
The yeah moans. Yep. So in the book, you mentioned Infrastructure as code is like, managing your infrastructure just like you're treating a software and that's why you apply software development best practices. So what kind of software development best practices that normally applicable for infrastructure as code? Is it all of them or just some of them? Well, I think it kind of depends and it goes back a little bit to that point of where the different concerns in your code base.
So, I mean, typically the things I talked about as practices to bring into it, it very much draws from the kind of agile software engineering. Practices of test-driven development, continuous integration, continuous delivery, pair programming, all those kind of things, as well. As I think some of the design principles have had a design, good software how to keep software kind of loosely
coupled. And so on that, we want that for infrastructure because I think what I've see a fair bit of these days as people who've been doing this for a little while to have very large code bases, for example, I work with the client in London had a terraform project that when you run Tara from apply, it could take two hours for it to finish. So it just kind of this massive project. It was exactly like we talked about software. Monolith was a monolithic project.
And so what we helped them to do was to break that apart into smaller. So taking that kind of almost microservices mentality of how can we make it into smaller pieces that are Loosely coupled and independently, Deployable or a pliable as it were? So for people who are probably new to this infrastructure as code. Can you probably explain? Why should they even learn and do this infrastructure as code? Sure.
I think the value of infrastructure is code is its kind of in the reproducibility and in the consistency. So most of the environment certainly that I've worked in have been wonder where we're doing software delivery. We have test environments may be staging and pre-production, all these kind of environments. And so one of the kind of first things that infrastructure code can help you to do, is to make
sure that those are consistent. They're built the same way at each point and then I think other things infrastructure as code can help with is around, just making sure that you can manage the amount of stuff you have. So, one of the things that you see as you move from a The center where all of your servers are hardware and maybe virtual machines, but they have kind of a physical limit. There's only so many virtual machines. You can cram onto the hardware that you have in your data
center. But then when you go onto the cloud, you can create so many more and it get out of control. And so, how do you manage all of those things? And I think infrastructure as code gives you a very good way to manage that. So rather than using maybe an automation tool that's like a gooey and then it has the configuration information inside, an internal data files, having it as code in the source control.
That says, this is what my infrastructure should look like, means anybody can look at it. So new members of the team can join in and they can look at the infrastructure code and say, oh, this is how we configure an application server. This is what our databases look like, very easy to see that and then also the processes Force. Okay, how do we provision a
system? How do we deploy software being able to look at the code for that as quite a helpful and that helps as well with more controlled environments and we have to worry about compliance. I can financial services and so on. Because you know, that stuff can be auditable. You can show an auditor. Look, here's the code that defines what our system. Looks like here's where we Define our security rules.
Here's how changes are made. Here's what changes have been made, because it's in our source control history. And if you're using something like a continuous delivery pipeline, you can say, oh, here's the logs of, like, every change that went through and was made to our system and who made it. And what test did we run? So that becomes a very strong story for kind of compliance and auditing as well. Yeah. So what kind of problems if let's say people do not adopt
this infrastructure as code. I mean, traditionally going back years we have seen without Out infrastructure as code. People can still build and manage their infrastructure. But what kind of problems that normally exists if they stay on and do without infrastructure as code, I think without infrastructure as code, what you often find is that especially for a system of any significant size. You end up with lots of different things and lots of different versions of things running.
So if you're looking like patch levels and so on, you might have all kinds of different versions of say Java running across your different systems. And then when there's a security vulnerability is published. How do you roll out the patch?
Is with infrastructure as code. Makes it very simple to roll out patches and keep everything at a consistent level without that you tend to have a little bit more of a chaotic environment and then it can be difficult where you're like deploying an application and it works in one environment and not another environment because there are differences and it's hard to kind of understand what those differences are because you have to maybe run some tools to try to analyze what's on versions of
different things are on there. But with infrastructure as code, you're not trying to kind of reverse engineer or understand what ended up somehow onto each system. You're actually saying this is how this System is built, and because it built from that code. So, there is no difference. Right? And also, I think the term snowflake service is one of the challenge. Yeah. Yeah, exactly.
The snowflake server. There's no fix the system is like the one that everybody's afraid to touch or you can't rebuild it. You're like, oh, nobody really knows how to rebuild it. We've tried to kind of move off of that and onto a new version of the operating system, but we still have to run the old operating system version that isn't supported anymore, because he can't figure out how to rebuild it. So there's this one term, very commonly mentioned. When we talk about
infrastructure as code. Which is Pat versus Capital. Can you explain to us? Like, what is Pat versus Capital? Yeah. So like a pet is like systems that you really love. You've built them by hand very carefully and I used to love this right back before, even the early days where I was using
infrastructure code. Like I mentioned with Hardware every server, like, we gave them special names, we would have like a theme and so, when one place, I worked all of our Linux servers were named for Planet, so we had, and we didn't have very many right at Jupiter and Saturn and Pluto and So on, we have some other servers that would be made me the names of the moons Ganymede and Callisto. And so and that was fun.
Right, you know, we love doing that, that you would work on Saturn and make sure that it was configured nicely, and everything. And then it was somebody from my mentioned in the book and I can't remember the name of the person somebody from. I think from CERN in Switzerland, who did a talk. He says, where I learned. It was a talk, they gave around treating your servers, like
cattle rather than pet. So cattle her like, you don't have an emotional attachment to them because you have too many of them, and you're going to this, kill him anyways and eat them or whatever. So much, the idea that your servers and other Part of your infrastructure, you should be able to destroy it very easily, and recreate it and reproduce it. And we talked about utility computing or used to talk about utility computing in this kind of like that. It's not especially hand-built
thing. It's more industrial era for infrastructure, right? So when we adopt this, I see, do we have few principles in mind, for example, if you think that I can think of is in seems like infrastructure as code, is supporting disposability. Like you also mentioned a couple of times a reproducible. So are there actually The principles behind infrastructure as code.
Yeah, so some of the principles as you mentioned, there's the idea that you should treat all of your systems as disposable and this helps with being able to kind of know that you can rebuild something. So helps kind of a disaster recovery and continuity to note. If any part of my system is destroyed or compromised or whatever. I know I can just destroy it and build it again. That's an easy thing to do in a common thing to do. So that's one of the principles and that could undermine the
idea of kind of unreliability. So originally, the idea of the cloud was that the hardware might not be that reliable and it shouldn't matter. You should be able to have run reliable systems on top of anyways, and you see that if you have that mentality, when like there's a failure of a cloud, like, when one of the Region's native, iOS has a failure. You see some organizations are down and other organizations are
not. Like, Netflix is the classic example of, they're really good at making sure that they carry on running, even if different parts of a SS go down. And that's because of that mentality. They treat everything is reproducible and assume the system is unreliable as being able to reproduce everything kind of on-demand. There's I think, consistency and kind of trying to reduce variability.
I don't think this is something I put necessarily in the first edition of the book, but it's the idea that you try not to have too many different versions of things running. You try to keep everything kind of minimized and this helps with things we saw this with. I think it was the Heartbleed security vulnerability that got a lot of publicity but the openssl the library that's installed on systems that people found that across their various servers.
They had like maybe six seven different versions of the openssl libraries installed and that makes it difficult to kind of keep everything a consistent. And also just to make sure that everything is Patched in the latest. So I think that's another important principle, right? When we say treating infrastructure as code just like any software development practices. Are there any sort of patterns like in the software world? We have design patterns or some kind of architectural patterns.
Are there any problems in? I see? Yeah, there's definitely. So in both addition to the book I use patterns for various parts of the various concerns. I've got a few patterns around how to provision servers, for instance. It's so there's like the push versus the pull idea. So the push idea is that you have a tool and ansible tends to be designed to work this way. Although you can use the different Tools in different
ways. The idea is that you spin up a new server in the cloud or on a virtual machine or what have you. And then you have a process sitting outside that connects in, Maybe by access logs into the machine and then configures it. So that's kind of a push to kind of provision and configure a machine. And then the pool pattern is basically, where you say, when the machine boots up, it has something already pre-installed. On it that will trigger and
download configuration files. Latest configuration files and apply it to itself when. So it basically pulls this configuration down onto itself. And as with any kind of design patterns and software engineering, there are advantages and disadvantages of each, maybe where they're more appropriate, a lot of people like the push pattern because you don't have to pre install anything on your virtual machines. So ansible can disconnect in.
As long as SSH is configured on there and you can connect into it. You can then go and configure that machine regardless of how it was before whereas the the pull pattern. Tends to work. Well with servers that are automatically provision say like auto-scaling because the platform decides to spin up a new virtual machine automatically. And so it's useful that the machine is able to configure itself, rather than needing to have something else.
No. Oh, it's time to go and find this new machine and figure it right from my personal experience. Reading this infrastructure as code. They are often times when people just learn the tools, like, for example, the most popular one, obviously is terraformed and then afterwards, they learn it.
They did it, they applied it, and the infrastructure is set up nicely, but then, Over time, they go back to, maybe the gooey, console-based kind of changes being made, or maybe they even do like an SSH and go into the servers. So, what are some of the tips to avoid these kind of practices? Yeah, that's quite common and it's certainly the way I tended to start out was using the automation to build things but not so much to change them afterwards.
And what would tend to happen is you'll create a few different application servers. They've all got Java and maybe they're all running Tomcat, but then it's like a one of them is getting higher traffic. Vanessa figuration needs to be tweaked to an optimized to handle the traffic level. So, maybe you write your ansible code to go and make that change to that server to configuration change that application server, but you don't run it on the other application servers.
And then later on, you say, oh, I need to do an upgrade to tomcat. And so, I make my ansible playbook and I try to use it to go and upgrade the Tomcats, And it breaks on some of them because you've made different changes to them in the meantime. And so, I think the kind of anti pattern here is using these configuration management tools.
Structures code tools kind of ad hoc kind of like to make a particular change and one of the stronger patterns that we see to make it possible to manage changes to your infrastructure more reliably and make the infrastructure code the way. The easiest way to do that is the continuous synchronization pattern and this is the idea that your tool just runs in a loop and continuously looks at the version of the code that
should be applied. Your infrastructure and will reapply it again and again, even if nothing has changed and so tools like puppet and Chef were designed to do this. They have an agent that runs. Is on the server and poles, maybe every hour or so, and make sure that it has the latest version of the code. If the code is changed, it gets the latest version and it hasn't changed. It just reapply as the existing version.
And that kind of make sure that everything is kind of pulled in to the same version all of the time. When you do go and make a change and you say, I want to change this one server to optimize it for the high levels of traffic. It forces you to figure out how to do that within the code to say. Okay. Maybe I'm going to make two different classes of application server. Now one is for high-traffic and
one is for low traffic. Or maybe I make the configuration change, even on the other servers and Going to all the servers will now be tuned for high performance. Even if they don't necessarily need it. And so that way it's all kind of built in and all consistent because I think the reason that people end up going and make configuration changes by hand is because, as lack of confidence that the tools are really going to work, and that things might
break. It's what I call the kind of automation fear spiral where the more you're afraid that your tool is going to break something. The more likely you are to do something by hand, which means that it's more likely. The next time that the automation will break it. And so it just kind of goes
downhill from there. And this is also a Well, actually of get Ops as well, which is one of the kind of schools of thought around infrastructure as code, tends to be applied, more in the kubernetes world. But this is a key part of that people often talk about less extra people talk about get up. So I'm using git, branch has to manage the different versions of my infrastructure code for my
different environments. And I think okay, I'm doing good offs, but actually important component of get Ops is that continuous synchronization, the fact that there is a process somewhere and whether it's a tool like we've Works tool supports this with a of working, there's something there that is just kind of continuously checking. The code against the reality and making sure that they match up. So, that's an important thing. I think to do.
Yeah, you mentioned something around automation fear. I think obviously, for example, your case with a customer where the terraform apply runs for like, two hours and SEO infrastructure as code gets bigger and bigger. Obviously, there's this tendency of fear coming in. For example, one line of code of change. Sometimes you don't know, actually, my affect other things. It might destroy the existing infrastructure and recreate that somehow.
So obviously this is one thing that is not so easy, and not so straightforward, especially for people People knew learning about the tools. I myself have seen it several times when I made some changes and oh, it's going to destroy this and recreate this. So obviously there's a lack of Confidence from my part as well, when I do that. So, how do you overcome that kind of challenge? So there's a number of things you can do for that. One is so as we talked about, in that case of the to our
terraform project. It's breaking it down into smaller pieces. And so that when you're running your Terror from apply, it's only running against a smaller subset of the whole. And so that gives you A bit of a conference, you still kind of scared because you still, you know, you can break that thing and maybe you can have a ripple on effects, but it's a little bit more.
Is that blast radius people talk about the blast radius of a change, but how much could you break with the particular change that you're making right now? So that's one thing is reducing, the blast radius by shrinking the kind of scope of the pieces of your system. Now another thing is in the reasons. I talk a lot about automated tests and pipeline for infrastructure as code which is
not really a mainstream things. Not many teams are really doing this and anger for a couple of reasons we can talk about but the idea of Why to do it is one of these conversations. I have with these teams were trying to kind of break apart. Their infrastructure is pick a pipeline for each piece of your infrastructure. And it does a couple of things. One is obviously you can run some automated tests to your terraform so that you have some confidence. Okay, we spun up this part of it.
Subset of the system that the terraformed thing manages, and we ran some automatic test against it and they passed. So we have more confidence that we can now apply this to production with less chance of it failing. The other thing that it does by having this pipeline.
Is it kind of forces you to keep that Loosely coupled thing going with your Imparts, so what will often happen if you don't have the pipeline but you break your system into multiple Parts is it's like okay, we're going to make a change to our application server terraform code. Well in order to test that we might have to create our networking stack in our database stack and all these other kind of parts.
So again that to our Terror form project, I mentioned in order to test one part of it, might still have to run two hours worth of terraform, even though it's all a whole bunch of different little projects, rather than one big project. We still have to do all of that to have all of the
infrastructure. That's the prerequisite for that one piece that were Ali wirthlin changing and so having a pipeline kind of forces you to think about what we did in the software world of saying, how do you do a unit test? We design the components of our software so that we can create an instance of it by itself to do a unit test. You shouldn't need to spin up a database and connect to a
database. That was one of the kind of things that people struggled with unit tests of software was all, we have too much other stuff that we have to create in order to run this one unit test on one component. And so the answer was well to force you to kind of do better design and say, okay. How can we redesign? How can we Factor this component so that it does the same thing, but it doesn't need all those dependencies. We can, maybe do some dependency injection or other techniques.
We can use mocks and fakes and things like that to test just the piece that we're working on and isolation. And so, this kind of stuff comes together. I'd like to break things into small pieces. You need to design them to be Loosely coupled and then the pipeline kind of forces you to prove that that design works by make a change to my infrastructure code. For my application server. I push that into the pipeline.
If I've made a dependency a hard-coded dependency on some other component, it will fail in the pipe. Pipeline because the pythons is what I'm testing it by itself. And so then you have to go back. Okay, how can I redesign my change so that it keeps it Loosely coupled. So people talk about test-driven development as not so much about the tests necessarily. As about design, forcing you to have a better design and it's the same is true for infrastructure as for software, right?
So before we go deep into the pipeline design and things like that, that's one thing that I want to ask as well because you just mention it refactoring. How do you actually refactor infrastructure as code? Because sometimes it involves State, what has been created and how do you actually reflect that? Yeah, it's really good question.
And it's one of the things that adding into the second edition of the book as a topic because it is one of these big things as we get as we mature and do more of the infrastructure code. We're finding a lot more of these sort of the hard Parts. This is one of the hard parts. So there's a couple of things and I think again it comes from looking at the software world. There's a few techniques of things like doing Bluegreen deployments and so on and feature Flags to say that, like,
I'm going to make a change. Every time I am For structure and I can push it through into production. But either it is necessarily lives. Maybe I'm doing kind of a dark launch or Canary release or I'm using a feature flag or whatever. And then also maybe if I'm going to change the infrastructure for my application server, maybe I'm not going to just apply terraform to that. Maybe I'm going to create a new instance of that infrastructure and bring up a new application
server. And then to test that before I flip it over. So that's like some of the options you have. And then with State you mentioned stay because it's like a terraformed thing in particular, especially when you refactoring and say, I'm going to pull apart for example. Use as where you've got like a tariff on networking project that down AWS. It creates like a V PC and some subnets and so on and you've got other projects, which create application servers, which are
deployed into those subnets. And then you say, oh, actually the way we created our subnets in the first place is not quite right. We need to change the size of them, or whatever. At that can really break things. Right? So, one of the things I've seen people do is they basically use the expand and contract pattern from database schema changes. So, this is something if you're not familiar with it's worth looking at.
But it's like, where do you use? Julia to like say fly away, or DB deploy, where it uses scripts to make changes to a database table structure. And how do you do that in a way? That is safer. And so we can do the same thing for infrastructure. So, the example for infrastructure with that networking example, so let me first say like what I think is probably not the right way to do it, but it's kind of common is to say, I'm going to edit the
state file. I'm going to kind of go and you can use the telephone command or maybe other tools. Or maybe you can even use a text editor because it's like a Json file. You can go and edit that scares me. I've been calling that infrastructure surgery. It's like when you're doing brain surgery. Something and you're at risk of killing the patient. So it's very scary and especially in an emergency situation. So the expand contract patterns and say, actually, this is known
as a series of commits. It's not a single change. What we'll do is we'll say, well, first, we'll make a commit that adds new subnets that are in this structure that maybe we needed a bigger address range in there. Maybe we can add new subnets or whatever to be adding the new subnet. But we keep the existing subnets are still there and the servers are still in the existing subnets. Then we can push through changes to the things, like those servers to change them into the
other. Yet. And so, that's a more tractable change in some cases. You might be able to do it, depending on what you're actually changing without interrupting, any kind of service or anything, and some cases, it might mean, okay, that server is going to get rebuilt. But you can manage it kind of one-by-one rather than having to do everything at once because I first we'll change this one server Which is less scary. Maybe it's not public. Facing will change that to make sure. Okay.
Yeah, that work. Now we'll go on to the kind of scarier ones one by one and you do each of those changes by pushing again, pushing the infrastructure code change through your pipeline with tests. So that you're more comfortable. Yes. This is going You okay? And then after you've made all those changes and everything is moved over into the new subnets, then you can push the change to delete the old subnets to clean
them out. That's the contract, you've expanded it by creating new subnets, moved everything over and then contracted by removing the old subnets. So, that's a pattern of seen people using with infrastructure as code. That can work quite nicely right, so that the common case of refactoring, which I find sometimes it's difficult. Again. This is based on Tara phone, when you create something and then you realize, oh, we can create a module that can be
reusable, for other use case. And that's when you actually create like this abstraction, or we need to add the module name, +. Something and that ends up in changing the state. Using some commands. Sometimes, it can be very scary. Yeah, so that kind of situation. I still could not find a way of how to solve that. You have some experience around that. There's a few things here. And so I don't know if it's related exactly to what you're talking to.
What are you talking about? Like we have terraform projects that are getting their dependencies from other terraform State files in another project. So let's say we have a terror Like pure just without module and then we can see a pattern emerges like, oh, we can actually create a module out of this few resources. And then that's when we extract that out as a module. But then when you have already applied that to an environment, the state actually doesn't recognize the idea of module.
And then after that, when you make that change, when you introduce that module, you kind of need to apply that to the state introducing this naming of the module as part of their insults. I think that might be an example where you could use depending on exactly the Specific situation. You might be able to use to expand the contract for that, where you introduce the module into your project and create the thing. But you don't necessarily right away move, the old thing into the module.
And then then make a series of code changes that you apply one by one that kind of move things over to using the module. So possibly, that would help. I mean, it may also end up that you need to do those State file changes. It's one of those things that like I said is scary and we like to avoid if we at all can, but sometimes end up having to do that. I think you can potentially script though. Things.
So if you think about it again like database Delta's where you say, okay, I'm going to have a script that makes that state file edit, but it's going to be a script and I'm going to first do it in a test environment and then I'm going to come on little test that says did it work and then push the change on the next environment. So it's a hands-off thing. At least you're not doing the surgery by hand. Right? Right. So yeah, let's go into the design of this pipeline.
Obviously, we have application code and now we have infrastructure code. How do we structure our repository? That's the first thing. Do you put them all together in one repository or do you separate them? How Do you actually design the CI CD pipeline? Are they separate pipeline that will converge at some point in time, because there are different versions of Interest code and there's a version of application code as well. And then lastly about the
testing. So how do you apply the testing in between like, you have a set of infrastructure as code? You have a set of application code and they merge into one. And then how do you apply the testing on that? Okay, good questions. So, start with a code base design. I think this is one of those things where there are patterns not necessarily a right. Wrong answer or best practice or would have you.
So I tend to think in terms of there's the Conway's law thing of your system design is going to reflect your team design or they should align. And so I think I tend to kind of start from thinking about what are the applications and the system structure, the infrastructure architecture that you want and your team structures. You should kind of line those up. And I think code based design will tend to come out of that.
So you don't really want to have a code base where multiple different teams are all making changes to it. Unless you've got good kind. Of tooling around that to manage that. So you kind of have to think about how you manage changes to that. So a typical kind of thing to do is to have separate code. Repositories may be based on teams. And then the question of should my infrastructure code, and my application code being the same repository.
It's like, well, is the same team managing both of those, which they might be, you might have OK an application. Team owns its own infrastructure or parts of the infrastructure that are relevant to the application. Think that's often a good way to look at it and then maybe other teams manage infrastructure. That's more shared mind so you can organize your repositories that way.
So Pretty common pattern. There's a mono repo pattern, which is where, like everything is in one big repository and famously. Some of the companies like Google and Facebook use this. And I was writing about this actually in the second edition been trying to define the mono repo. And one of the things that occurred to me that I realized, as I was talking about this and talking to some people about it, was that mono repo isn't really about is having all of your code in one repository.
What it's really about is how you build your code. So with Facebook and Google, they use tools which basically just run your build and it runs the build across the entire. Pause ettore all the projects that are in it and it's obviously, they're very intelligent tools that work out. Okay, you only change the very small part of the code in the
repository not everything. So it doesn't rebuild everything from scratch every time and similarly, like it runs tests then based on what's actually changed and that's the kind of key thing. I've seen people put all of their code into a single repository, but then each of the projects was still separate would still like compile and build and as separate builds and separate pipelines.
And so I don't think that's the true mono repo because I think the mono repo thing is really it's a build strategy rather than a code organization. Valerie necessarily. So then I think you're asking about pipelines and how kind of pipelines map on from that, but I think it's really about the different pieces that you have and then how they come together. So I see a pipeline as there's a couple of things.
When you go from left to right, the start, and then going to the right of later stages in the pipeline. There's a couple of different things that are happening. So the classic thing is that like the early stages are the things that run fast, fast, test, like unit tests and so on, and I think that's true. And then the slower tests and the broader scope. Tests like Journey tests that go across the user interface of a fully integrated application tend to run later in the pipeline.
And then I think another dimension of that is it's the components. So I think what you tend to want to do is you're trying to break your system apart into small pieces and to be able to test each of those pieces individually. And so, early pipeline stages, will tend to be a first build, a component on its own and test it and make sure it's good and then promoted along and then later pipeline stages, my aggregate some of those Components together, and the components can be various things.
They can be like application, code, libraries Java. Libraries. For instance. I'm going to test my Java Library, first with unit tests and so on. And then I'm going to test an application that builds a war file by pulling different Library files jar files together. Then similar with infrastructure. You might have I've got some code which is going to install Java and Tomcat onto a server. It's ansible Playbook. And so you probably want to have like a pipeline stage was just
test that Playbook on its own. And it can do that very quickly because it doesn't need to necessarily create a server in
the cloud. It can unlike a Docker instance or something like that where it just says simple Linux image run the Playbook and then test did it install Java and Tomcat correctly to do what I want there before you then progress that on and say okay now I've got something which is like an answerable role of an application server and that takes in not just the Java and the Tomcat but it also puts on the monitoring agent and sets up user accounts and whatever else
we want for an application server. And so it says, okay, now I'm going to test those all those playbooks together and see does that create a server, the way I would want and Test at that level. And then you might have the code whether its tariff or more handsome or whatever, which says. Now I'm going to create the infrastructure for my
application server. It's going to create obvious going to provision a virtual machine or an auto scaling group, the load balancer, some networking, roots and security groups that open porch to it and all the kind of things around the application server. So I'll provision that on the cloud. And then, I'll bring the other things in and test those together.
So, you can see the each of these kind of like aggregating piece by piece putting the pieces together step by step and then testing that they work together. Integration testing and I kind of Incremental way. So that's the kind of classic thing to do that kind of fan in and say, we're going to bring all these kind of pieces together, and then, once we've tested them all together, we might progress them to a later stage. Maybe after doing the automated tests.
We make it available to human Q&A to do exploratory testing or what have you or you 80. So users are going to look at it. And then we approve it to go on into production. That doesn't necessarily scale very well at very large scale. So if you've got like a dozens of teams much less hundreds of teams all building stuff having all their work trying to come together and run a massive integration tests across everything. Becomes unwieldy and intractable.
So what you can do there instead? And this is kind of draws from the microservices way of thinking, is this, actually, we can push different parts of our system straight into production. We might do some contract testing or we might test against instances of other parts of the system to make sure it's okay, but we're not going to try to
couple the releases. So as an example, let's say you have a team working on shared networking infrastructure, those V PCS and subnets and so on. And that's a terraforming project and you've got another team which is building an application servers and The infrastructure for the applications, you might say that the networking team can go ahead and push changes to the terraform code for the networking through the pipeline into production on their own.
And they don't have to make sure that they can run a comprehensive test across everything in the organization and then simply the application server team can push their applications through with and change it to their infrastructure, but it's decoupled and that just means you need to do a little bit more thinking about the contracts between those different pieces. And how to test that. They're, you're not breaking anything. I'm not making a change to my networking that's going to break
other people, but you Do that? And I think again, this comes down to the good design thing it forces you to kind of think about. Okay. So what are people depending on in my networking infrastructure rather than people just kind of hard coding dependencies to wherever they want. It's like, no. No, I'm going to say I'm going to publish the subnets. Maybe to a registry or somewhere.
These are the subnets that I create and you make sure that you use those and then I can change anything else as long as I keep those subnet ID is consistent, right? But when you say breaking out these component or different parts of the whole giant system, you mentioned something in the book called stack is this referring to That kind of pattern. Yeah. So the stack this is a turn that I've used because the tool vendors don't tend to have a consistent terms of the cloud
formation and AWS. They talk about a stack and plumy also used the same term terraform has a project and I'm not sure the answer was necessarily has a term to refer to it, but it's basically it's like the unit of stuff on say a cloud or virtualization platform like the unit of change. So it's like you've got blob of code that you can change when you apply it, as kind of the scope of what might change
within that piece of code. So, terraformers a project and there's In the state file associated with it. And like I said with cloudformation, it's a bit more concrete because they actually used that term stack as well. So that a big part of especially in the second edition. I think I've expanded a lot more on this and how to do things like integrate between Stacks nicely and patterns for Designing stack so that they're kind of loosely coupled and everything. And we're two breaks tax apart.
Because as that becomes a bigger than, when I wrote the first edition of the book, most people were still focus on servers. And now, this level of stuff has become what we tend to work with a lot, if you're not working with kind of kubernetes and the layer above that, even, right. We covered a lot of things about testing. So what are some of the tools normally people use to do this infrastructure test? I don't even know whether you can do unit tests. Like, how do you unit test? Terraform?
It's a hard one. Right? And this is, I think something we're still in a lot of churn in the industry about what type of tests are appropriate and useful and valuable and therefore what tools to use for them. So that our unit tests useful. Well, one of the things I'm realizing with looking at the newer tools, like, plumy and cdk, which are using regular language. Is that there's a kind of a couple of different types of projects really that you can think about.
So the typical again, the stack where you're defining infrastructure and you're using a language. If using something like terraform your tend to be defining, the elements of the infrastructure at a pretty granular level. You're saying, I want a virtual machine. Here's my subnets. Here's my roots. Gateways. All the individual pieces are all right there and you have the code directly reflects those. And again, it goes back to that thing of its declarative code. It tends to declare.
I want these pieces to be in place. And so Declarative code tends to have a little bit less value or for testing in that. If you're saying if your code says make a subnet and give it this IP address range. What is your test going to say? It's going to say, is there a subnet? It doesn't have that IP address range and it's like well, with test, you have to be very pragmatic and think about like what's the value of this test? What's the risk? I'm trying to address here.
So when is that test of that? Subnet going to fail? Well, you could have a syntax error, which you can catch beforehand. A lot of the errors that you would catch are actually going to fail when you apply the tool when you run Ply. It's going to tell you. Oh, you can't create that subnet because the address range is not a valid address range. So you never gonna run the test. So I think that the declarative code level, there's not so much value in test particular that unit test level.
It's more when you Aggregate and you say, okay, I've declared by subnet and I've declared gateways and roots and other things now, it's like well can I actually make a connection through all that stuff and get to where I need to get to you if that's where you want to test because that tends to be what goes wrong when you apply your tariff own code and you point your web browser at it and it's like connection refused normal. Where was it? Free?
Fused was it my subnet? Was it, my security group? So that's where you want to have the tests I think is when you kind of aggregate those things together. So that's for the declarative code. And then I think the interesting thing, when you look at using a tool like blue me or the cdk. You're probably not using it for the same thing. And this was kind of a
realization. I had where my first assumption when I saw these tools coming out was like, oh you're just going to click the same kind of project to make for terraform, but it's going to be different language to declared all those subnets and things and so on. But I think actually those tools are probably more appropriate for the ReUse and you mentioned the example, the terraform Are you make modules? Because you identify, there's more reusable code?
I think often that's the situation where you find what the code in. Those modules is the code that you want to say. I want to actually pass in some parameters and maybe do different things. Maybe I want to make a different number of subnets, depending on their AWS region. How many subnets are available there? You want to do more Dynamic things, or I want to assign security groups and this and that based on what you've created.
So that's where I think logic comes in and I think that's where you see the kind of really terrible terraform code of putting in loops and conditionals and stuff. Into your HCL, which is essentially a declarative language and trying to make it procedural. It's because we're trying to actually do a different type of thing. And so this is where I want you to elect blue me to make a library.
That's where I think testing becomes more powerful, more useful because it's like, okay, I'm making a library and it's going to create subnets for me. It's going to create subnets depending on what? Parameters, I passed in again. The number of availability zones that are in a region or maybe the use cases, is it a public facing thing? Is that internally facing thing is These kind of things where you might want to have some variations. So you have this code, which can do different things.
And so that's where you want, some unit tests and say, okay, Make an instance of my little Palou me library, for subnets, and pass in different parameters and then see, does it do the things? That's also, the kind of thing that you can probably do more with kind of mocks and the kind of offline kind of things to where it really is. Proper unit test that will run quickly.
So I think that's kind of where my thinking is coming to of where these different things come into play and where the testing becomes more important, right? If mention a lot of times about plumy and cdk like many times now are they like the up-and-coming tools that we have to explore? I think so.
Yeah, what are some of the good things from those tools again, to kind of recap a little bit about what they do is basically they let you use a regular programming language and off-the-shelf programming language and they tend to support a JavaScript and typescript by popular python for some, I think maybe Java for cdk. I'm not sure this is different languages that they look kind of support. And so I think the value is When you're writing reusable code basically it's where you're not
saying. I'm writing the code, for this one environment. And I know what that environment you look like, but it's like I'm writing code that different people might use or that I might reuse across different environments which are different and so it needs to have a bit more logic going on. So I think that's a valuable thing about it, the other valuable thing. So we talked about you asked me like what tools there are four
tests. I don't think I specifically like list any tools other than to say that there's not as many out there. There are tools out there, but it's not as mature, which is one of the reasons why people don't do a lot of Any of infrastructure, I think. But the thing, when you're using one of these other tools, like a plumeria cdk, and it's like, oh, what testing? Tools are available to write unit tests. Will all the tools that you have for your language.
If you're running JavaScript, there's loads of tools, right and then simply for packaging up your code and versioning it, and promoting it and like an artifact repository. It's like suddenly you have access to that full ecosystem and the things you can do in an IDE with the JavaScript code to kind of navigate and refactor your code and all of that is just Way Beyond what you can do with more infrastructure Focus language like HCL, which although there's support out
there. HCL and similar languages, it's not nearly as wide as it is with the general purpose languages. I think that's a powerful thing. That's useful thing. Right? Obviously in your career. You have dealt a lot with infrastructure as code. Can you probably share it as what are some of the most horrendous and D patterns or code smells in infrastructure as code? Yes. I think the other big projects is one thing. This is massive project which has kind of grown and grown and
grown over time. So I think one of the other things that we see with tariff on projects and similar projects is with Well environments. So it's like how do you define but Dev environment test environment, staging environment, production, environment with terraform?
And I think one thing that you see people do at the beginning common thing to do when you're first starting out is I can't one project that has all the environments in that one project and then you break the project and it breaks all your environments or you're making a change your test environment you Britt production and then you realize that that's not a good thing to do. Let's separate them out.
Then the next thing that people do, which I still think is not quite right and I described it as an anti-pattern is really have a separate project. It's like a separate Tara from project for each environment. Even though it's meant to be the same environment. There are the same system that
you're kind of replicating. So it's like I'm going to make an infrastructure change my test environment, I make it there and I apply it and then I copy the code change over to my staging environment and over to my production environment. This is like copy and pasting is never really a good thing to do with code. Is the whole idea of code is that it's reusable and consistent so on and so on.
So I much prefer having a single piece of infrastructure code that defines your environment that you apply in one test it and then push the same code to the next environment. Which requires To do some things. You have to think about. How do you configure parameters? Because in different environments, you might need like different numbers of servers. If your load balance pool, for instance, but they are, there
are ways to do that. And I think it's important to do that right throughout this conversation. You have mentioned a lot about second edition of your book. I personally didn't know about that and I research about you before this podcast. So can you tell us what makes you write the second edition? And what are the major changes that we should be looking forward to? Yeah, so things have moved on a bit. It's been about 45 years. Now, I think and it's
interesting. So the focus has changed the subtitle of the first edition of the book was something like managing servers in the cloud because like servers all about servers. In fact, now we're talking about stacks and I mentioned Stacks or I think equivalent Concept in the first edition of the book, but it's become much more of a thing. We're spending a lot more time now, on that level of the terror for more the block of stuff in the cloud that you're managing block statement pieces, and
they'll all that. And so, I think that's become important. I think a lot of the topics we talked about today are how to manage that infrastructure and keep it loose. Be coupled in smaller pieces and more manageable. So it's less scary to change. I've learned a lot since I wrote the book, right? I think as an industry we've moved on in terms of what we know and what challenges were facing. So I felt like that really needs to come in there.
So I think that's probably the biggest change is a lot more focus on that level of stuff. And there's a fair bit on those kind of almost design and architecture type patterns for infrastructure stack type projects. How do you integrate the different Stacks by talk? A little bit about codebase organization, the mono repo, and
those kind of things? I talked a little bit about the refactoring stuff that we talked about because again, that's one of those things that we've run into a lot more or something. I've seen a lot more that need covering. So it's a pretty substantial rewrite. I would say, one of the things I'd like to do if I can is find one of those tools that like compares to see, like how much commonality there is between two Tech's. I want to see how much of the book has changed.
I would say. It's probably quite a lot, right? When can we expect to see the book being published? It should be out around the end of the year or maybe the beginning of next year and you can Get access to the draft of, most of the book, I think on the O'Reilly's learning platform, which is formerly known as Safari. So, if you're a member of that platform, if you have access to that platform, you can find it on there. So I'll just ask one question.
We stifle that to us throughout my experience as well. There are many people interested with infrastructure as code, but they have already had infrastructure setup since the beginning and some of them actually dream about having a reverse engineering Tools in which that from an infrastructure being set up. Can you actually come up with automatically? Generated code. So is there such tool that you know of I think there are a couple of tools that you can generate terraform code.
I don't know the top my head, what the tools are. But I know there are tools to pointed at the cloud and it will spit out code that you can then edit. And so on. I tend not to recommend that approach and maybe do it as a kind of a learning exercise to kind of learn a little bit about your existing infrastructure.
But what I tend to recommend is essentially taking piece by piece to existing infrastructure and rebuilding it by writing the code clean and well structured because The reverse-engineered code, I don't think is necessarily going to be well, structured. Well, factored won't include tests and all those kinds of things. So I recommend starting by take one piece, write the code for it, right test for right pipeline for it.
Put it out there. And then using one of the kind of things that we've talked about around expander and contract or other kind of refactoring, patterns of to move, things over to the newly built thing. And then just do that piece by piece and replace your infrastructure with kind of new clean stuff. The same way you do with application code, when you have a model left and you're trying to maybe turn it into a more
kind of micro. Sword, just better factored system right before we end our conversation. Keith as always, I ask my guests to share it as the three technical leadership. Wisdoms. Can you share with us? What are your technical leadership wisdoms? Yeah. I think my biggest one is kind of like harnessing and trusting the power of your team and the people around you, one of things that we didn't really talk about in my career journey, is that I particularly before thought works.
I did manage teams attended to manage teams of systems administrators or developers or sometimes both and one of Of the kind of most powerful things. I found was not thinking that I had to kind of manage everything and decide everything and know everything that's going on, but just kind of like trust the people and be there to support them.
So that's that's like the number-one thing is one of those lessons that I can I can relearn this is, I know that and I learned it and then I'll be in a new situation where I'm kind of not necessarily doing it. And then I realized, oh wait, if I just tell the people and let them kind of decide, then it works out much better. It's much more, scalable and less stressful as well. The second thing is to support that really you need to kind of work out the right level of
guidance and support. To provide to people and that can vary in different situations and maybe I'll cheat a little bit and call that my third one as well, is to be aware of the different situations. You're in, might call for different approaches depending on things like the, maybe the
skill level of the team. So, if you're coming into a team and it's not really going well at the start like they're struggling, you might need to take a bit more of a Hands-On approach and a bit more close involvement and provide more direct support to people and understand what that is and sit down with them and work through things or what have you whereas with With a team that's more experience and everything is
flowing. Well the level of guidance and support you may need to provide is maybe more around the kind of prioritization and maybe even around higher level stuff. Look, these are the challenges that as an organization were facing. So if I'm the one going into management team meetings and we're focused on cost management, or maybe we're not focusing cost management. We need more opportunities for growth or whatever it is.
He can take that back to your team and say, hey, these are the things that were struggling with never focus on as an organization. And so with decisions that you're making with the work that you do day by day. - no need to come in and help you make those decisions. But like this is what you need to know that might help you with that. So I think being there to
support I guess the 123 is one. Don't over manage the people and think that you need to think for them, but do provide the right level of support that they need to know what they should be working on and when they need help to be able to bring that into them and then the third is to tailor that to the situation and their needs. Right? What can people find you online? I'm mostly on Twitter. That's at Keith K. IE F. You can see my mirror. Lot, I do some stuff on LinkedIn
but Twitter's by the best. I've got a couple of websites that I almost never post to infrastructure as code.com with hyphens between the words as where I tend to post things about the book. I'll probably start posting more as I finish up the book and get more into going out there and talking about it to the world mode, right? So yeah, I'm looking forward to the new book and thank you so much for your time. Keith. Nice talking to you learning more about infrastructure as
code. Thanks a lot. Rodney. Henry has been good fun. Thank you so much for listening. I hope you enjoy this episode, share it with your friends and colleagues who would benefit from listening to this episode. And if you liking this podcast, I would love if you subscribe and leave me your valuable review and feedback. It really helps me a lot. Stay tuned for the next technology, you know, episode. And until then. Goodbye.