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

Terraforming 1Password

blog.agilebits.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: Terraforming 1Password

#81

Post by geerlingguy »

solatic wrote: post #67
geerlingguy wrote: post #7

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…

> CloudFormation has its virtues Which seem to mostly revolve around AWS vendor lock-in. Which, you know, can be a valid business decision - accepting vendor-exclusive tooling for better vendor support to try and simplify initial deployment and lower near-term, initial ramp-up costs - but it has its downsides too, like losing control of costs over the long term and making advanced work (like multi-cloud deployments t…

I’m assuming someone making the decision of CF or TF would already have sold their souls to AWS at that point.

Re: Terraforming 1Password

#83

Post by matt_wulfeck »

cle wrote: post #58
djhworld wrote: 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…

One supports inline comments, the other doesn’t. That should be enough for anyone to choose one over the other.

Re: Terraforming 1Password

#84

Post by gergnz »

I find that both terraform and cloudformation have their pros and cons like many things in life. It comes down to personal preference and how you think (vim/Emacs?).

For me, I choose cfndsl to build my cloudformation templates. This gives me the ability to actually write code. JSON, YAML, HCL aren't full languages. Yes tf and cf try to provide language like concepts (iteration, etc) but really at the end of the day they are just a definition of your environment and not strictly code.

Note: I maintain cfndsl, so I'm totally bias.

Re: Terraforming 1Password

#85

Post by alexeldeib »

rgoodwintx wrote: post #17

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.

Love the visuals. Readability is less than great in some cases. I'd probably model my team's infrastructure this way and keep it as a reference to onboard new members and problem solve.

Is the readability just due to the size that the images get reproduced at? If that's the case, it looks like the text isn't great on the "standard" size people reproduce the graphic in (landing page of your site), but it looks nice inside the editor (second section on your site, very crisp). Optimizing it for size, or scaling up the representation somehow would make this a lot more pleasant to look at for me.

Re: Terraforming 1Password

#86

Post by merb »

ben0x539 wrote: post #71
merb wrote: post #10

would've been easier to just migrate to k8s and used some kind of ignition/managed k8s (and maybe ansible, if things still needs some manual tweaking).

I'm really interested in migrating some of our own systems/services to k8s and I'd love if you could elaborate a bit. How do IAM resouces or VPC subnets etc map to k8s concepts?

well k8s has his own RBAC system so IAM does not map 1:1. The same with VPC subnets, you actually have your own network with k8s. Some can peer via BGP, like kube-router (as far as I know) and calico (which I use). So basically k8s is a little bit different than the concepts of aws.

Re: Terraforming 1Password

#87

Post by sneak »

epistasis wrote: post #77
smsm42 wrote: post #72

Earlier quoted context omitted.

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…

It's funny, I came to the comments to specifically complain about that graphic. There are significant disadvantages to the isometric view for that data, and absolutely no advantage that I can see, other than it looks pretty if you're not trying to get information out of it. I think that Tufte needs to make a resurgence with this generation of designers.

Take it up with BeOS? :D

Re: Terraforming 1Password

#88

Post by inferiorhuman »

ben0x539 wrote: post #70
_ix wrote: post #54

Earlier quoted context omitted.

I'm not so sure about this. My experience has been limited, but so far, Terraform has been a treat to work with. I didn't think Terraform cared about where the resources were defined in a the plan step. I'd love for someone with further experience to weigh in here. Also, Terraform state on the file system ? Do you have the luxury of solo development without the need for a Terraform remote backend?

I think the complaint is that you define a resource in some module, then do a bunch of refactoring with the result that the very same resource is now defined in another module, terraform will need to be explicitly told that it's still the same resource or else it will destroy and recreate it on application. That is, it's about the file system layout of the .tf tree, not the state.

There's also tf import and tf delete to manually import resources to your state and remove them respectively.

Re: Terraforming 1Password

#89

Post by solidsnack9000 »

geerlingguy wrote: post #7

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…

The real advantage of CloudFormation comes in combining it with the AWS APIs -- you can define your infrastructure as code in Python, NodeJS, Java, Ruby, &c.

* troposphere (Python): https://github.com/cloudtools/troposphere

* cloudform (JavaScript, TypeScript): https://github.com/bright/cloudform

Driving infrastructure with a general purpose programming language actually works pretty well in practice.

As things have developed, I've come to question infrastructure-specific external DSLs, like Salt, Terraform, even Chef to some extent. Infrastructure is not any less programmable than payments, machine learning, graphics, app servers. Why can't the tooling be provided as libraries, consumable from ordinary programming languages?

Re: Terraforming 1Password

#90

Post by wgjordan »

0x62c1b43e wrote: post #73
wgjordan wrote: post #43

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…

Could you share what preprocessors/templating languages you've used with CloudFormation?

I've used Embedded Ruby (ERB), I was also converting YAML to JSON before CloudFormation added native support for YAML templates (Sep 2016). My company's web application was a Ruby/Rails stack so `.yml.erb` syntax was already quite familiar to our team. Pre-processing the template is a simple shell one-liner that you can easily add to your test/deploy scripts:

    cat template.yml.erb | ruby -rerb -e "puts ERB.new(ARGF.read, nil, '-').result" > template.yml
A lightweight template-preprocessor step adds just enough scripting automation (in a familiar language/environment of your choice) to cut through boilerplate, and avoids imposing yet another domain-specific intermediate abstraction layer on top of the whole stack (e.g., troposphere's Python API, arguably also Terraform's HCL).
Post reply on HN