Pseudocode

I’m not going to write any actual code for IaC in this chapter (you can find that in the chapter dedicated to IaC), I’m just going to give a quick overview of the concept behind IaC using some pseudocode definitions. These will help you understand how singular IaC definitions work in securing resources.

An example pseudocode – to create a virtual machine – broken down into the simplest pieces would be something like the following:

• Module Name (Usually descriptive of the service being deployed)
  • VM Name (say VM1)
  • Resources allocated (Specifications, or class of VM) (say 1 GB RAM)
  • Internal networking and IP addresses (in VPC1)
  • Tags (say “Department”: “Accounting”)

This example will create a VM named VM1, with 1 GB of RAM in a VPC or equivalent network named VPC1 with a tag of key Department with an Accounting value. Once launched, that is exactly what will happen. Oops, I needed 2 GB of RAM. What do I do now?

That’s easy, just change your code:

• Module Name (Usually descriptive of the service being deployed)
  • VM Name (say VM1)
  • Resources allocated (Specifications, or class of VM) (now its 2GB RAM)
  • Internal networking and IP addresses (in VPC1)
  • Tags (say “Department”: “Accounting”)

And that’s how easy that is. You can see why it’s popular. It is stable enough to be reliable, but flexible enough to be reusable. Now, here are a couple of other pointers that will help you understand how most IaC templates work:

• If you had renamed the VM, it would have been redeployed with the new name
• If you had renamed the module, most templates would by default tear down and decommission the old VM in the old module and create a new one from scratch
• Changing the network or VPC would logically move the VM to the other network whose network rules it would now follow
• Most templates would allow you to loop or iterate over multiple VMs

IaC, man what a concept. It’s a very interesting – and very popular – solution to a common problem. It can solve a lot of DevOps headaches and should be in the arsenal of every DevOps engineer.

Summary

The concept of DevOps is exciting, vast, and has room to get creative. It is a discipline where the world is essentially at your command. Effective DevOps requires effective structure and adaptation of that structure to a challenge as we learned in our Exploring automation section.

But remember, anything that can go wrong will go wrong, so plan for success but prepare for the fact that failure is a common occurrence. In such cases of failure – as we learned in the sections about monitoring and event response – the ability to recover is what matters, and the speed of that recovery also matters quite often. If an incident to be recovered from is new, it must be reported and understood so that such incidents can be mitigated in the future.

And lastly, as we covered in Delving into infrastructure as a code, code is your friend. Be nice to your friends and play with them. You’ll learn how to in this book.