Showing results for 
Search instead for 
Did you mean: 
Create Post

Infra-As-Code: What does it mean?

Level 10

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.

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!


This is something that should already be in place for most shops.

It leads to consistency.

Changes can be made in one place.

I would highly recommend the peer review as mentioned.

It provides a different perspective as well as gets a second pair of eyes on the code.

On the note of coding,  set up and establish coding standards that the team will use.

This helps with consistency, documentation.  Keep the code simple, it may be longer, but

built in comments are a huge benefit and help to make it 3AM friendly.

I have been through many "shops" over the last few years moving around the planet.  Some shops have begun this and some cannot spell it.  But over the years, I have developed my own way of doing things and how I like to have things done.  I take bits and pieces from each organization and meld them into my process and procedures.

Some tasks/process/procedure that are most common would be:

-Labeling of Cables - believe it or not most do not do it, and using a sharpie on an ethernet cable does not count.

-Standardization of a device configuration.  I like the STIGs it takes care of this issue but still needs implementation

-Diagrams/Documentation - If the network is down then how do I locate issues.  What goes where and Why?

-Daily automated scripts - Thanks to SolarWinds Lab and thwack Community‌ for the development.

I look forward to the rest of this discussion and comments from others.

Level 8

good article....

Level 14

Looking forward to the follow on articles.  Sounds like we may already be doing some of this.

Cisco's ACI is all about scripting, and my organization's adopting and implementing ACI. 

Pre-ACI, I was using NCM back in 2004 to standardize scripting for my team, and to make things consistent--and handy!

One problem we run into is ignorance of the big picture or the C-level folks' big plan.  While it may not necessarily be secret, it also might not be communicated to the lower levels that are responsible for implementing the technical details.  If someone would tell me what the organization's Network needs will be at any given time in the future(e.g.:  in three years), I could easily have that in the budget requests and I'd have it implemented on schedule.

Instead, too many times will departments buy an incompatible technology without input from IS, spend big $$ and have the vendor's installer on-site before they call for our help--and then it's an emergency, drop everything and make it work!

If all departments followed a business "script" that coordinated resources and timing and budget, it would work so much better!  Maybe even as well as scripted NCM tasks . . .


Level 17

Very nice. Having a set of standards to drive policy and dictate procedure are key to congruity across your network. If you are using contractors to do some of the manual labor having those metrics in your SLA makes all the difference in the level of work and consistency.

Looking forward to the journey on this series.  Based on the loose description, I feel like we are headed down this road, but look forward to the topic being exogeted.


I read the third article and got here via #2. - I'm glad I did though, because wasn't convinced with this on its own, but each subsequent article got me more and more onboard

Level 10

Great to hear that you are using ACI. I myself am in the middle of this same journey with Cisco ACI so this series is of the utmost importance in my real-world as well.

Level 10

Glad you found it. I plan on back referencing each post and then once complete I will reference each post forward from the first post as well. As you can see each subsequent post builds based on the previous post.

Level 21

We are one of the shops that probably could not have spelled this a year ago and will be implementing it this year.  We are going to be building out an automation platform for deploying and delivering services in an Azure Stack environment.  Based on my experiences thus far I would say much of this is still very bleeding edge so if you are going to down this route you should probably be prepared to bleed a bit but you will have a fun time doing it!

Level 20

is this a devops thing?