Organizations have changed the way their systems operate, over the last decade, with the rise of the cloud. Infrastructure code is an incredibly powerful process that has come out of this change.
Infrastructure code eliminates manual steps and houses configuration information in standardized files. It simplifies configuration and management.
To learn more about infrastructure code, we spoke with Patrick Pierson, Director of Cloud Infrastructure at cybersecurity startup, IronNet.
He discusses the capabilities of infrastructure code, proposes best practices when writing it, and explains its relation to multi-cloud.
The conversation below has been edited for length and content.
What is infrastructure code?
To begin with, there’s obviously cloud formation. Each cloud provider has its own kind of language that it uses, from Amazon to Azure to Google. Terraform allows you to do a multi-cloud approach, but you still have to write specific code for each provider.
There are more traditional languages like Ansible, Puppet, or Chef, that you can consider infrastructure code because you can create and configure AWS resources with them. You can even put together simple Python code using SDK’s like the Boto3 SDK. You can do it in any language to create infrastructure via actual Python code.
There are a million ways to do it.
One of my favorite stories on this topic goes back eight or nine years to when I started learning about cloud formation on Amazon Web Services – which is Amazon’s templating language to create cloud resources. One day, I was talking to a good friend of mine and I showed him a template I had written. It was a confirmation template that spun up a simple web server.
I explained that this template created the server, installed the code for the server, and then got the server running. Once I was able to explain it to him, his eyes lit up. It blew his mind. It was neat to explain the power of infrastructure code and see the impact it had.
Do you have any best practices for writing infrastructure code?
Iterate and start small. One of the things that’s hard with infrastructure code is that aiming to do too much can lead to misconfiguration.
For example, if you start creating an RDS database on AWS (which takes around fifteen minutes) and then go get a coffee in the meantime, you might come back to a misconfiguration halfway through. This then rolls back your timeline.
The quickest way to combat that is to start with something fairly small and iterate over it to get your final deployment. However, I see a lot of people take a template that gives them an “all-in-one” network configuration, VPC, and then RDS database. If you run all of those at the same time, it’s very possible that you will actually lose more time making corrections. If you iterate over it, credit the VPC first, get it working, and then add the RDS instance. You have a greater chance of success at deployment.
How is multi-cloud related to this idea of infrastructure?
I’m a huge Amazon fan, so I would jokingly say there is no such thing as multi-cloud and only Amazon exists. But truthfully, as much as I love Amazon web services, Azure has started to develop a lot of different tools that people are using. There’s also the Nutanix and VMware worlds that are traditional on-prem solutions with growing cloud mindsets. The OpenStack world provides a lot of the same API’s that a cloud-centric person would expect to have.
That said, there are many flexible options available. Managed services are very useful for those working in the cloud world. You don’t need to be a database expert to run a database. You can set up a lot of your tasks automatically and services can even monitor them for you for optimization. Ultimately, you don’t need to be well-versed in every single cloud. It can actually be better to be an expert in one particular thing. I might consider myself an Amazon Web Services person, but, if the company needs to talk about Azure, I can talk about Azure and look up similarities between the different clouds. It’s just somebody else’s server, and that’s what it really all comes down to.
If you write and deploy code as often as you can, you can build anything.
