Live data from Hacker News

Terraforming 1Password

blog.agilebits.com

61–70 of 119 posts

Re: Terraforming 1Password

#61

Earlier quoted context omitted.

Have a look at https://www.pathwaysystems.com/video/#racks1 The video is a bit slow because it's meant to be instructional. There are other videos on the same page which show how the model (graph) can be viewed logically instead of isometrically (what we call spatially). I'm the CTO, happy to answer questions.

The product looks pretty interesting, but I don’t see any pricing. What would it cost for a single user?

Our marketing is currently geared towards teams, so our pricing starts at 12k USD/yr for a 10 user subscription. We haven't yet rolled out official individual pricing so I don't want to jump the gun here by announcing prematurely, but if you start a free trial and mention you're seeking a single user, we can discuss further via email.

Re: Terraforming 1Password

#62

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 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 actual programming language instead of whatever HCL wants you to think it is. The Cfer[0] project that I contribute to (and use as the underpinnings for the Auster[1] cloud workflow tooling) is the thinnest possible wrapper around CloudFormation that we could come up with. But it just by existing lets us do things like...y'know...if statements and loops...without breaking our backs. Code reuse is better than whatevery module reuse, too; I wrote a gem, which this reminds me that I need to open source, that lets me roll out a standardized three-tier network of varying size (important because AWS tends to work best with /24 subnets but hey, you might want more than three of them per tier) without really thinking about it too hard.

(Back when Terraform was new, I tried writing a halfway decent DSL on top of it; turns out "it's really just JSON under the hood" was untrue and no testing had been done on that path. I assume it has since. But HCL still exists, and HCL is still pretty awful.)

I would say not to use Terraform if you're using only AWS, because Terraform has a nice habit of hosing your state when you look at it funny and I've had it literally regress to the point of making states in version X unreadable in version X+1. But those issues are separate from the clunky DSL.

[0] - https://github.com/seanedwards/cfer

[1] - https://github.com/eropple/auster

Re: Terraforming 1Password

#63
post #12

Earlier quoted context omitted.

The internal infrastructure of AWS apps are fairly guessable anyway. There are only a limited number of AWS resources and they fit together in predictable ways, VPC - Gateway - ASG - EC2 etc etc. I think it's really great that they've talked about this, it's quite rare to hear about these kinds of internal migrations, and it's something I do a lot with clients but it's not really glamorous enough to talk about.

Hi vr46, where should I go / what resources should I consult if I want to start learning more about AWS & setting up infrastructure? Thanks!

Forgive the self promotion but I'm building a subscription video site - http://stackleap.com/ - to teach people how to build and deploy to AWS infrastructure.

The difference between StackLeap and sites like acloud.guru is that I'm focussing on the day to day stuff rather than high level concepts you need to know to pass the certification exams.

I'm hoping to launch a beta in the next few weeks.

Re: Terraforming 1Password

#64
post #35
post #30

Earlier quoted context omitted.

I believe there was a case last year when one of the new AWS features was available in Terraform before it made it to CloudFormation :)

It's still the case. I can't find it on mobile, but I asked a StackOverflow question and later answered it myself after discovering something like this buried in the AWS documentation.

Yup, found it: https://stackoverflow.com/questions/45858031/how-to-get-elas...

Terraform supports it, CloudFormation doesn't...

Re: Terraforming 1Password

#65

I’ve always wondered — from a security perspective, is this kind of an in-depth engineering blogpost a good idea? You’re basically handing a map of your internal infrastructure to any potential attacker who reads the blog. Of course obscurity is not security blah blah blah. Still I can’t help feeling that writeups like this could backfire down the line.

All this tells me is that they use EC2, Aurora, and other AWS products. What am I supposed to do with that?

Re: Terraforming 1Password

#66
post #37

Earlier quoted context omitted.

Ah. I wondered what made these terrible diagrams. They look cute but the text and the symbols are incomprehensible.

Looks mostly comprehensible to me. A lot of the icons are obvious if you deal with this stuff a lot, like the ELB, Redis icons, and the ones with instance types written on them. Bit too zoomed out to read the small text, though.

If they didn't have the precious isometric projection and just showed a regular 2D diagram it would be more legible.

Re: Terraforming 1Password

#67

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 to improve reliability) more fragile, difficult, and sometimes de-facto impossible.

Seems to me like the question of CloudFormation vs. Terraform has more to do with whether the business makes a strategic decision to allow for vendor lock-in or not, rather than mostly aesthetic discussions over the merits of YAML vs HCL.

Re: Terraforming 1Password

#68

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…

> It's easy to pipe configuration through your favorite 'straightforward and powerful' templating language of choice to generate the stack template used by CloudFormation. I definitely wouldn't use CloudFormation at all without an extra preprocessing step of some sort.

The tricky bit is what kind of logic you can apply to values that are the result of provisioning/looking up resources in the first place, isn't it? Like, what dynamically determined resource IDs are exposed to the language and in what places you can reference them. Basically the capability of terraform's interpolation language vs. CloudFormation Fn::* constructs, I suppose.

Re: Terraforming 1Password

#69
post #56
post #44

Earlier quoted context omitted.

Puppet rules are typically applied constantly in short intervals. The installed version should always be the same everywhere, the latest available from the repository. The risk is more that you can get updates installed at inopportune times. Of course what's right is that the version change is not reflected in the configuration management, but this isn't normally a problem for minor version changes.

I think the default settings for puppet agents are typically 30 minutes if I'm not mistaken. I've inherited a bit of a DevOps mess with some 600-700 nodes in various states of management. In previous positions, there was a great hew and cry that the run intervals were increased from 30 minutes to 60 minutes... eventually every four hours for production resources. In my current position, production nodes are provision…

Well I've seen many environments, and some only ran puppet manually whenever they would before had used ssh and made a change directly. Another allowed one group of admins to just continue to log in and make small config changes, then got alerts and diffs of those changes from running puppet in noop and incorporated those changes into their git after the fact.

It's a tool to be used however you see fit and what you describe sounds reasonable, but the most common (because default) setup I've seen is the 30 minute interval.

Which is why I would argue "time of last puppet run" is mostly fairly recent and consistent for all machines, but terraform apply is most often not run automatically, not even at daily intervals.

Re: Terraforming 1Password

#70
post #54

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…

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.

Post reply on HN