Live data from Hacker News

Terraforming 1Password

blog.agilebits.com

111–119 of 119 posts

Re: Terraforming 1Password

#111
post #62

Earlier quoted context omitted.

> The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). There are also decent tools atop CloudFormation for using an a…

> The Cfer project that I contribute to [...] is the thinnest possible wrapper around CloudFormation that we could come up with. I've found preprocessing CloudFormation YAML using a standard template language (e.g., ERB) to be the thinnest possible wrapper around CloudFormation for providing if statements and loops without breaking our backs. Cfer looks nice and lean, but it still adds another domain-specific languag…

It is a DSL, but it's literally as thin as it gets. =) `method_missing` calls define properties. I'd take YAML+ERB over HCL for sure, though. And Cfer treating everything as objects gives us a really simple packaging mechanism for reuse--they're just gems.

Objects just work way better for reuse and aggregation than text, IME.

Re: Terraforming 1Password

#112

Here I am wishing that CloudFormation had one killer feature that would have allowed us to use it at work: the ability to adopt existing resources into a CF stack. When we were starting on the path of "hey maybe all our infra shouldn't be pointy clicky", we chose between CloudFormation, Terraform, and making something in-house. Out of those three, Terraform was the clear winner for us at the time, but it has not been…

You can use outputs in CloudFormation to adopt resources from existing CF stacks. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Re: Terraforming 1Password

#113
post #72

Side note, for anyone wondering like I was, the visualization tool is Cloudcraft: https://cloudcraft.co/ . I'd love to have something similar for doing isometric views of any kind of diagramming.

I am not sure I get the point of making it (fake-)3D. Except for all text to be diagonal and me having to tilt my head to read it, and cute pseudo-3D pictures of variously formed boxes, I don't see any advantage. It's still essentially 2D - there's no third dimension I could usefully explore - it's just presented in a visually cute but informationally cluttering way. Is there any advantage to this form of presentatio…

AWS has sometimes used in their diagrams, so everyone wants it when creating theirs. I work on https://www.lucidchart.com (which has "only" 2D diagrams) and it's a common request.

You're correct that 2D makes for greater readability and information density.

Re: Terraforming 1Password

#114
post #58
post #9

Earlier quoted context omitted.

Personally I find YAML for cloudformation worse than JSON because of the whitespacing requirements. JSON isn't much better mind, especially once your template reaches to hundreds of lines with nested objects. Recently I've come around to using Troposphere [1] to write cloudformation templates, it's actually very pleasant to use. You just write your infrastructure in python, and it will generate you a template at the…

I'm sorry, what? You don't like YAML because it uses whitespace as a delimiter instead of curly braces? That is probably the least important feature that YAML adds for CF templates. YAML, despite its warts, is much more readable and maintainable for CF templates than JSON, particularly when you are doing non-trivial things and need to use a lot of intrinsic functions and string manipulation. Or you want to put commen…

Absolutely agree! Have been smashing out YAML templates for 12mths with pleasure (3yrs of JSON templates beyond that), comments are the winning proposition, allows neat sectioning of various parts.

Re: Terraforming 1Password

#115
post #21

The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). I’ve spent a lot of time working between the two, and while Terr…

I am sorry but I just could not grasp YAML for some reason. I am always confused by its indentation and maps vs lists notation.

Initially I was that way too, only took a couple weeks and a few reference templates that demonstrated the constructs to get past that and haven't done JSON since. Definitely more efficient to develop with.

Re: Terraforming 1Password

#116
post #101

With infrastructure in multiple regions, do you have independent Aurora databases running in each region? Do you have any data synchronising between regions or are they running completely independently?

They are completely independent, that was the goal.

Re: Terraforming 1Password

#118

> servers will be down for the next few hours. We are recreating our entire environment to replace AWS CloudFormation with @HashiCorp Terraform. One of the greatest strengths of terraform (vs say, cloudformation) is that you can adopt existing resources, and ZERO downtime is needed to migrate. Why take downtime?

Because we needed to re-deploy our database, which unfortunately requires downtime.

Re: Terraforming 1Password

#119

I use CloudFormation to manage similar AWS web-app infrastructure. I've been continuously evaluating Terraform over the years (it is indeed maturing quickly), but have still decided to stick with CloudFormation for now, and would still continue to recommend the same for anyone managing an AWS-exclusive (or mostly-AWS) deployment. To respond to some specific items mentioned in this post: - "Terraform has a more straig…

Disclaimer: I work for AgileBits.

CloudFormation is a great tool, don't get us wrong. It is one of the first cloud IaaC tools.

And it has it's downsides:

- inability to address specific object in the state, similar to `-target ` option in terraform

- forcible re-deployment (`taint`ing) of the resouce is not possible too, well, not as easy as in TF

- when creating ChangeSet in CF, it is absolutely useless on nested stacks, all you see in it is "Stack will be updated", even if there is nothing to update

- targeted `destroy`s do not exist, as well as destroy `plan`s: similar to what `terraform plan -out plan.out -destroy -target aws_resource.name; terraform apply plan.out` does

- The work with state, renaming, reassigning, deleting and importing resources is missing in CF as a class

- TF refreshes state of the resources each run, checking their actual state and trying to revert any changes applied to them outside of the flow, CF assumes that nothing is changed and gets very surprised when it is drifted or simply doesn't match its expectations. ( I know there is drift detection, but does it actually restores the desired state? I've never had a chance to check that..)

When we deployed new TF stack, we imported part of the resources created by old CF template. And now I am a bit worried to clean it up, because it might try to delete old resources, even with '"DeletionPolicy": retain'. I have no visibility or control over its action. Basically: apply the template and pray.

ChageSets also failed me once, trying to do not what it was telling me in the plan. Terraform plan once captured into the file will do exactly what it promised me, when applied.

To sum up: both tools got their 'pro-'s and 'con-'s, and personally I feel more comfortable with the Terraform.

Post reply on HN