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

Infrastructure as Code Should Feel

scalefactory.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Infrastructure as Code Should Feel

#41

Post by nickjj »

jen20 wrote: post #26
nickjj wrote: post #10

I like Terraform but I've grown to not fully trust its plan output. There are lots of cases where you can plan something successfully without errors but then when you go and apply it you'll run into errors and now your infrastructure is in a half working state where some resources applied successfully and others failed.

You’re not wrong on this. Being able to give 100% guaranteed valid plans would require cloud providers to publish full specifications of their APIs, including (most importantly) the domain of each property relative to possible values of all the other properties of a resource. Given that most cloud providers struggle to publish an API where even the data types for properties are correct, this does not seem realistic t…

Yeah, it's not an easy problem to solve.

But it is worth pointing out because you can't trust plans for figuring out if something will work or not. However they are great for letting you know what's about to get CRUD'd, which in itself is very valuable to help prevent a set of issues but it doesn't guarantee victory in the end.

Re: Infrastructure as Code Should Feel

#42

Post by vageli »

chrisshroba wrote: post #11
pid-1 wrote: post #9

I've been doing IaC in AWS since terraform 0.11 (now added Azure and AWS CDK to the mix). Most cloud providers (and don't get me started with software platforms) support IaC as a complete afterthought. The day you decide to use IaC, you will have chosen to spend your days fighting against their APIs to make things nice and immutable. Moreover, most languages and tooling are rather immature. Things like secrets, testi…

Any pointers to what you use instead for managing those kinds of corner cases like things that modify themselves?

One solution is adding the attributes you expect to be modified to ignored_changes in a lifecycle block[0], which instructs terraform to disregard changes to those attributes when calculating diffs for plan/apply. That allows you to specify a value for that attribute at creation time and allow for its subsequent manual/non-terraform-managed modification without causing "drift".

[0]: https://www.terraform.io/language/meta-arguments/lifecycle

Re: Infrastructure as Code Should Feel

#44

Post by NateEag »

politician wrote: post #35
NateEag wrote: post #30

Earlier quoted context omitted.

"Trust" is (or at least can be) an emotion.

Trust is the faith that the subject won’t betray you or your interests despite being in a position to do so. It’s a belief, not an emotion.

Hmm, yeah, good point. I think you're right.

I guess the emotions associated with trust might be "peace" or "confidence".

Thanks for correcting my error!

Re: Infrastructure as Code Should Feel

#45

Post by nijave »

SirensOfTitan wrote: post #21
hobo_mark wrote: post #16

Earlier quoted context omitted.

As someone starting with terraform literally this weekend, why did you move away?

Asking my engineers to learn a completely new DSL (HCL) with its own quirks to change infrastructure felt like it ran against the spirit of IaC. If they were tweaking infrastructure every day, that’d be one thing, but it’s fairly hard to commit a language to your long term memory when you’re interacting with it only on occasion.

If you have common changes like adding a new queue or storage bucket, you can pull the details out into yaml or json and have Terraform loop over them. As a (potentially) added bonus, you can have different Terraform projects point to the same yaml--used to do this for maintaining subnets

Re: Infrastructure as Code Should Feel

#46

Post by nijave »

jugg1es wrote: post #24
mountainriver wrote: post #19

IaC is unfortunately the wrong abstraction for most use cases. People have become religious about it and it’s slowing down development. I’ve been doing IaC since terraform and k8s came around. We initially all thought it was great, now I think we’re covering up these wonderful UIs for a much worse interface that takes significantly longer, and in many cases gives us very little. What we will hopefully converge on is…

I was about to disagree with you until I read the part where you are using terraform with k8s. IaC starts breaking down once you start using k8s - especially if you are using a flavor like EKS that is both kubernetes but is also its own IaC platform.

k8s has its own built in IaC with object definitions (usually yaml or some sort of yaml templates) and controllers to apply the changes. I don't think most people are managing k8s objects directly with edit/patch--they're just applying complete yaml/object definitions to override current state.

If you want drift/auto apply you can use a CD solution like Argo

Re: Infrastructure as Code Should Feel

#47

Post by ozim »

I think more about culture that you should have "automate first" mindset.

Yes, changing 500 lines in a text file if you can write grep replace in 30 seconds is nice.

Automating deployment that you are doing once a month and is taking 20 mins to prepare and run, I don't feel it. Because developing such automation takes considerable resources especially if you cannot test it right away on prod and have to make test env and other overhead.

Maybe one should automate preparation parts of such deployment first and then see how it goes.

Re: Infrastructure as Code Should Feel

#48

Post by throwaway787544 »

falcolas wrote: post #29
throwaway787544 wrote: post #22

Earlier quoted context omitted.

Agreed. IaC has become another gated bottleneck; rather than waiting on an admin to change a server, we wait on an admin to write and test the IaC to change a server. One reason it's this way is poor design of cloud tech. Cloud tech isn't immutable, idempotent, and versioned, most of the time. Often there's arbitrary limitations and conventions that are not obvious which cause changes to break unexpectedly ("we don't…

> we wait on an admin to write and test the IaC to change a server This is more about company culture, not IAC. I write IAC, not a sysadmin. They don't even test it, that's what our test environment is for. There's a few things they don't let us touch, and a few enforced best practices but those are handled in code, and I can incorporate those checks as part of my usual unit test cycle. > And there are very few turn-…

You can make mistakes in IAC just like in the GUI. If the difference is having a plan stage (which, again, quite often you still don't know what the change is because it can't be known until apply), the GUI could offer a plan stage too.

One of the things Terraform should have had from day 1 was automatic import of all existing cloud resources and generation of hcl. That would allow creation of infra in a GUI and then locking it down into a version controlled declarative configuration. Terraformer (written by a Google team) does exactly this, though it's rudimentary and lacks a lot. I still use it to quickly capture the state of legacy accounts and make changes later.

Amazon should have had this for all its services by default, because it would prevent the need to manually craft code. GUIs exist to prevent people from having to slowly craft code by hand. I think people today still forget the entire purpose of GUIs because there's this cargo cult that says the only way to do anything good is to manually write lines of code.

Personally I'd be happy if I never wrote another line of code in my life, if the GUI would just version the configuration. And even better, if the state were immutable and versioned and didn't need to be constantly "fixed" by a configuration management tool (Terraform).

Re: Infrastructure as Code Should Feel

#49

Post by mountainriver »

chousuke wrote: post #33
mountainriver wrote: post #19

IaC is unfortunately the wrong abstraction for most use cases. People have become religious about it and it’s slowing down development. I’ve been doing IaC since terraform and k8s came around. We initially all thought it was great, now I think we’re covering up these wonderful UIs for a much worse interface that takes significantly longer, and in many cases gives us very little. What we will hopefully converge on is…

fancy UIs usually don't even attempt to solve the primary problem that IaC does, which is change management . Systems where changes (rather than operations) are made through interactive UIs are a horror to manage; it works for extremely simple systems, but most systems don't qualify for that.

yes but a UI could give you those properties with an ability to break glass into the underlying logic

Re: Infrastructure as Code Should Feel

#50

Post by p_l »

soco wrote: post #39
SirensOfTitan wrote: post #21

Earlier quoted context omitted.

Asking my engineers to learn a completely new DSL (HCL) with its own quirks to change infrastructure felt like it ran against the spirit of IaC. If they were tweaking infrastructure every day, that’d be one thing, but it’s fairly hard to commit a language to your long term memory when you’re interacting with it only on occasion.

You can do Terraform in Java. Or Python. Or... https://www.terraform.io/cdktf

CDK is reasonably new thing for terraform.

A lot of us have cut our teeth on previous major version of terraform DSL, when it was even less capable than it is now (no maps, no for each, etc.) and it wasn't that uncommon to be told to generate terraform JSON directly to work around DSL shortcomings, generating essentially all of the provider objects yourself.

Post reply on HN