Nobody should write terraform
A: “Our Terraform is so bloated it’s starting to rot!”
B: “Hashicorpse strikes again.”
“Who Should Write the Terraform?”
71–80 of 137 posts
Re: “Who Should Write the Terraform?”
#72Software Engineer at Spacelift[0] here - a CI/CD specialized for Infra as Code (including Terraform). A pattern we're seeing increasingly commonly are Platform Engineering teams doing the bulk of the work, including all the fundamentals, guidelines, safety railing, and conventions, while Software Engineers only use those, or write their own simple service-specific Terraform Stacks which however extensively use module…
Thank you for the plug. Surprised such an open commercial promotion got top comment.
Re: “Who Should Write the Terraform?”
#73Earlier quoted context omitted.
What exactly is a "Conflicting duty"? What's stopping a company from stating that developing, deploying and supporting software is a single duty?
Nothing ... except compliance. The idea comes from finance -- to require collusion to execute a fraud. It's not perfect, but it's something.
Maybe I should rephrase that: Is it impossible for a company that defines Dev+Ops as a single responsibility to be compliant?
Re: “Who Should Write the Terraform?”
#74Earlier quoted context omitted.
Author here: yup Pendulum back to the center
Partly yes, but not fully. The idea is not to go back to the Software Engineer asking the Ops team "Hey, can you provision a Postgres database for me please?" and then waiting a week for it. It's that the Software Engineer takes a module that was prepared by the Platform team - i.e. "terraform-postgres-mycompany" - which already includes all the requirements the company has for handling databases (think backups, moni…
No post body was provided.
Re: “Who Should Write the Terraform?”
#75Devs 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.
> waiting days to get things setup in dev
not really an ops thing. This is just the reality of large corps. Microservices are the same way, with devs partitioned off. You put in a Jira ticket and wait a month for a turnaround on a task that would take an hour to do. Eventually management wants it done now and, like always, they bust open and manipulate the process for their own purposes. Rules for thee, not for me.
Re: “Who Should Write the Terraform?”
#76Earlier quoted context omitted.
Nothing ... except compliance. The idea comes from finance -- to require collusion to execute a fraud. It's not perfect, but it's something.
Maybe I should rephrase that: Is it impossible for a company that defines Dev+Ops as a single responsibility to be compliant?
No. Assuming a well configured continuous deployment type environment; you just need to have peer review on code before it can hit production, and you need to have controls in place over the who, what and when of elevated access to production being granted
Re: “Who Should Write the Terraform?”
#77Earlier quoted context omitted.
Nothing ... except compliance. The idea comes from finance -- to require collusion to execute a fraud. It's not perfect, but it's something.
Maybe I should rephrase that: Is it impossible for a company that defines Dev+Ops as a single responsibility to be compliant?
Not impossible. even in a prescriptive framework like ISO 27001, adequate SOD is a judgement call between you and the auditor. Generally speaking, if a single dev can push a code change to prod, in a way that would escape audit or not require a second pair of eyes, that would not be compliant. So if a dev writing code, also manages the deploy environment, that may not pass muster.
But it's not that cut and dried. There are degrees of rigor.
Re: “Who Should Write the Terraform?”
#78Re: “Who Should Write the Terraform?”
#79The author calls out a few reasons why DevOps fails for organizations all of which I agree with - however the one that I've never completely understood: Regulatory reasons for keeping Ops centralized. I work in healthcare which I guess should fall under this rule - but in practice I haven't really seen that impeding DevOps. Teams that have the capabilities to build the full stack get handed a subscription to a cloud…
Author here. That's interesting, as I've not worked with healthcare too much.
Others here have cited segregation of duties, which is definitely a factor, but the other one less mentioned in finance is the 'one throat to choke' principle: it's simpler from a management and regulatory perspective to have the responsibility for failures in one place rather than across many teams.
Re: “Who Should Write the Terraform?”
#80Wow that was excellent, very thorough but also easy to read and with minimal fluff
My personal take is that DevOps doesn't work (for me, and probably many others) because it amounts to context-switching (recently featured on HN: https://news.ycombinator.com/item?id=32390499). By being responsible for both Dev and Ops, my time (and my brain) gets split 50/50 into two entirely different sets of:
- Concerns
- Languages
- Tools
- Mindsets
This is both super draining, and counter-productive, for me. If Ops can be made so simple (by a platform team or otherwise) that it doesn't amount to a whole separate headspace, then great, I'll manage instances myself. But as long as it's a whole separate domain, trying to have one foot on each side of the fence is just not going to be workable.