Live data from Hacker News

“Who Should Write the Terraform?”

zwischenzugs.com

51–60 of 137 posts

Re: “Who Should Write the Terraform?”

#51
The answer to this question is that you should never be writing Terraform/CDK from scratch, you are wasting time.

1. Scaffold your infrastructure with simple point & click in web console.

2. Generate terraform/CDK code by scanning your AWS account with typically available tools.

3. Edit an update said Infrastructure as Code as needed, swapping out the parameters with the vectors you need to change according to CI/CD

The whole "i want to write infrastructure as code from day 1" is not only stupid , its a waste of resources.

Re: “Who Should Write the Terraform?”

#52

Software 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…

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, monitoring, encryption, etc.). They can then proceed to use it in the small service-specific Terraform configuration, which really is just putting such ready-made modules together.

The important bit being - the Platform team isn't a bottleneck here.

Re: “Who Should Write the Terraform?”

#53

Earlier 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…

Agreed.

Re: “Who Should Write the Terraform?”

#55
The thought leadership seems to be to get Dev and Ops to work directly together and avoid handoffs by creating a totally separate department called DevOps and having them do all their handoffs with dev and ops. You can call them platform engineering so nobody figures it out, though.

Re: “Who Should Write the Terraform?”

#56
The 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 provider and they go off and do so. They still fill out and track change logs, audit changes and seek approvals - but after that's done, it's still the team who presses "the button".

Anybody in a regulated industry where you've hit hard walls that prevent you and your team from going full on DevOps? If so, what rules were quoted that stopped you.

Re: “Who Should Write the Terraform?”

#57

Earlier 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…

Sure, but early in this transition it is slow&painful.

At my last org..

The old process of "Hey, can you provision a Postgres database for me please?" was managed in a web ticketing system, change managed, and had 24 hours turnaround! As was most other requests - VMs, NFS shares, FTP servers, network/FW changes, etc.

The new process was "Hey is there a terraform module for Postgres?" followed by weeks/months of prioritization and specification battles with the platform team. Somehow despite the platform existing 18 months, we were the first team to need a.. database? Then they didn't want to support Postgres and were forcing everyone onto Aurora. Then it look N months for it to come up in their queue.

Rinse&repeat with every fundamental building block of a cloud offering, ad infinitum.

This is why I strongly prefer the embed model until the platform has proven itself to at least be at the "80% solved" end of the spectrum.

Re: “Who Should Write the Terraform?”

#58

The 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…

I am not in a regulated industry, but we have recently gone through the process of getting SOC2/ISO27001 certified.

This is what was cited for us.

ISO27001:2013 A.6.1.2: Segregation of Duties. Conflicting duties and areas of responsibility must be segregated in order to reduce the opportunities for unauthorized or unintentional modification or misuse of any of the organization's assets.

Re: “Who Should Write the Terraform?”

#59

Software 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…

I think a platform team taking ownership is the correct model, but the early product teams need to have "embeds". The platform team owning base terraform functionality works well for the product teams that are the 3rd or 4th user of said functionality. For the early days of the platform, and the early users.. your product is constantly in dependency & priority battles with said platform team. This is where "embeds" h…

I tend to think of embeds as being very similar to the open source contribution model: you want some sort of BDFL entity that drives the overall direction of the platform, but also some sense of community/collaboration where individuals can feel empowered to contribute features to scratch their own itches, or bring up discussions, etc.

Having a team owning the platform doesn't necessarily need to mean shutting yourself in a cave. Granted, promoting cross-functional collaboration is a challenge in and of itself, but similar to OSS, projects that invest in the community aspect are the ones that eventually gain critical mass and set themselves apart from the rest.

Post reply on HN