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.