The Shift from ‘ClickOps’ to Infrastructure as Code: Why It’s Time to Re-assess Your Deployment Method

The way we deploy infrastructure has changed. Over the last few years, there has been a big shift in the mentality and how Infrastructure is deployed in Projects and managed in BAU operations. Traditionally, when deploying services in a Public or Private Cloud service like Azure, AWS, GCP, Hyper-V or VMware you would use the Portal experience now known as ClickOps to stand up your Virtual Machine or Network or use Python Scripting to deploy services in VMware Hypervisors.

Why this matters to Executives within an organisation is that though these deployment mechanisms do serve the purpose of provisioning what is expected, it does introduce potential trip hazards or operational risks:

• Business Standards and Uniform Configuration Drift (Governance) can be misinterpreted by the Engineer deploying the service and if Guardrails are not in place, the configuration may not align to the requirements set by the business.
• Runaway Costs can be incurred due to misconfiguration of SKU’s or provisioning of wrong resources.
• Downtime can be introduced due to having to reprovisioning misconfigured resources.
• Security Risks are often flagged when a service is deployed and the wrong Firewall settings, encryption levels or connectivity configs are chosen and the resource is then exposed to threats.
• Auditing is more manual, having to deep dive through activity logs and sys logs to find out when a service was brought online, who did the deployment, correlating the change request.
• Repeatability – Companies who are scaling services on a fast pace will move at a slower pace if scripting or automation is not in use as well as going management proving troublesome.

To address these concerns, Infrastructure as Code (IaC) using DevOps Frameworks (CI/CD) is being adopted by companies of all sizes (small to enterprise businesses) simply not as a bolt on but as their only method of deploying and managing Infrastructure.

Infrastructure as Code Tooling

In short, Infrastructure as Code means defining Cloud Infrastructure via version control in a file repository rather than building it manually through Web Portals.

IaC Tooling in the Microsoft Cloud space consists of 3 main products:

• Bicep – Microsoft owned language – the evolution of ARM and Powershell.
• ARM Templates – Legacy deployment model developed by Microsoft.
• Terraform – Bought by IBM but founded by HashiCorp – supports multiple Providers from Public Cloud, Applications and Private Cloud environments.

Selecting the suitable tool out of the above depends on your requirements but Terraform appears to be increasingly adopted in most sectors but it is also common to use multiple IaC tools for different Platforms or resources.

The use of IaC has seen Engineers adopt a Software Delivery Development / Lifecycle mindset and CI/CD Delivery tooling and frameworks as opposed to traditional Infrastructure, nuts and bolts.

The learning curve for this is steep but Engineers can upskill by completing the variety of Courses, learning materials and Certification Paths that are out there but it is advised that you simply just start small.

The Pros of Infrastructure as Code

When IaC has been adopted both technically and operationally, organisations can gain the following benefits:

• Consistent / Uniformed Deployments – Resources are deployed to defined and approved standard that aligns to Governance, Security and management requirements.
• Predictability – Managers and Engineers know exactly what they are deploying, when it will be deployed and can plan the change accurately with more assertion.
• Recovery – The code repository is essentially your Infrastructure in File Format, this code can be redeployed into another Region at a quicker rate than using Manual deployments.
• Repeatability – For organizations that Scale or have separated environments, using IaC can make deployments repeatable at a quicker scale and pace.

The Cons of Infrastructure as Code

Although IaC does come with a variety of positives and wins for organisations, it does introduce a number of problems if not adopted fully within your Technical Teams and delivery models.

• False Sense of Security – IaC does not guarantee security, hard coded secrets (passwords, keys), weak access controls or poorly written modules can introduce vulnerabilities.
• Operational Risk and Drift – When teams deploy infrastructure using IaC but continue to make ad-hoc portal changes, the code no longer reflects reality. This leads to failed deployments, unexpected behaviour, and environments that cannot be reliably recreated.
• Lack of Skilling or Code Competence: If principles such as KISS (Keep It Simple) and DRY (Don’t Repeat Yourself) are not followed, IaC codebases can become bloated and difficult to manage. Minor changes may require updates in multiple places, increasing the chance of error.
• Mantel Piece Code: In the worst cases, IaC is written once and then abandoned. Environments continue to change manually, leaving the code outdated and unusable, therefore wasting the initial investment and creating confusion.

The following principles of IaC must be embedded into Code structure and repository:

K.I.S.S – Keep It Simple Stupid: Keep the code as simple as possible without convoluted structures and mechanisms. Overcomplication leads to single point of failure, poor scalability and weak adoption among engineers.

D.R.Y – Do Not Repeat Yourself: This principle avoids hard coding resources into your code that would be better stored in a variable that can be called throughout your code base rather than statically entered across multiple lines of code, change becomes easier to manage with D.R.Y is embedded.

Summary

To adopt IaC, unless you’ve brought in experienced expertise (DevOps Engineers) then start small, deploy simple and low impact services via a Pipeline, ensure the code is repeatable, simple and easy to adopt.

If an organisation cannot hire these skills but wish to adopt, then it is key to learn the CI/CD Lifecycle and Frameworks, so you understand how IaC environments operate and are managed.

Transparity among others in the Microsoft Partner Eco-System have IaC-as-a-Service offerings who can help with code changes and releases.