Contents
Short Summary
What is Infrastructure as Code (IAC) in Cloud Computing?
Infrastructure as code or IAC is an IT practice that codifies and manages underlying IT infrastructure as software rather than through physical hardware components. Historically managing IT infrastructure was a manual and difficult process professionals had to physically install and configure servers and other hardware which is expensive slow and inconsistent.
Infrastructure as code enables developers or operations teams to automatically manage monitor and provision resources.
The code is easy to edit copy and distribute but like in the software design process development teams must control code versions, test iterations, and limit deployment until approved for production.
Some benefits to IAC include
Speed and Efficiency
As it’s faster than manual processes for provisioned resources, database, networking, user account management, and other services.
Consistency
As software developers can provision and deploy servers and applications according to business practices and policies.
Alignment with DevOps
As the infrastructure setup code goes through the same version control testing and CICD pipeline that developers use for application code.
Disadvantages of IAC
IAC requires some extra tools that could pose a learning curve and cause additional errors
Introduces the change of configuration drift or inconsistent configuration items across devices
Places more responsibility on developers to write efficient code
There are two IAC approaches declarative programming which outline the desired intended state of the infrastructure but not the steps to achieve that state.
And Imperative programming defines commands for the infrastructure to reach the desired state.
Infrastructure as code tools basically configures and automate the provisioning of infrastructure. Very Common IAC tools involve AWS cloud formation.
It’s not just you, I hate the AWS web UI myself and the Azure web UI and the Google Cloud web UI. Well here’s a question these are all multi-million dollar companies right? Can they not have a decent web UI for their cloud services?
This is a problem for somebody who’s trying to learn these services. First of all, you’re dealing with like 10 billion services and types of solutions for each of these cloud providers and their UI makes things so difficult that you go there and wonder where do I start?
How can I even begin to comprehend this craziness and even worse, sometimes you create these resources and then come back and wonder, wait! what did I configure for this thing did I change this drop-down value or leave it as default?
Well, I’m happy to say that I have just the right solution for you, just don’t use their UI seriously helped me to successfully ditch almost each web UIs not only one cloud provider but the web UIs for all the cloud providers that I deal with and if you’re thinking to start learning something like AWS or Azure, this is the most convenient way to get started, let me explain why.
What is Infrastructure as Code (IAC) in Cloud?
Okay! But honestly speaking, I don’t think these UIs are bad because people aren’t using these are really smart people working on these things and they already have done a good job considering the situation in my opinion.
The fact is the present cloud services are very complex that it’s hard to build a UI that’s intuitive for all the flaws a bit of an oversimplification alert, but according to me, it’s much easier to build a UI when you know what that actual problem is right?
Designing for a specific flaw is easy but with these cloud provider solutions, you can use these components to build so many things that are hard to build a good UI flaw so that’s why people use infrastructure escort.
You can easily guess by its name, it’s simply coded that you write to create to manage and to tear-down infrastructure instead of clicking buttons and scrolling as such to a provision like an EC2 instance.
You just write code to build, manage, and tear down infrastructure right, infrastructure as code.
I can guess what you’re about to say to create more code for me to learn and write and maintain, well this is not a good idea as these UIs are they’re still manageable should I really be coding this whole thing?
Well, let’s assume that you’re coding on AWS and you need to create one EC2 instance and let’s say three S3 buckets.
If you don’t know what exactly an EC2 instance or an S3 bucket so don’t worry it doesn’t matter for this discussion just a bunch of infrastructure items for you to create.
Now how do you go about creating them all so let’s say you go to the AWS UI poking and prodding and scrolling and struggling and then you set up everything in the UI then your manager comes to you and says nice work setting up our QA environment now do all this all over again for prod or you can guess so as you can see the benefits of infrastructure escort is not just not having to deal with bad web UI.
Repeatable
One immediate benefit you can see is that you have the repeatable infrastructure you can have a set of configurations that you apply for one environment and reuse that for building the exact same configuration, the exact same infrastructure in a different environment.
you won’t have what’s referred to as configuration drift where you have different environments which are supposed to be similar but because of some changes that you did in one and you forgot to do another configuration of begins to drift apart between those two environments it doesn’t happen in infrastructure as code.
Infrastructure Automation
There are other advantages the obvious one is that you’re automating this whole process of building infrastructure rather than clicking around and using manual steps to configure your infrastructure in the web UI you’re writing code and automating this whole process.
Integrate with CICD
You also have the ability to integrate this with the CICD pipelines so you have multiple people working on this codebase which is infrastructure as code and when something is checked in you can have a build pipeline run and actually provision the infrastructure for you and it becomes a part of the build process.
GitOps
The other benefit of having it be in the code is that you have the ability to leverage everything that Git provides for your application code base and use that same thing for your infrastructure code base as well.
So for example infrastructure variation can be normally a pull request to your infrastructure as a code base and you get the same advantage of code reviews.
Visibility and Auditing
Other related visibility advantages auditing advantages you can see previous versions.
you can revert to previous versions of your code and can always go back in time and see what the previous infrastructure was. It almost acts like a documentation source of what your infrastructure is supposed to be.
Let’s not use the UI you can write code that makes these calls to AWS APIs to create these resources.
That way it becomes repeatable, so first you create let’s say you create a method that creates an EC2 instance, and then this method that creates an S3 bucket then the pseudo-code creates one EC2 instance and three S3 buckets.
Now, this is infrastructure code, I guess technically it is but with most infrastructure as code platforms you don’t write code like this. You create code in a declarative style it’s not just a different way of writing the syntax.
Declarative Style of Coding
It’s basically another way of even thinking about infrastructure code let me explain you an analogy.
Let’s say your roommate or your friend is going shopping and you want them to get you some groceries right, so let’s say some apples some spinach, and some ground coffee now how do you communicate this to your friend? Do you say well okay buddy go to the store go to the grocery store pick up a shopping cart walk to the groceries aisle pick an apple from the fruits aisle put it in the car pick another apple?
No, we are not going to do that at least I hope what you do is you provide your friend a shopping list you don’t tell your friend the steps by step process to get the items. You just tell them about the items. The item that you require is called the declarative style of coding.
The basic difference is that with the declarative style you specify the possible final state and not one by one individual steps.
So your infrastructure score for a few basic infrastructure resources would be just like your infrastructure shopping list like one EC2 instance three S3 buckets and so on.
Isn’t this so much easier than coding these steps imperatively, of course, there is one drawback as easy as it is to just write a shopping list you need a friend who’s going to go to the store and shop those items for you.
So if you write a shopping list for your infrastructure items, who’s going to go and provision those resources in the cloud?
But an interesting news is this pattern is so popular that most of the major cloud providers have a pre-built technique for you to write infrastructures code in this type of a declarative fashion and they have a sophisticated tool that makes it easier.
So for example AWS is something called “Cloud Formation” in Azure is something called “Resource Manager” GCP has something called “Deployment Manager” they all do something similar.
You write infrastructure as code in a declarative fashion using that corresponding declarative syntax or the tool that you’re using and then you run the tool and that tool calls the right APIs and makes the things in your list happen.
Now you’re going to wait a minute I need to use different syntax for each cloud provider. Well if you’re working with multiple cloud providers there’s a better alternative there’s something called terraform.
What is Terraform?
Terraform is an infrastructures code tool that works with all of these popular cloud provider platforms and it’s also open-source it uses a language you may know is called HCL Hashicorp configuration language to define different resources for all these cloud providers and you can run terraform on that language file also.
It’s a common language so you just need to learn one and you have a consistent language and tooling workflow that you can use for all these cloud providers.
So you can have one file which contains an AWS resource and an Azure resource and a GCP resource, and a Runter form on that file which it is going to make sure it’s going to call the right corresponding cloud provider APIs and promising those resources for you.
Most of the time what you do is copy-paste the definition from the documentation and then manipulate these values to what you need but the benefit is
A) The overall structure is the same and
B) You can have code for multiple cloud providers in the same file.
A bunch of Azure resources, a bunch of AWS resources are all set up in the same code, and terraform is responsible for creating the right resource with the right provider.
Working of Terraform
Like if you’re giving your friend a shopping list and saying hey I need some spinach and I need some office supplies your friend knows to go to the grocery store to get the spinach and go to the office supply store to get your office supplies similarly terraform knows if you’re provisioning an EC2 instance it knows to go to AWS and if you’re provisioning Azure it knows to go to Azure.
So terraform has this concept of providers which are kind of like plugins that get downloaded before you run your code.
So these providers know how to call the right APIs for the right configuration and it just makes it happen.
So if you’re provisioning like an EC2 instance on AWS, terraform downloads the AWS provider and that provider knows to call the AWS API.bSimilarly, for Azure.
It makes configuring and even learning about cloud services so much easier. Now this itself is awesome but what makes it even better is a concept called state typically when you’re provisioning resources you already know how many resources you need.
How Does it Work in Different Conditions?
So let’s assume you require five ec2 instances for your app that’s all you need. So if you run your infrastructure score again does it create five more EC2 instances, what if you forgot that you ran the code earlier and you run once more do you end up with duplicate resources?
Now let’s take this analogy of your friend shopping for you. Instead of a shopping list let’s say what you have is a recipe list so you plan to make smoothies and you need five apples and a bunch of spinach so instead of telling your friend, hey go get me five apples and a bunch of spinach what you’re saying is, hey make sure that we have five apples and a bunch of spinach at home all right?
There’s a little bit of a difference here so what would your friend do when you ask them to do this first? they just wouldn’t go and shop directly, first, they would look at your fridge to see how many apples and how much spinach you already had.
So if you already have five apples and a bunch of spinach your friend is going to go okay I don’t have to do anything no trip to the store needed but suppose your friend looks at the fridge and he finds two apples and a bunch of spinach what do they do?
They only need to get three apples from the store right? because what you need for your recipe is five apples and a bunch of spinach so this is a fundamental concept with most declarative infrastructure escort tools.
Instead of imperatively creating your resources you declared them but these tools also remember what they have created for you.
So if you were to make a change to your code and run this tool again what it does, is kind of figure out what the data is right.
It does the work to make sure that what you have provisioned matches what you have in the code.
So for example, if you were to change your terraform code to update the number of EC2 instances from five to seven and you run terraform on that code again it goes well I’ve already created five EC2 instances.
The code will tell there should be seven EC2 instances so I need to create two more so similarly if you remove resources then if you were to change their code and say instead of five you make it three and run terraform again.
Terraform goes and destroys those instances to make sure the resources on your cloud reflect what you have written in your code.
Final Remarks on Infrastructure as Code (IAC)
Tools like terraform or even cloud provider-specific tools like cloud formation keep track of the resources you’ve already created.
So you can run it multiple times and it doesn’t matter. It only has work to do if you have made a change to your code and what is in your code is different from what’s actually provisioned on the cloud provider.
So this is infrastructure as code if you want to work with cloud providers like AWS or Azure I highly recommend you try on one of these infrastructure tools specifically something like Terraform because it’s open-source and you can work with multiple cloud providers with just one tool and one workflow.
