211–220 of 315 posts
I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…
I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…
You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!
Earlier quoted context omitted.
It’s pretty wild that the object identity via name thing is still a problem. Can they not add a transitional name feature where an object is known by multiple aliases for a while and then when you have finished putting though a change, you can delete the original name? Is this not very basic SQL migration practice? Like column aliases until no longer needed.
I don't even understand why the state needs to know the identifiers that the high level language uses for various resources. If the high level language has a binding "foo_bucket" for an AWS S3 bucket resource with a single property `name = "foo"`, then why should the state need to know that the high level language refers to that bucket with the name "foo_bucket"? Instead, the state should look something like this (ob…
Earlier quoted context omitted.
100%. Terraform is half-way between a tool for generating the configuration and applying it. I think Terraform's application engine is actually quite good, but I would like to use a much better tool to generate the config. (And be able to diff that config) You can feed JSON to Terraform however this falls over if you need dependencies for output values. This usually isn't an issue because most Cloud provider resource…
> application engine [vs] tool to generate the config I get it from HashiCorp's perspective though. A robust application engine with a suboptimal config generator is a viable product. A suboptimal application engine with a brilliant config generator is not. So given limited resources, former gets the dev grease.
You can generate these configs really easily with any off-the-shelf programming language for a small fraction of the effort they’ve put into HCL + all of the stuff on top that makes HCL the shitty programming language that it is.
Even if you insist on building your own programming language for this purpose, Hashicorp could’ve saved themselves a lot of work by looking at the prior art of the last 70 years of programming language history.
In other words, if they just picked, say, JavaScript from the start they could have saved a bunch of time and energy and put that into their application engine.
Earlier quoted context omitted.
Yeah, CloudFormation is workable in this regard (I've created a neat generator for Python), although it has lots of its own problems (e.g., if you want to create a new resource, you have to run it as its own lambda--your infra-as-code needs its own infra which needs its own infra-as-code).
> I've created a neat generator for Python care to share? (I know some hn users often don't w/o being asked, out of a sense of not wanting to be seen as self-promoting.)
One afternoon with Terraform and you'll want to give up cloud and get your own datacenter again.
I have a highly fuzzy result in my sarcasm detection here. It's because I can understand this to mean either that: 1. Terraform is so difficult managing cloud services that you'll give it all up and run for the hills of bare metal once again. - or - 2. it's so good you'll want to swear off the cloud providers and switch to running your own infra using Terraform and not the cloud services own tools. Given other commen…
I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
+1 from me on the "awful half-baked language" (HCL). I just recently wrote an article about my experience, including issues and workarounds, when migrating from Terraform to Pulumi: https://blog.ekik.org/my-experience-migrating-my-infrastruct... Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform…
Only cmake's 'language' is worse.
Earlier quoted context omitted.
You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!
Pulumi sounds interesting. Spent 10 mins with their marketing website and I'm not very clear whether it is a standalone set of libraries, or do they only work in conjunction with their cloud services. Do you know?
Looks like they actually might have added locking recently with https://github.com/pulumi/pulumi/pull/2697 but I haven't looked deeply
Earlier quoted context omitted.
Its a problem only if you use these vendors, you don't have to.
It's a pretty tough sell to tell people they have to uproot all of their existing infrastructure and move to Amazon just to use an infra-as-code tool.
Tools are never 'just tools', there is context and there are externalities. And as you already pointed out: migrating/uprooting all of those other things isn't a likely scenario.
Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…
Not sure why Hashicorp felt the need to reinvent the wheel instead of having a library in an existing language generate markup or JSON or something like that.