About this talk
This talk introduces the concept of infrastructure as code (IaC) and emphasizes its importance in modern application development. The speaker, Talia Nasi, shares her background as a lead developer advocate and discusses the challenges faced when managing cloud resources through user interfaces. She explains how IaC automates the provisioning process using configuration files that define the necessary resources and settings for applications. By treating infrastructure like code, developers can version, store, and deploy it consistently across different environments, minimizing configuration drift and enhancing collaboration among teams. Talia also touches on tools such as Terraform, which allow for multi-cloud deployments, and demonstrates the fundamental commands involved in using Terraform to manage cloud resources effectively.
Full transcript
[Music] n e e e testing testing all right hey everybody Welcome to building applications with infrastructure as code my name is Talia Nasi and let's go ahead and get started so I am a lead developer advocate for aami Technologies and my job is just to build things in the cloud and then I talk and write about them um before becoming a Dev Advocate I was a test
engineer so I was responsible for QA automation testing um full like endtoend tests integration testing all all of the basically every part of the testing cycle um before AI I was at AWS on the serverless team um before that I was at Wei work um comp I was a test engineer at Visa so I've worked at some like pretty corporate companies I've also worked at like smaller
companies um and something that I want to talk about today is infrastructure as code because it relates to um a lot of different companies and a lot of different scales you could be a small company you could be a big company um but I want to go through an introduction to infrastructure as code and really understand the use cases and um the why and what some of
the benefits are and then we'll talk about some tools um and then we'll go through a quick demo so many times when developers start building applications in the cloud they they'll start in the console right so you choose the services you want and then you connect them you build your Lambda function here you choose what you want as a trigger for your Lambda function here you want
what do you want is your Des destination you have maybe a database connected maybe a server um and you can create like all the resources you need right there from the console and this is a really great way to learn right because you have this UI um where you can see everything that you have in application the only problem comes when you want to move your resources
to different accounts or you want to move it from one environment to another or just somehow like replicate what you've done in the console so chances are you're not going to know exactly how you set up these resources in the first place and exactly which configurations you set and so to solve this problem we're going to look outside of the console to something called infrastructure as code
so with infrastructure as code what you're doing is you're automating this provisioning process so you're not going to go to the console click on the services you want configure the resources and everything from the UI from your cloud provider what you're going to do is you're going to create something called a configuration file where you define all the resources you want and all the configurations for those
resources and that's how you instantiate your infrastructure so in this configuration file you have one place with all of the steps and configuration for your application that you can reuse whenever you need and the great part about this and kind of the highlight of this is that you treat your configuration files and your infrastructure as code and so what are some of the things we do with
code we version it we put it in a repo in GitHub or code commit or something like that and then you deploy a version and you work on it and then you merge a new version and then you can roll back if you need to so when you move into this new way of of um working with infrastructure as code you treat your infrastructure the same way
that you treat your code so if something breaks and your infrastructure isn't working you roll it back to a different version that was working or you try a new version or you can move it over here to environment you have this flexibility to build change and manage your infrastructure in a safe consistent and repeatable way so why is this important like why is building with infrastructure as
code better than from a UI so by using the same configuration files you ensure consistency across these environments and this takes care of that well hey it works on my machine phenomenon you have one source of truth that's this configuration file and this happened a lot when I was a test engineer like I would see this all the time where I would open a bug um I
would would find something wrong and I would you know take a screenshot and write a defect report and then I would send it over to the developers to say Hey you know this is what's going on and they would respond with oh well it works on my machine so this is something that you see a lot in um the software development life cycle between Dev and QA
it's something that you see um with customer success when they're trying to reproduce an issue that that happens in production um so it happens a lot across many different teams and this is one of the ways that um we can combat that it's also really great for onboarding developers um so like when a new developer joins your team and they're setting up their environment um let's say
it's like their first day and you know they get like this whole book of like okay this is how you set up your environment and it's like 3,000 pages of like this deployment and that deployment and you have to set up all these tools and it's just really overwhelming versus when you're using infrastructure as code all you have to do for the new developers joining your team
is just give them the configuration file and say hey deploy this done like everyone's happy another benefit to infrastructure as code is that it eliminates configuration drift so configuration drift happens when you have a shift in environment so let's say there's an incident one late one night like really late um and there's an incident for your mobile application and you look at the logs you identify what
the problem is and in order to fix it you need to update a specific configuration in production so you make the change in production and you go back to sleep although you fixed the issue you've just created an even bigger divide between your staging and production environments because you didn't make the same change in your staging environment so many times staging environments are not the same as
production because of changes made during Incident Management and this is called configur ation drift so with infrastructure as code rather than having that shift in environments you have one Central Authority that is this configuration file and then you just push the infrastructure changes through it also decreases risk so provisioning all of your infrastructure by hand really is risky it requires a lot of manual work that's error
prone it might require like one single person to do and like what if that person leaves the company and they take all of that knowledge with them so infrastructure as code really minimizes these risks and so by representing infrastructure as code you have these reproducible blocks of code which are far less error prone because your infrastructure lives in a source code repository and all of its history
and its changes are visible to everyone on the team so how do we actually Implement infrastructures code I talked about this a little before with what we call configuration files and um we're going to talk about some of the tooling later but um one of the tools you can use is called terraform terraform is an infrastructures code tool that you can use for defining both cloud and
on-prem resources in these configuration files so I want to take a look at one of one of these configuration files as as an example so one of the most important things to note with configuration files is that they are declarative meaning that they describe the end state of your so you don't need to write step byep instructions to create these resources because the infrastructures code tool will
handle that logic so I don't have to go in and say hey create this I am rooll and then click over here and go to this button and then click on like I don't need to I don't need to say um how to create these resources all I have to do is list them in the configuration file and um you describe what like the overall topology right
so when you deploy the configuration file these resources are going to be either created if they're brand new resources updated if they already exist or deleted if you remove something from the configuration file so in this example configuration file we're saying hello please create this I am roll with these configurations and please create this Lambda function with these config configurations thank you have a nice day so
I don't need to say how to create these resources I don't need to give you know the infostructure as code tool you know Specific Instructions or anything like that your cloud provider will handle this logic to create or update the resources that are in the configuration file there is a core workflow for creating and managing this infrastructure and there's basically three different commands so the first thing
we need to do is write the configuration file and this is where you define all the resources we just saw an example of this you want to create um all of the elements you need and you do that with the command terraform refresh and this will go out and talk to the different infrastructure providers it's going to ask them what is out currently out there what's currently
running um what's the current state and it's going to um this is where like the the first step right like what is currently out there next you're going to run an execution plan with the command terraform plan and so in this stage terraform figures out what it needs to get your current configuration to the desired configuration so let's say you write in your configuration file I want
to create this network on gcp or I want to create this database on AWS Whatever It Is What You Define in your configuration file that's your desired configur fation when you run terraform plan terraform says in order for me to execute this plan and make your desired configuration the actual configuration this is what I need to do I need to create this resource I need to update
this resource the it's B it's the execution plan it's basically think of it as like a diff like a g diff of like the differences between what's existing now and what you want to update and then we have terraform apply this is where terraform performs all of the pro proposed operations and executes the plan it figures out what the right order is to create all the resources
and it executes that plan so it makes your configuration and there's a couple of parts to terraform that are essential to the way it works so first we have terraform core and core is responsible for a few things it takes in that configur duration file again which is provided by us the user it also takes in the current state and this current state acts as the source
of Truth for our environment terraform uses the state file to determine the changes that are that we're going to make to our infrastructure so that it'll match our configuration and this again this state file Maps Real World Resources to our configuration it keeps track of things like metadata um core is also responsible for how different pieces relate to each other and then on the back side we
have providers and providers are how terraform connects to the rest of the world and these could be um Cloud providers like AWS Google Azure Len node AI um they could be on Prem infrastructure like VMware they could also be platform as a service tools like Roku or kubernetes um other things terraform could manage are software as a service so there's also like very high level things like
monitoring with like Splunk and Source control with GitHub um and these are all externally managed services but what's great about terraform is that it understands that all these pieces are related and all these pieces are connected and so you have all these pieces of important infrastructure and you can't deliver your application without your infrastructure as a service your platform as a service your software as a service
they're all part of your logical delivery and when you use an infrastructure as code tool you get this single unified delivery of all of these components and me as a developer like I don't want to have I don't want to have to use one tool for my infrastructure one tool for my observability and one tool for every service that I add to my application I don't I
don't want to have to like piece together all of these things instead I want one place where I can have a holistic view of my application and what's going on on all sides so let's talk about um kind of the adopting the adaptation of infrastructure as code so let's talk about where how do you start so on day one you go from running nothing to running something
and this this is where you provision your initial set of infrastructure and you describe what your desired configuration is so when you run terraform refresh refresh says hey there's nothing existing and then when you run terraform plan plan is going to create that execution and then apply is going to go out and create everything for you because again this is day one there's nothing there then there's
the more challenging day two plus and this is where you have your existing set of infrastructure and you're trying to evolve it you're changing it over time um you're adding new Services you have um existing infrastructure and you enhance it by adding these other elements and you rerun that exact same workflow now there's many moving pieces to infrastructure maybe one day you have a Lambda function maybe
one day you add a database maybe one day you remove that database maybe one day you add a server so you can imagine like over time your infrastructure is going to expand and evolve and you'll likely add different pieces you're going to add more complexity decrease um and you have this process that you can use that's not going to change no matter where you are in the
evolution of your life cycle so then on Day end maybe in the future you decommission your infrastructure um maybe these resources were for a test environment or for some reason you don't need that infrastructure anymore um you can remove them with terraform destroy which is basically a specialized version of apply that will talk to those providers and destroy those elements so there's many advantages to um what's
great about terraform is that your day one experience is identical to day two right so it's something that you're going to keep doing you're going to keep evolving but you don't need separate processes for each stage of development another Advantage is on Day end where you you know you can you maybe you don't need this infrastructure anymore um you have the option to destroy which cleans up
your environment and so in this life cycle you go from you evolve this day over day and then you can decommission it so as your team grows it can be challenging to manage your infrastructure and so normally companies will start with a single individual practitioner who's creating this configuration file locally right like there's one person they're like the devops person and their workflow will start with writing
some terraform configuration and then they'll they'll go through that that process that we talked about and it's one person and they're going to continue to to evolve that infrastructure um by themselves and now what if you go from running um from a single individual to now there's like multiple teams maybe now you have like a devops team and other people want to collaborate on managing the the
same infrastructure so how do we make sure we have a consistent view of what the current configuration is and make sure we don't step on each other's toes right because we're going to be making multiple changes in parallel and what we do is um there's something called terraform Enterprise which you still write your configuration and you plan it locally but now you push your plan into a
Version Control System something like bit bit bucket or GitHub basically you move this to a central repository where managing this and you're coordinating um changes and then your company does really really well and maybe you have a lot of teams that are working on your so there's people who don't necessarily need to know about all the parts of your infrastructure like maybe there's new developers or maybe
there's like I don't know some business people who don't need to know every configuration for every piece of infrastructure so what what you can do is use something called a module and a module is like a black box of infrastructure and um what happens is you define a set of input variables that let you toggle the behavior of the module and the module might emit a set
of output variable so basically it's a container for multiple resources that are used together and they can be used to create lightweight abstractions so that you can describe your infrastructure in terms of its architecture rather than in terms of its physical object so basically you can you can um manage a group of related resources as if they were a single resource and what you're doing here is
you're encapsulating the complexity and you're making it more accessible to a broader audience because a developer might not need to know all of the details of every part of your infrastructure or of one specific part and even for like you know if you're following the the the principle of least privilege like it might be better for some people to to use this modu modle now how do
we manage all of these modules what well something that you can do is publish them to a central repository and there is a central repository that exists today and it's called the terraform registry so if you go to registry. terraform doio it's the global public registry and you're going to find common forms of infrastructure common architectural patterns and what's great about this is that most of them
are published by the cloud providers themselves and it just makes it so much more consumable for us to go in and um you know I don't have to know every detail of how to create a Lambda function and everything that happens in the back end I can just go into the registry type in Lambda function and find the code that I need and copy and paste it
into my registry so I can go in and say I want this network from Google and fill in a few of the inputs that matter and then let the module take care of the complexity another benefit of using terraform is that you can do multicloud deployment and nowadays I think it's very rare that companies are using only one cloud so one of the benefits of this when
you provision your infrastructure across multiple clouds is that it increases fault tolerance you have more graceful recovery if like one cloud provider has an outage um and it also simplifies like the management and orchestration of these infrastructures when you're using a tool like terraform um so just another benefit so I just quickly want to recap before we get into the tools infrastructure is code like why do
we use it why is it beneficial what are the advantages so first it enables everyone to be able to self-service their infrastructure regardless of your devops experience um you can implement the the privilege the privilege the principle of least privilege um and use modules for people who don't necessarily need to know like all the physical details of the infrastructure um you also get this natural progression from
day one to Day 2 plus to dayn and you don't need to change a lot about the existing processes um when you use infrastructure as code you get this single unified delivery of all of your infrastructure as a service platform as a service um software as a service components and again I don't want to have to have to application I have this one single components and I
get this really holistic view of what's happening in my application you can import your existing infrastructure if you didn't start building with this um you can do multicloud deployments um you can also optimize your Cloud costs um there's a lot of um stuff on pricing with es I know like terraform just Chang their pricing but um it is an open source tool that you can go in
and start using okay let's talk about tools so there's so many choices when it comes to infrastructure as code tools we talked about terraform a little bit um one of the differences between terraform and the other tools that I talked about is that terraform allows for multicloud deployment so you can deploy a database with gcp and an instance from from Len no all in the same configuration
file they also have a registry with pre-made resources that's written in the correct language for those configuration files um AWS has two different infrastructures code tools there's cloud formation which is used for um non-server list resources things like ec2 RDS and then the second one is Sam the serverless application model which is um used for serverless resources and these are things like Lambda functions Dynamo DB tables
sqs Qs um one of the biggest differences between terraform and cloud formation and Sam is that in your AWS configuration files you can only add AWS resources where as with terraform you can have more than one Cloud provider's resources so if if your entire stack is on AWS then yes you should use an AWS infrastructure as code tool um AWS configuration files are written in either yaml
or Json um Google cloud is another cloud provider you can use they also have templates they also have an integration with terraform um you can use a scripting language like Powershell and you can there Powershell has something called the Powershell gallery um which is a central repository for um sharing and acquiring Powershell code um and you can add resources from other Cloud providers as well so that's
a plus so some things and then sorry there's also anible which is more of like orchestration um which you can use with terraform so you know you can use um different tools for different parts of your infrastructure if that's something that you want to do so some things to think about when you're choosing an infrastructure as code tool are you using Services specific to that cloud provider
or external Services as well um and do you want your configuration file written in yaml or Json or a scripting Powershell um are you doing multicloud deployment things like that and the most important thing to take away here is that it doesn't matter what tools you're using to provision and configure your infrastructure I just want you to capture this process in a way that can be repeated
and automated and that's going to make your life a little bit easier so let's go through a quick demo um I want to do this with the lenoe terraform provider so the first thing we have to do is you need to have a lenoe account and you need to install terraform I'm going to I'm going to post the QR code to this at the end so that
you can um go in and create a Lode account and install tform it'll go through everything for you so um if you don't have an account you can create one for free and then you can install ch per forance an open source tool so the first thing you have to do is generate an SSH key and this is how you connect to the server and you use
the command SSH key gen um and then you have to copy your SSH key copy it and save it because we're going to add it to our configuration file next from your lenot account you need to create a lenoe API token um from your from your um profile choose create a personal access token in choose the access levels and then again copy this because you're going to
have to put it in your configuration file so next we need to create your configuration file and save it as a TF file and that's how terraform knows what to look at so the easiest way to do this is to type Nano and the file name um and then you're going to insert your API token you're going to insert your your SS key those are the two
that you just created and then you're going to enter your root password so the resource that we're creating here this is a len Noe instance and we're calling this terraform web example and you can see these are the configurations that we're using um we're saying this is the region this is the type of instance at the top of the page you can see um that we're using
the LOD Provider from terraform this is all from the terraform registry um and again you can copy and paste this from the tform registry so once we deploy this we're going to see um terraform web example inside of our UI next we run terraform init which is going to initialize terraform next we run terraform plan which is going to create that execution plan so what's the difference
between what's currently in production versus um what is uh what I'm update next we on terar form apply and it's going to apply our changes for us and then once we log into we're going to we're going to see this tariff web example created so this is just a very simple example of building your infrastructure with Len node and terraform again here's the QR code um where
you can go in if you have not used the terraform registry I highly recommend um it's registry. tor. um there's so many different providers um so many different resources from different providers that you can use um and you can use um Len no for uh for those Cloud resources we do have a free version so um there's also some more resources you can use on YouTube if
you go to youtube.com Leno we have a great devops Community Len no.com blog um terraform again is an open source project you can contribute to um this is my Twitter account at Talia Nasi I also just created a uh blog and a website it's called build withth talia. comom um thank you all for joining and um please reach out on Twitter if you guys have questions or
comments and have a great day
More from this event
See all 58 talks →
Halil Ibrahim Kalkan: Building a Kubernetes Integrated Local Development Environment
45:20
Paco Orozco: Growing at the Edge: Doubling Traffic While Changing the API Gateway
45:03
Viktor Vedmich: Ideal Blueprint Versus Reality for CI/CD Pipelines
46:03
Koray Oksay: Continuous Deployment: The GitOps, The Pipelines, and The Ugly
43:03