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

Terraform should have remained stateless

bejarano.io

Post reply on HN
Print view View original

181–190 of 329 posts

Re: Terraform should have remained stateless

#181

Post by georgyo »

ntoskrnl wrote: post #168
Jasp3r wrote: post #163

Earlier quoted context omitted.

That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?

No DNS provider I've ever used has a way to store metadata alongside a DNS record (like an individual A record)

Why do I need metadata along with my A record? It either exists or it doesn't. That is the state required for Terraform.

The article explicitly mentions OctoDNS as a stateless configuration management system for DNS as a good solution.

Re: Terraform should have remained stateless

#182

Post by m1keil »

Jasp3r wrote: post #165
m1keil wrote: post #51

> Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things. Ansible, Chef, Puppet and co existed long before Terraform. If the stateless way would work better, these tools take over the cloud infrastructure space. But they didn't. To me it seems like a good sign that the their approaches didn't fit to infra. Additionally, one of the biggest te…

Ansible and Puppet are for infrastructure automation across multiple VMs. Terraform is a way to declare cloud (native) infrastructure as code. Ansible and Puppet are not used anymore because of the shift to cloud native, not because they are stateless.

I wasn't suggesting that CMS fell from grace because they were being stateless. I was saying that when TF just started, these tools were in the right position to take lead over the IaaC space and didn't because the stateless model didn't fit. Take a look at Ansible's cloud modules, they tried.

TF's success, in my opinion, can be boiled down to:

a) Having a state - allowed them to provide declarative config with plan functionality

b) Choosing Go - removed the burden of installing or having to invest in self contained setup like they did with Vagrant & ruby.

I'm not a TF zealot. I hate my life every time I need to use it. And yet I know that there are no better alternatives out there. I'm sure there are some nice things in Pulumi or cdk-tf but I doubt switching to any worth the investment with existing TF project.

I would be glad to try and play with a tf-like project that works without state - "talk is cheap, show me the code".

Re: Terraform should have remained stateless

#183

Post by master_crab »

tedk-42 wrote: post #24

Ahahaha there are commenters that don't realise that Cloudformation IS the state for your infrastructure that you've provisioned. Ansible is stateless because every operation is suppose to be idempotent. Unless your ansible is doing a HTTP PUT request to an API I suspect you're misusing the tool for something it's not meant to do. State is a good thing with infrastructure and terraform got it right.

Cloudformation is not the state of your architecture. It tracks the state. A very big difference.

You can still make changes to resources within stacks outside CF, and Cloudformation can still be very unaware of the drift.

Re: Terraform should have remained stateless

#184

Post by KyeRussell »

georgyo wrote: post #181
ntoskrnl wrote: post #168

Earlier quoted context omitted.

No DNS provider I've ever used has a way to store metadata alongside a DNS record (like an individual A record)

Why do I need metadata along with my A record? It either exists or it doesn't. That is the state required for Terraform. The article explicitly mentions OctoDNS as a stateless configuration management system for DNS as a good solution.

To know if it’s managed by TF or not, to know whether or not to delete it. Exactly what’s being described.

Re: Terraform should have remained stateless

#185

Post by pid-1 »

pojzon wrote: post #69
kevan wrote: post #57

Earlier quoted context omitted.

Have you checked out CDK or Pulumi? CDK still has a few warts but overall I've been pretty happy with it. Haven't used Pulumi but from chatting with friends it sounds like it has a similar feel as CDK but supports multi-cloud like Terraform.

Cdk is compiling into CF template. And Pulumi is using Terraform providers under the hood. Writing infra in imperative style can cause ALOT of unseen issues when developers start adding IFology or Design Patterns..

Most CDK code is absolutely declarative. Unlike TF, you have an actual programming language as a escape hatch.

Re: Terraform should have remained stateless

#186

Post by aequitas »

stingraycharles wrote: post #149
pharmakom wrote: post #98

The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…

The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources, rather than a standalone file. In other words, this metadata then is the state. Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?

> The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources

Except for the Cloud's and API's that don't provide them but we stil need configuration managed. This is the world we live in, and in that world Terraform is the solution to the problems that we seek. In an ideal world Terraform would not be needed, but we don't live in that world.

Re: Terraform should have remained stateless

#187

Post by smcleod »

w3456yhbvr5yh wrote: post #180
smcleod wrote: post #46

Earlier quoted context omitted.

After spending the last 6 months with AWS CDK - I'd kill to go back to using Terraform which is far from perfect but light years ahead of CDK which is the most consuming time sink I've ever had to work on, it's truly dreadful. Give me Terraform any day!

"time sink" is also how i would describe CF templates and wrappers like SAM. I'd be grateful if you could elaborate on the CDK issues. I'm also curious to know how many people in this thread consider themselves developers as opposed to devops/cloud engineers.

There is so much toil involved in the software framework(s) around CDK, the most common CDK language is typescript - which while in many ways is better than JavaScript still suffers from the same garbage ecosystem.

The serious problem with CDK is that it's just a wrapper for CloudFormation - so you have all the limitations of a CFn backend with the added complexity of a full general programming language and ecosystem.

While Terraform is far from perfect you can land in a team, look at the terraform repo and immediately know what's going on, you've got very commonly used patterns / templates that can very quickly spin up your platform.

With CDK almost anything you create is a pet, a special snowflake that almost immediately becomes technical debt.

You end up spending a lot of time on maintenance and upkeep, updating libraries for (really bad!) node security patches, you have to test those updates across whatever packages and repos you're using them in, maintain software build/test/secure/deploy CI pipelines.

I've seen CDK at reasonable scale - it's painful with more than a couple of repos, even worse when they're spread across teams and products. With Terraform at least you just update Terraform itself after checking for breaking changes.

I could keep on ranting but I think no matter what I have seen and say - many developers will take a default position to arguing that infra/platform code is always better written in their language than any DSL, wrapper or templating system, I've heard this time and time again and only really agree with it when it's with Lambda only workloads, Often people cite "a real language is so much more powerful" etc... but in reality 99% of the time you just don't need highly complex programming logic when creating reliable and scalable platform using something like Terraform. (Insert "any fool can create something complex" quote here).

The one and only place I think CDK is genuinely a half-decent tool for the job is with Lambda only deployments as long as you keep it pretty lean don't don't over cook it with complexity and keep in mind that it's just CFn in the background so it has the same limitations.

I'm in a "DevOps" / platform engineering / automation role.

:)

Re: Terraform should have remained stateless

#188

Post by dangus »

I think the author of this article misunderstands what Terraform is for and what it does.

The author compares Terraform to Ansible and Puppet, but these are not analogous tools. If you compare to Pulumi, you'll notice it also has state.

Keeping track of what is live and what is expected to be live is much of the utility of Terraform.

If the author is getting some Terraform state pain (e.g., from drift caused by a team making changes to infrastructure and forgetting to represent those changes in code), they should try using Terraform Cloud or building a CI pipeline for their infrastructure.

Re: Terraform should have remained stateless

#189

Post by moondev »

Jasp3r wrote: post #163
EwanToo wrote: post #157

Earlier quoted context omitted.

This is the fundamental misconception of the article as far as I understand it. Cloud providers do not provide enough metadata to enable that mapping across all resources.

That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?

https://github.com/nat-henderson/terraform-provider-dominos

terraform is more than just cloud providers https://registry.terraform.io/browse/providers

Re: Terraform should have remained stateless

#190

Post by NateEag »

ntoskrnl wrote: post #168
Jasp3r wrote: post #163

Earlier quoted context omitted.

That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?

No DNS provider I've ever used has a way to store metadata alongside a DNS record (like an individual A record)

That's what TXT records are for:

https://en.m.wikipedia.org/wiki/TXT_record

Post reply on HN