Why Infrastructure as Code (IaC) ?

Infrastructure as Code (IaC) allows you to remove inconsistencies in your deployments and environments allowing you to increase Productivity and deploy faster along with reducing the fear that something will go wrong in your Production environment – it gives you the freedom to make changes without fear!

No need to worry if the configuration has been applied correctly to multiple environments or Virtual Machines – IaC is here to help you with this!

Lets start your journey with IaC

Think of it from the perspective of when a manual change has been applied to an environment and something goes wrong:-

• What was changed?
• Did I make a change that broke something?
• Was there a misconfiguration?
• Does it have the correct permission?
• It works fine on another environment why not this one?
• Was there a misconfiguration in my release?
• Manual changes and configurations can take time, this slows down the deployment process

How do I know? In this blog post, I am going to summarise “Why Infrastructure as code?” and help you mitigate them queries from above.

Why IaC?

Source control

A single source of truth!

• Pull requests are code reviewed
• Code reviews increase knowledge sharing which will increase the quality of code overtime
• Can test changes before it is merged, even to a lower environment you can test your changes in the pull request
• Build validation can be configured to stop “bad code” being merged
• Stops fear when making changes, peer reviews assist with this!
• Made a bad change? No worry – you can simply revert the latest commit

Environments can be mutable

Having IaC environments can be mutable, changes can be applied easily

• Variables and parameters stored can be easily changed between environments
• Don’t want an environment to have a specific feature? This part of the code does not have to be included
• Gives you the ability to scale your environments and determine additional features if & when required

Stops configuration drift

Its in source control, configuration drift will be stopped. As mentioned, source control is the single source of truth, making a configuration change? If its not in source control – it doesn’t get deployed!

• No changes can be deployed to environments if not in source control
• Configuration drift cannot happen if their is manual changes
• Different environments may have slightly different requests, use feature toggles!

Test what has been deployed both before and after deployment

Creating IaC you can create so many tests and various testing suites available!

• Test during a pull-request as part of your build validation
• Testing when it has been deployed to confirm the correct configuration has been applied
• Test your environment daily to confirm no changes have been applied without IaC!

Ability to create multiple environments, using the same code-base

Repeatability! You want your pathway environments to Production, mimic its setup! The same configuration to be applied multiple times before its ready to be deployed into production!

• Eliminates configuration drift between environments if you are using the same code-base for all environments
• Ability to deploy environments faster
• Testing of environments become simpler, the same set tests can be created for all environments
• Its easier to maintain multiple environments from the same code-base
• Wanting a testing environment? No need to have it running full-time, just deploy from your code-base!

Can help with visibility

As your environment(s) expand over time, sometimes it may be difficult to understand what has been deployed in each environment or subscription, using IaC? This will certainly help with visibility

• Auditing becomes easier, you can check code & pipelines to what has been deployed
• An issue has arisen in one of the environments, you can check IaC to what & when was deployed, increasing visibility to troubleshooting

Costing

Deploying IaC will help from a costing perspective

• Ability to tag all resources that are being created, to assist from a cost centre perspective
• Not needing that part of IaC anymore? You can remove it again in a few simple steps, cost-saving!
• Performing a costing exercise and notice part of the resources and be down-sized? No problem, change a property within your IaC and receive the costing benefit as soon as possible

Security

Another benefit from assisting with visibility is the increase of security!

• Being able to seeing what and who changed a configuration, auditability is great!
• Pull-requests! These help so much with increasing security – all IaC is peer-reviewed before being merged, can stop unnecessary changes before they are applied to any environments
• Applying new security principals can be deployed at scale
• No need to worry about various security configurations in each of your environments, they are deployed at scale and to every environments when you roll out

You can roll back changes easily!

Yes, it happens – deploying a change and notice something is wrong, whether a mis-configuration or its causing an issue within your environment – even though you have tested your change..

• Having this in IaC is a huge benefit, you can roll back easily
• Review the changes and revert to a previous code-base
• Can revert some changes, not even all – IaC is just great!

Troubleshooting

Its all really piecing together, the auditability to the rolling back of changes easily, all this is helping with the ability to troubleshoot so much easier!

• Knowing exactly what has changed via source control without the need to review numerous activity logs and asking colleagues to understand what was changed & when
• IaC at your finger tips, ready to be troubleshooted
• Writing IaC? Add in tooling to assist you with troubleshooting!

Introduction into Continuous Integration & Continuous Delivery (CI/CD)

What is CI/CD?

Continuous Integration (CI) is the practice of team members merging their code changes into a mainline branch multiple times per day.

Continuous Delivery (CD) is the process of making regular automated releases every time code is pushed to the mainline branch.

Wikipedia

Its benefit? You can deploy IaC changes multiple times per day, at scale – across multiple environments!

• Ability to adapt to changes quickly
• Introduction to agile development, small changes can be made quickly!
• Pipelines – Create pipelines to deploy your IaC, single or multi-stage pipelines!
• Build triggers – applying a change? Have it deploy to lower-environments in an automated-fashion!
• CI/CD is great, check it out!

Allowing teams to be more efficient

Adding IaC reduces the chances of mistakes and inconsistencies within your environments!

• Reducing human error
• Deploy what is only in source control
• Allowing teams to upskill and use the team further to making the environments even more efficient!
• Less manual tasks, automate were efficiently possible!

Be diligent, don’t make manual changes to your environments – Infrastructure as code will certainly be a game changer!

PS.. Make IaC your single source of truth!

I hope you’ve enjoyed this blog post and it has given you an introduction into the world of IaC! In future, I will blog more in-depth on this subject!