Will this be the year of Infrastructure-As-Code (Infra-As-Code or IAC) becoming more mainstream? Or is this just a wishful journey that will never catch on? Obviously, this is not a new thing but how many companies have adopted this methodology? Or better yet, how many companies have even begun the discussions of adopting this? Do you currently write scripts and save them somewhere and think “Hey I/we are doing Infra-As-Code already”? Well if true then you are not correct. “But why?” you might be thinking. Infra-As-Code is much larger and more dynamic than just writing scripts in a traditional static method. But if you do currently utilize scripts for infrastructure related tasks and configurations, then you are much better off than those who have not began this journey at all. The reason being is that taking an automated and more programmatic approach of configurations on your infrastructure instead of a manual prone to errors approach is a much more predictable and consistent method of configuring your infrastructure components. Now these components can be of numerous types such as servers, network routers or switches, storage components and much more. But for this series of posts we will only be focusing on the network components and how we can look at beginning the journey towards Infra-As-Code.
Below are some of the topics that we will be covering over the series of posts.
- - Infra-As-Code: What does it mean? (This post)
- - Infra-As-Code: How do we start?
- - Infra-As-Code: What is required?
- - Infra-As-Code: Examples
- - Infra-As-Code: Next steps
- - Infra-As-Code: Overview
So what does Infra-As-Code really mean? Let’s go ahead and address this here in this post and get a good foundation of what it really does mean.
If you begin to treat your infrastructure as code, you can begin to develop the processes in which allow you to deliver a fully tested, repeatable, consistent and deliverable methodology for configuration state in your environment. In doing this you can begin looking at these items as a pipeline of continuous delivery. Furthermore, allowing for automation tooling to consistently bring your infrastructure to the desired state which has been defined. As you begin this journey you will start with a baseline and then a desired state. Adopting chosen automation tooling for your environment, version control, code review and peer reviews will allow for a much more stable and speedy deployment. As well as, allowing for easier roll-backs in the off chance that something does not go as planned. But the chance of having to roll-back should be minimal assuming that proper testing of configurations has been followed throughout your pipeline delivery.
I know this all sounds great (on paper) and feels a little unrealistic in many aspects but in the next post we will begin to discover on how we can get started. And hopefully by the end of this series you will have a much better understanding and realistic view on how you too can begin the Infra-As-Code journey!