With the rise of DevOps and the ongoing maturity of Infrastructure as Code toolsets over the last few years its apparent that the whole IaC journey is expanding across all areas of technology, and isn’t just confined to Software Development roles.

In this brief module I hope to disclose some of my findings on what to look for when selecting the right tooling for your needs, using 9 factors I hope to compare the most common IaC toolsets and what parameters set them apart from their competitors.

Factor # 1- Open Source vs Closed Source

The choice between Open vs Closed source, may seem like an obvious point straight up, and it could be to easy to just look at this in terms of cost being ‘Free vs Not Free’ to buy. Which may very well be the case to a point.

Generally speaking Open source software will certainly remove the barrier to adoption or use purely down to the point that is is free to share source code and use as you please (or in line with the Open Source licence). However, typically you can buy services around Open source for things like technical support and assistance.

Most proprietary licensing that includes a ‘paid for’ license with its code being closed source is typically maintained by a software company who sells these licences and support or maintenance services.

Factor # 2 – Cloud Agnostic vs Cloud Native

Do you need to use the same tooling for multi-cloud configurations or deployments? Or are you happy to use a toolset that has been developed and maintained just for one Cloud platform only?

Again, as with all of these factors there is no right or wrong answer here. Its just a point to consider when choosing the right tooling. Would using the same toolset for AWS, Azure, Google be advantageous in terms of training and/or consistency? Or do you only ever use a single platform and don’t need a toolset to cover multi-cloud?

Factor # 3 – Provisioning vs Configuration

Again, generally speaking there are two common threads with IaC tooling. Those that Provision Infrastructure, i.e. provision a load balancer, a network, some storage and a Virtual Machine. Then there are the toolsets that act as Configuration management platforms, i.e. to configure the Virtual Machine that has been provisioned with Applications and/or run scripts to set an environment for the servers to be utilised.

Yes, there will be overlap, some Provisioning tools can do a bit of Configuration Management, and some Configuration Management Tools can do Provisioning tasks, however later we will look to see where the main strengths are generally agreed on across the community. Again, there will most definitely be exceptions to this choice, and there will be scenarios where a tooling will be used in a different manner.

Factor # 4 – Mutable vs Immutable Infrastructure

The definition between whether infrastructure is Mutable or Immutable typically outlines whether the infrastructure will be deployed ‘New’ every time from code (Immutable), or once deployed the infrastructure will change (i.e. software updated, OS updates etc.)

If infrastructure that needs to be modified is subject to regular change, having an immutable approach may be difficult to manage every time there is a minor update that needs to be deployed. Alternatively if you require the ability to spin up and environment in a consistent and known manner, then an immutable approach may be the way for you! At this point, concepts such as containers may also offer some options to consider.

Factor # 5 – Procedural vs Declarative Language

A procedural language defines in a step by step manner ‘how’ and ‘what’ need sot be configured. This can be a script like process where the process will start and the beginning and run each command as a series of tasks. The engineer has to tell the code in what order to make the infrastructure and make sure they have taken into account any dependencies etc. i.e you can’t configure a public IP on a VM until after you have created the VM!

On the flip side, Declarative language is merely the act of defining the code that describes ‘what’ needs to be configured, but not the order in which it needs to be configured or even How it will be configured.

Another point to consider, is what do you want your code to be able to do? What I mean by this is, if you run a procedural code once, typically that’s it, you can’t reuse the code to add another piece of infrastructure, or you can’t run the code and get the same output in the same manner again. Whereas, with a declarative language, typically these languages retain a ‘state’ which means that as part of the act of running them, they are aware of the current state and are aware of what their impact of running may be. This concept is known as ‘Idempotency’.

Factor # 6 – Agent vs Agentless

In order for your infrastructure or configuration to be applied, does it require a piece of software (an agent) installed on it to communicate either by ‘pulling’ down the code to set the configuration, or having the code ‘pushed’ to it by an outside source. These agents will them selves require installing and managing for things like updates and conflicts with other software etc.

On the other hand, an agentless deployment can typically utilise common connectivity protocol such as ‘ssh’ or ‘wmi’ to configure services on a server for example. They don’t need an ‘agent’ as such, but they do need an open port to a management interface protocol such as those mentioned that in themselves need a different form of management. i.e. leaving ssh open can be a security risk, so having an answer to mitigate that risk is then imperative.

Factor # 7 – Master vs Masterless

Closely related to the Agent/No Agent point, does your implementation benefit from an IaC toolset that acts from a master server and communicates with the scope of your requirements from this one place (i.e. master). Which would require set up and maintenance of additional infrastructure to run the deployment from.

Or does your IaC toolset offer the abilities to run the code from anywhere? I.e. masterless. Is the convenience of being able to run your config’s from your local machine a compelling factor for you? Or would you prefer a central point that can deploy the configuration?

Factor # 8 – Community Size

Regardless of the tooling you choose, you will undoubtedly require support at some point, whether that is in the early days by reaching out to community members of your chosen tooling, or paying for Platinum level support agreements later down the road! Typically the benefit of these IaC toolsets is that a lot of them are open source and lend themselves to that developer lifestyle of community and sharing of knowledge and information.

So…… when choosing your toolset, would you rather a well known and uses toolset with a large community of users able to help you with your next question. Or do you prefer the more cutting edge toolset that offers that feature you need today with a trade off of the community engagement may be a lot smaller for you?

Factor # 9 – Maturity Level

The final factor to consider is the overall maturity level of the platform. This may very well correlate with the community size, but not in all scenarios. For example, a platform may be very well documented and have gone through a number of releases over a number of years but be quite niche in its approach, and therefore have a small community size. What you are looking for here is what version? how long has it been established? etc.

Some newer platforms haven’t yet even reached release v1.0 yet and are still technically in beta release, but they have a groundswell of community. Does this bother you? Or are you comfortable with that?

Conclusion

Thank you for reading down my 9 factors to deciding on Infrastructure as Code tooling! I hope you will see that there simply aren’t any right or wrong choices here. Its just about being aware of some of the things to maybe look out for when making your choice as to which toolset to choose.

In all reality, the general trend seems to be that you probably wouldn’t just choose a single toolset, you may in fact choose 2 or even three different platforms that offer subtly different solutions to your environment. Some of those platforms may even overlap in capabilities, when this happens its probably beneficial to work out what you want to use each platform for, and communicate this out to your staff to ensure you are all using the platforms in the same manner.

Up to this point I have been careful not to mention any technologies specifically, however I have taken the following table from research done by ‘Yevgeniy Birkman’, Author of ‘Terraform Up & Running – Writing Infrastructure as code (2nd Edition)’ where his findings were as follows. Please note this book was printed n October 2019, so will be slightly out of date, but I felt this highlighted the more common platforms that we are all choosing between at the moment. I’m sure there will be some that disagree with some of the choices, but like I say, hopefully this help’s someone else to make a bit more of an informed decision, and to try and understand the things to look out for in a platform for Infrastructure Provisioning and configuration.

One other thing to not is that I haven’t included any Container or Image packing technologies in here, this is purely looking at Infrastructure deployment and config.

	Source	Cloud	Type	Infra	Language	Agent	Master	Community	Maturity
Chef	Open	All	Config Management	Mutable	Procedural	Yes	Yes	Large	High
Puppet	Open	All	Config Management	Mutable	Declarative	Yes	Yes	Large	High
Ansible	Open	All	Config Management	Mutable	Procedural	No	No	Huge	Medium
SaltStack	Open	All	Config Management	Mutable	Declarative	Yes	Yes	Large	Medium
Cloudformation	Closed	AWS	Provisioning	Immutable	Declarative	No	No	Small	Medium
Heat	Open	All	Provisioning	Immutable	Declarative	No	No	Small	Low
Terraform	Open	All	Provisioning	Immutable	Declarative	No	No	Huge	Low

100DaysOfCloud Overview

My Main ReadMe Page is all set up with a bit about me!

The guys at 100DaysofCloud have set up the GitHub repo to be cloned and also have a great repo containing ideas and areas to collaborate on: https://github.com/100DaysOfCloud/100DaysOfCloudIdeas

My Github Journey tracker can be found here: https://github.com/jonnychipz/100DaysOfCloud

Please Watch/Star my repo and feel free to comment of contribute to anything I push! I really look forward to hearing from anyone who is going to jump on the journey around the same time as me! Lets see where I get to in 100 days!

I would encourage others to jump on this journey, I’m not sure that I will be able to commit every day for 100 days, but as long as I can complete 100 days that will be great!