Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Who Should Write the Terraform?”

zwischenzugs.com

Post reply on HN
Print view View original

31–40 of 137 posts

Re: “Who Should Write the Terraform?”

#31

Post by erikerikson »

malfist wrote: 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 CDK seemed to be an attempt to supplant the Serverless framework and Pulumi even. Are those options barred for use internally or just under promoted?

Re: “Who Should Write the Terraform?”

#32

Post by Spivak »

cube2222 wrote: post #22

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 this would easier to adopt if it could be plopped into an existing agnostic CI system. We built something like this in-house on top of Gitlab CI and it works really well for us. Locking isn't as much of an issue as you make it seem in the pitch, we just have our infra contaiers wait to acquire and renew a distributed lease while they're running. Some kinds of failures just release the lock and others panic and stop the world for human intervention.

Presumably your core competency isn't building CI systems or job runners so why bother? I'm sure at the core of your own infra it's job agnostic The value-add is the management plane on top of it.

Re: “Who Should Write the Terraform?”

#33

Post by theideaofcoffee »

encryptluks2 wrote: post #23
theideaofcoffee wrote: post #20

Earlier quoted context omitted.

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

Quite simple for simple tasks. Automation is not always simple though. That is like asking someone to write a program that is static and only has inputs and outputs, but doesn't do loops well or anything else. Terraform is great if you are fine with duplicating things in 100 different places. Once you want to take values and plug them into various modules and run loops, then Terraform begins to suck and its weaknesse…

Yes, vanilla terraform can be a bit verbose at times but that doesn't bother me. If DRY and other software engineering-y concepts are important to you, I would recommend a wrapper that assists with that, something like terragrunt.

Re: “Who Should Write the Terraform?”

#34

Post by danwee »

cube2222 wrote: post #22

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…

Having a single "platform" team per company is a bottleneck as soon as the number of product teams is greater than N.

> ...you'll probably start having as many approaches to your infrastructure as there are teams, complexity will explode, and implementation/verification of compliance requirements will be a chore. Just a few people responsible for handling this will yield huge benefits.

Agree with the centralization of "how infrastructure should be managed/defined". A "platform" team composed of M platform engineers (where each platform engineer works 80% of their time for a given product team) can handle such centralization.

Re: “Who Should Write the Terraform?”

#35

Post by malfist »

danwee wrote: post #28
malfist wrote: 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…

As a SWE, I don't think it's great. I'm more interested in writing product features and fixing bugs. I'm not that interested in writing CDK stacks to create databases or what not.

That's fine if that's what you want. But I'd suggest that your career might be improved by being more willing to take on harder challenges and grow as an engineer. Product features and fixing bugs are intricately linked to infrastructure, and limiting yourself to only code is going to limit your ability to debug hard problems.

Early in my career, I worked for a business that still used mainframes, and we had this random bug that caused processes not to communicate and drop messages. Because I was willing to dig into the intricacies of server administration, I was able to diagnose the problem as the IPC queues size being set to the kernal default, and the default only allowed for a few seconds of messages to back up. It was a quick fix, deploy a new kernal parameter to allow for bigger IPC buffers, but if I'd refused to do "devops" work, we'd never have found the problem.

As my old boss said, you're not paid to do only the easy stuff. You're paid to do the hard stuff too.

Re: “Who Should Write the Terraform?”

#36

Post by malfist »

erikerikson wrote: post #31
malfist wrote: 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 CDK seemed to be an attempt to supplant the Serverless framework and Pulumi even. Are those options barred for use internally or just under promoted?

Amazon loves dogfooding. I don't think they're barred, but fall under the "nobody ever got fired for using CDK" domain.

Re: “Who Should Write the Terraform?”

#37

Post by danwee »

malfist wrote: post #35
danwee wrote: post #28

Earlier quoted context omitted.

As a SWE, I don't think it's great. I'm more interested in writing product features and fixing bugs. I'm not that interested in writing CDK stacks to create databases or what not.

That's fine if that's what you want. But I'd suggest that your career might be improved by being more willing to take on harder challenges and grow as an engineer. Product features and fixing bugs are intricately linked to infrastructure, and limiting yourself to only code is going to limit your ability to debug hard problems. Early in my career, I worked for a business that still used mainframes, and we had this ran…

> But I'd suggest that your career might be improved by being more willing to take on harder challenges and grow as an engineer.

Indeed. That's what I have done (I do infra stuff + product features). I don't like it, but I do it.

> As my old boss said, you're not paid to do only the easy stuff. You're paid to do the hard stuff too.

This intrinsically states "product features == easy", "infra struff == hard". While I think that certain topics related to infrastructure are hard, certain topics related to product feature are hard as well. What I think your boss wanted to say is "I don't want to pay an extra paycheck to an infra engineer. So, I'll pay you 20% more so you do the infra stuff instead. And you get to 'grow as an engineer'. It's a win-win!".

Re: “Who Should Write the Terraform?”

#39

Post by RajT88 »

mamcx wrote: post #25
RajT88 wrote: post #5

> But despite a lot of effort, the vast majority of organisations couldn’t make this ideal work in practice, even if they tried. This matches my on-the-ground experience. The teams who lived the dream of DevOps were teams which built their software as cloud native (instead of later trying to migrate to the cloud). This is purely because the PaaS tooling let them efficiently be both Devs and Admins. When you involve m…

> The teams who lived the dream of DevOps were teams which built their software as cloud native Or the total opposite. People that not drink the cloud-narrative and the operational simplicity make devops no-brainer. ie: You are truly made for the massive overenginering of cloud (because you ACTUALLY need that) or you keep things simple enough to fit in a single head. What is problematic is when you try to do be first…

The immediate following sentence from the one you quoted was:

> This is purely because the PaaS tooling let them efficiently be both Devs and Admins.

It wasn't the cloud which made them successful, it was the level of automation baked into the PaaS solution(s) they built on top of. I thought I was pretty clear on that, but I suppose I could have been more clear.

You could similarly get success if you had an OnPrem solution with really great orchestration layers. And in fact, I've heard of such successes (but not seen up close) of teams doing exactly that with Pivotal Cloud Foundry.

Re: “Who Should Write the Terraform?”

#40

Post by sodapopcan »

My experience being on a team that owned its infrastructure was that it wasn't really a terrible experience per se, but there was so much time between stories that required infra changes that the context decay was massive. We always managed, but it would take a lot of time to rebuild context and remember where everything was and generally how Terraform worked.
Post reply on HN