Who remembers the quote from Mark Cuban back in 2017: “Automation is going to cause unemployment, and we need to prepare for it!”? How about “I think as automation gets even more and more prevalent, we’re going to need to learn how to code. Everybody does.” This was said by Reshma Saujari, CEO of Girls Who Code.

You don’t have to raise your hand, as we’re not keeping score. In all fairness, the quote from Cuban was regarding robots taking over jobs, and I think Ms. Saujari started that company because she did not want to code to automate, so she hired folks who can.

This blog is meant to provide guidance and direction for the best choice for your organization. The assumption is that there is some basic knowledge as to what Infrastructure as Code (IAC)  is, and some of the existing tool set around it. The whole purpose of automation is to perform tasks in a configurable and repeatable pattern to reduce inefficiencies and eliminate errors. As a society, we have automated more in just a few years than in the past 30-40 years combined.

Employment numbers though do not seem to indicate automation is taking over our jobs for the foreseeable future. As WinWire is a Gold Microsoft Partner, we will focus on the two popular infrastructure and application automation tools in the Public Cloud; Azure Resource Manager (ARM) and Terraform.

What is Infrastructure as Code (IAC)?

IAC was developed over time to minimize what’s known as “configuration drift” where implemented infrastructure evolves into something unique over time and makes it difficult for IT staff to manage. With each inconsistency, mature deployments are at risk of exhibiting different behaviors, especially when scaled across 10s and 100s of servers, making it nearly impossible to troubleshoot, maintain consistency, and give a good end-user experience.

Of course, there are other ways of deploying infrastructure and code to Azure.  One can always use the portal.azure.com to manually implement each environment, which at scale is difficult to manage, and error-prone.  There are also third-party implementation tools such as Embotics that act as a front-end to the Azure API set and can create automation.  Downside is that these applications are not Cloud-native and require continuous upgrading as Cloud Service Providers are adding new services daily which could lead to a stale infrastructure.

How to Choose the Right Deployment Solution?

When it comes to evaluating infrastructure deployment models, one must think strategically about their enterprise. At any given point, one or more of these items must be taken into consideration:

1. Number of applications
2. Variations among versions
3. Short-term vs. long-term testing needs
4. Performance-related implementations
5. Compliance-specific deployments

Furthermore, security assessment by itself is often a beast and may require:

1. Environments for denoting malware
2. Testing application boundaries (Black Hat-type testing)
3. Load-testing to understand DDoS withstanding capability

Producing environments for each of the above use cases could be an expensive and daunting task if not managed properly. Automation affords us the ability to bring up and tear down environments in a consistent manner.

Azure’s native offering for automation is made through ARM templates. These are JSON files that are declarative and can be very flexible in slicing and dicing infrastructure. Developers can call them as inputs to make provisioning calls into Azure to automate the deployment of an application. They can also be formed into templates and used multiple times. Another advantage of these templates is their maturity and flexibility. We can reap the benefits of other people’s work as there are   Microsoft ready-to-consume templates, and the general Azure and DevOps communities also contribute to the repository.

Example Source: Microsoft

This is useful if you have a team consisting of Azure DevOps engineers who can dedicate time to maintaining and creating new ones. However, for the not-so well-adapted-to-JSON IT staff, this format is intimidating and often yields results that are not scalable.

Benefits of Azure Resource Manager

• Enables you to manage your infrastructure through declarative templates rather than scripts
• You can deploy, manage, and monitor all the resources for your solution as a group, rather than handling resources on individual basis
• Can help you define the dependencies between resources, so they are deployed in the correct order

What is Terraform?

Another tool that is natively available on Azure is   Terraform (TF).  It is the brainchild of a couple of Silicon Valley developers and has been in the market since 2014. Licensing models vary from Open Source to Enterprise, and there are 100s of communities that you can turn to for support, not to mention the 1000s of articles and how-to guides. Better yet, TF is officially supported on Azure (and other Public Cloud providers).

TF can be used to build, change, and version without the need to worry about errors, leftovers, or costly mistakes. Infrastructure can be torn down just as quickly it was brought up, so if there is a mistake, tear it down, fix the format, and rebuild with a couple of keystrokes.

TF uses   Hashicorp Configuration Language (HCL)   in its config files to build/configure infrastructure. Each section of the configuration file is human-readable and describes the desired resources to be implemented, whether it is one application or a complex load-balanced environment with 100s of servers and security components. More importantly, incremental changes are tracked and can be applied to other situations at scale.

Example Source: Hashicorp

I don’t own any stock in Hashicorp, but use TF in our daily Azure routine, and have many case studies where TF has helped our customers reduce spending, get a better implementation strategy, and increase security.  TF truly embodies the IAC concept, is multi-Cloud, and gives a preview of resources to be deployed as dry run to ensure maximum accuracy.

TF can be accessed through multiple ways:

1. Within the browser – Without the need to install anything, and it’s always updated to the latest version as soon as the Cloud Provider is having pushed the updates:

2. Within Visual Studio Code – Requires installation of Microsoft VS Code, but gives great flexibility as code can be installed locally, in Github, or some other code repos such as Azure DevOps. Disadvantages are that local installs of TF will need to be manually maintained and upgraded, as necessary.

3. Within the PowerShell environment – Can use the existing Windows PowerShell environment, but the disadvantages are that local installs of TF will need to be manually maintained and upgraded as necessary, and this is the most isolated method, meaning that changes will have to be manually synced up with the various code repositories.

Benefits of Terraform

• Multi-Provider: TF supports multi-cloud orchestration such as AWS, Azure, OpenStack, etc. and on-premises deployments.
• Dry Runs: TF supports something called Plan. You can look at the Terraform file and determine the changes you are going to make in the infrastructure before making it.
• Super Portability: TF enables one tool and one language for describing the support for multiple cloud providers. Migrating to vendors is not a problem anymore.

Even though ARM and TF fulfil the same vision, their approach is different. While I simplify the vision, imagine trying to go to Microsoft HQ from Portland in your car.  You know traffic is going to be horrendous and there are multiple ways to get to Seattle. One of the ways to go is to use a map or passive GPS, plan your stops, and hopefully, your passenger knows when the traffic is busiest at which time of day.

Another way is to use an active GPS in your car with 2-way communication, or smartphone with Google/Apple Maps with traffic rerouting where it shows you the path of least resistance. I am sure most of us have experienced at least one of the two ways, but any guesses as to which one’s ARM and TF?

They both accomplish getting us to Microsoft HQ, but one is more efficient and easier to use than the other. There are strengths and weaknesses to both ARM and TF. We have not gone very deep in identifying the pros and cons of each one, but this is only the 1st of a few upcoming blogs on this subject folks; have some patience.

Conclusion

Both Terraform and ARM are good when it comes to infrastructure coding for Azure. TF has some exciting concepts; I can see some definite advantages over ARM templates in certain areas, and I enjoyed working with it. If you need to undertake a multi-cloud deployment or deploy on-prem, you will use it. Hopefully, this blog has helped provide a good synopsis of what Terraform and ARM templates bring to the table.