This message was deleted.

What do you dislike?

Cloud providers actually make declarative configuration too verbose. More verbose than imperative, (script based or custom tool via api) configuration.

Are you using terraform or the native cloud providers IAC offering (ex, cloudformation from AWS)?

Azure Bicep

Oh sure. However, I think a huge benefit of declarative is you can typically see what drift has happened and reconcile back to your declared state. At least with terraform I have been able to do this.

Yes bicep does this but in reality what happens is your spend time maintaining and developing your modules in addition to the IaC required to deploy the resource.

I’d suggest a similar base of comparison or criteria. E.g: state management — using the azure CLI isn’t clear a good fit if what’s what you’re looking for. With Terraform, you’ve got that solved without even thinking about it. Is TF better than azureCLI for any other approach? I don’t think so, it depends on your comparison base, criteria you’ve choose, etc.

it certainly is a huge amount of work.

That’s also relative and quite subjective. It depends on how your code is structured (whether you’re applying certain principles, like DRY, your modules are properly structured and has a certain level of agnosticism —meaning, they’re decoupled from an specific domain/use-case so they can increase their “reusability”—, etc.), the “size” (or complexity) of the problems that you’re trying to solve, etc. It’s always a trade-off decision. I’ve been involved in IAC from the very early days. I’m able to maintain modules, and stack-composite/blue-print architectures quite rapidly, but that doesn’t make me think that IAC is the silver bullet for all the infra/platform related challenges out there. I’d give the same answer for k8 😉 Just a thought.

IaC tools like Terraform need a state file as they cant speak directly to the ARM api layer. Bicep doesn't need a state file as it does talk directly to the ARM api layer so state management in itself isn't a real factor in the discussion about IaC complexity that Jacob is referring to. As a long time user of Terraform and recently some pulumi and bicep (after being an 'ARM-victim' myself), i think its more sensible to use the right tool for the right job. For some time now I'm more inclined to do my infrastructure by "stealing" the tfvars concept from terraform with simple AZ CLI commands all in powershell files and then adding Pester tests for integration tests. If you create a folder structure that mimics a terraform/bicep project and keep all the variables values in tfvars/json and read the files as you run you PowerShell wrapper, reading values and injecting them in the right place, so in a sense create a small abstraction layer on top of the IaC tool, and then you can always replace things, underneath when the team is ready to use what ever IaC is more relevant, but you don't have to change how you describe the config values. Yes you do have to understand Azure the order of execution, which normally TF abstracts from you via the use of the provider but i would actually say its better to understand the underlying azure architecture of services that to not know it. After training multiple people in a few companies about terraform. People that go from pure devs to pure ops, and in different responsibilities between them, i always go back to simplicity and standards over tool x or y, but I do understand the effect on people cv's and abilities to compete for their next gig.

@Jacob Hodges For Azure, you could also use Pulumi or CDKTF (Cloud Development Kit for Terraform), which uses regular programming languages to generate the declarative model under the hood. For CDKTF, it will translate to Terraform as an intermediate step. For Pulumi, it goes directly to their declarative model, no intermediate language. In AWS land there is also AWS CDK, which generates CloudFormation as an intermediate language. A good thing with AWS CDK is that AWS has built a lot of higher-level components on top of the lower-level interfaces defined by CloudFormation. A bad thing is that it is still CloudFormation under the hood, so things like refactoring will suck. Despite that, it is still hugely more productive than using plain CloudFormation. That is a non-option for Azure though. More than just the verbosity and abstraction level, thinking about your ability to refactor, test och infrastructure codebase is important to consider also, applying software engineering principles to what is done - more infrastructure as software, than infrastructure as "code" only.

I dont think the issue is a programming language vs not a programming language bur rather the complexity of all the tools vs for example the same service creation in say AZ CLI with the parameters. The missing part os how you read the variables (in this case simple PowerShell reading a file.tfvars or file.tfvars.json and injecting the values into either the AZ CLI or create a PowerShell function that takes the values and warps the AZ CLI command. Refactoring and testing are as easy to do with PS as in TF for example. In all ways you still have to adopt additional tools to complement.

Definitely some good discussion and for context I've been doing IaC from the early days as well. More with ARM on Azure than with Terraform. In my current project I've got some very generic Bicep modules that represents the 'reusable', 'decoupled' templates and a number of deployments that compose these module into actual infrastructure. I try to follow the recommended practices for DRY and modularity as much as the next person. I'm not saying IaC is terrible but some days my enthusiasm does diminish. Consider this little example. I am building out a new environment in Azure. I know my environment will need k8s and due to organizational requirements everything needs to be private (Private Endpoints). I also know there are some requirements for a few VMs, some Storage Accounts, and Serverless. I start with a simple Hub/Spoke deployment in IaC with Azure Firewall some vnets, app gateway, etc, as per best practice. I put that IaC in a git repo and have a pipeline run that deployment. Any changes to my vnets, firewall, nsgs, gateways can be made in Git, reviewed and deployed automatically via a pipeline. Fast forward to when we have added k8s, some VMs, Azure Functions. All of a sudden I'm faced with a lot of complexity. The deployment of my app shouldn't trigger my IaC pipeline for Hub/Spoke but what if I need a firewall change? To that point adding a firewall rule means I'm running the IaC deployment for my entire Hub/Spoke which takes ages to run for a single rule change.

Yes, you want to keep the complexity and cognitive load at a manageable level, throughout the lifecycle of the infrastructure. A programming language is just a way to add more power of expression. You still would want a declarative model to reduce complexity and cognitive load in maintaining the infrastructure, and you also want the tools to fit well into the workflow without too much cognitive load.

I've been thinking about this stuff lately. Two of the issues with most current IaC (and there are more!) are a) they deal with low-level resources, and don't have good ways to package and present higher level abstractions for use, and b) it requires loads of scaffolding to handle things like configuration parameters and integration (e.g. if you break up your codebase into multiple projects). Most people end up with piles of custom scripting for the scaffolding, and it's usually a spaghetti mess.

• Kubernetes: Describe the desired state in yaml file, and the control plane automatically deploys and operates the resources. • Terraform: Describe the state of the desired infrastructure resource in HCL files, and the terraform automatically creates, modifies, deletes, and manages the resource. I love the concept of Terraform and IaC tools, and managing GitHub, Sentry, and Nexus Repository resources with Terraform has been much more convenient and secure than scripting.

At some point, doing Infrastructure As Code will mean you are doing Coding, so normal software development practices will arise. You will need the safeties of testing, config, versioned libraries, ecosystem tooling, documentation, orchestration, etc.. It's at that point that the utility between declarative and imperative methods starts to not matter, because you still need to build that same capabilities around it.