Live data from Hacker News

“Who Should Write the Terraform?”

zwischenzugs.com

11–20 of 137 posts

Re: “Who Should Write the Terraform?”

#11

Devs writing Terraform means ops doesn't move fast enough. Fix ops instead of forcing the teams to roll their own.

But, as the article points out, centralized ops teams many times do not have the capacity to handle all the requests coming from the dev teams.

Re: “Who Should Write the Terraform?”

#12
post #7

What a long winded article to say "it depends", I liked the history though. It got me thinking, here at amazon, we deliver "infrastructure as code" using the Cloud Development Kit: https://aws.amazon.com/cdk/ We expect engineers (not devops) to define their infrastructure in typescript and configure it through code. That code gets turned into cloudformation scripts and stands up the how cloud system for the api you'r…

The layers of AWSCDK leads to a lot of brittleness, and that was a huge turn-off for us. I like the thought of building systems in a functional way but the tooling just isn't there yet. I haven't dived too deep into Terraform CDK yet, and Pulumi just had too many problems.

Re: “Who Should Write the Terraform?”

#13
post #7

What a long winded article to say "it depends", I liked the history though. It got me thinking, here at amazon, we deliver "infrastructure as code" using the Cloud Development Kit: https://aws.amazon.com/cdk/ We expect engineers (not devops) to define their infrastructure in typescript and configure it through code. That code gets turned into cloudformation scripts and stands up the how cloud system for the api you'r…

The layers of AWSCDK leads to a lot of brittleness, and that was a huge turn-off for us. I like the thought of building systems in a functional way but the tooling just isn't there yet. I haven't dived too deep into Terraform CDK yet, and Pulumi just had too many problems.

What were your issues with Pulumi?

Re: “Who Should Write the Terraform?”

#14

Devs writing Terraform means ops doesn't move fast enough. Fix ops instead of forcing the teams to roll their own.

But, as the article points out, centralized ops teams many times do not have the capacity to handle all the requests coming from the dev teams.

So fix that by hiring more ops folks...? Ops should scale with the dev teams, if they aren't you're burning them out and will have even more problems.

Re: “Who Should Write the Terraform?”

#15
Re this segment:

> "There were endless complaints about the time taken to get ‘central IT’ to do their bidding, and frequent demands for more autonomy and freedom. A cloud project was initiated by the centralised DBA team to enable that autonomy. [...] Cue howls of despair from the development teams that they need a centralised DBA service"

Author makes it sound like users didn't know what they wanted. This is not true -- I have seen this play in practice, and what author omits is _it was a different set of people_ who were complaining before and after.

If a dev team has at least 2 engineers who are happy working with infrastructure, then the team will benefit from autonomy. If there is no one like that on the dev team, they will cry in despair.

Re: “Who Should Write the Terraform?”

#16

Devs writing Terraform means ops doesn't move fast enough. Fix ops instead of forcing the teams to roll their own.

No matter how capable and well-staffed ops is, it will always take them much longer to provision my stuff than if i did it myself. I like having more eyes on stuff before it hits prod, but waiting days to get things setup in dev is not just unproductive, but demoralizing.

Re: “Who Should Write the Terraform?”

#17

Devs writing Terraform means ops doesn't move fast enough. Fix ops instead of forcing the teams to roll their own.

No matter how capable and well-staffed ops is, it will always take them much longer to provision my stuff than if i did it myself. I like having more eyes on stuff before it hits prod, but waiting days to get things setup in dev is not just unproductive, but demoralizing.

Who owns it when it goes to production? You, by yourself? What happens when it breaks, you're on call 24/7? You really want that? You're going to stay on top of keeping it up to date, in line with governance/security requirements? When do you have time to work on features and bugfixes?

Re: “Who Should Write the Terraform?”

#18
post #7

What a long winded article to say "it depends", I liked the history though. It got me thinking, here at amazon, we deliver "infrastructure as code" using the Cloud Development Kit: https://aws.amazon.com/cdk/ We expect engineers (not devops) to define their infrastructure in typescript and configure it through code. That code gets turned into cloudformation scripts and stands up the how cloud system for the api you'r…

The layers of AWSCDK leads to a lot of brittleness, and that was a huge turn-off for us. I like the thought of building systems in a functional way but the tooling just isn't there yet. I haven't dived too deep into Terraform CDK yet, and Pulumi just had too many problems.

I am finding the same. Even a relatively simple deployment built on CDK has no end to issues and headaches, ranging from rollbacks that don't completely roll back to a previous state, dangling resources that aren't cleaned up properly, and the issues go on and on. This is mainly due to CDK depending on cloudformation which is, in my most humble of opinions, a non-starter for starting up anything more complex than a single ec2 instance.

Had we built this out in terraform, state cleanup and tracking would have been more robust, the ability to retry resource creation would have been more stable, the project overall would have been much more of a pleasure to use. The functional/declarative aspect of terraform in relation to cloudformation is so much more polished.

Edit: declarative

Re: “Who Should Write the Terraform?”

#20

At my company, I do. As a backend engineer. Guided by the devops team. It is a nightmare of arcane copy pasting. Terraform is an overengineered mess, a complex enemy I need to beat to deploy my simple changes.

Terraform really takes Conway's Law and manifests it in the real world, but I don't think terraform itself is an overengineered mess. It's quite simple when you boil it down. However, if your team structure and communication is bad, you're probably going to get bad terraform code. I've seen both, large teams writing extremely well-written terraform, and small teams writing a mess of spaghetti. Like anything in software, it mainly comes down to the people.
Post reply on HN