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

21–30 of 52 posts

Re: Infrastructure as Code Should Feel

#21

Post by SirensOfTitan »

hobo_mark wrote: post #16
SirensOfTitan wrote: post #15

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time. My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see https://github.com/pulumi/pulumi/issues/8872 it can take minutes for pulumi to plan changes if using azblob backen…

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.

Re: Infrastructure as Code Should Feel

#22

Post by throwaway787544 »

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…

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 know the result until apply" seems to happen every single apply, and success in dev is no guarantee of success in prod). And there are very few turn-key solutions, so we're left to keep rebuilding the same things and running into the same problems.

We need people creating SaaS/PaaS/IaaS to create systems that give us what we really want, without having to hire somebody to write really crap fake code to work around what those systems lack. We need GUIs that allow anyone to safely make changes without being an expert. We need turn-key solutions. We need advanced best practice deployment methods to be the first option, not implemented 5 years down the road. We need security to be easy. We need multitenancy to be the default. We need simple billing limits.

..... Ok a lot of that has nothing to do with IaC. But it's clear to me that a lot of what we do do today is an unfortunate side effect of how these systems were designed, and what they still lack. Somebody built a railroad, and we're still trying to force the railroads work like real roads.

Re: Infrastructure as Code Should Feel

#23

Post by rkangel »

SirensOfTitan wrote: post #15

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time. My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see https://github.com/pulumi/pulumi/issues/8872 it can take minutes for pulumi to plan changes if using azblob backen…

I think that terraform etc. are largely the wrong way of doing it. I think NixOS (or just the Nix package manager) is the right way of doing it but the Nix ecosystem has it's own separate set of issues. Mostly these are around (lack of) documentation making it impenetrable to get on board with.

On the other hand, my feeling is that as your problems become harder and harder (your infrastructure gets more complex) Nix is exactly the same amount of hard as it was, but the other tools begin to struggle more and more. Sometimes that's from a performance point of view (the plan speed issue you're talking about), sometimes it's because edge cases of unexpected results begin to creep in.

Re: Infrastructure as Code Should Feel

#24

Post by jugg1es »

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.

Re: Infrastructure as Code Should Feel

#25

Post by jgeurts »

hobo_mark wrote: post #16
SirensOfTitan wrote: post #15

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time. My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see https://github.com/pulumi/pulumi/issues/8872 it can take minutes for pulumi to plan changes if using azblob backen…

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

Terraform as a language is a bit clunky and feels not quite complete. For example, to accomplish if/else logic, you have to hack something like: `count = var.is_foo ? 1 : 0`

More than the language syntax, getting any response from the hashicorp team on their official providers is like rolling the dice. If your bug or feature pr is a bit on the fringes and not in their sights, it can sit for months/years without traction or even a non-automated response. With just the aws provider, there are over 3000 issues and nearly 400 open PRs. That team is understaffed or mismanaged. It has gotten marginally better over the last year or so, but generally speaking, Hashicorp doesn’t seem to care while they’re pouring all efforts into their own cloud. 1. https://github.com/hashicorp/terraform-provider-aws/issues/1... 2. https://github.com/hashicorp/terraform-provider-aws/issues/6... 3. https://github.com/hashicorp/terraform-provider-aws/issues?q...

Re: Infrastructure as Code Should Feel

#26

Post by jen20 »

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 today.

Another way to achieve a good result would be an accurate “dry run” API from the provider, but these are also often inconsistent when they exist, and make planning painfully slow.

Re: Infrastructure as Code Should Feel

#27

Post by SirensOfTitan »

rkangel wrote: post #23
SirensOfTitan wrote: post #15

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time. My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see https://github.com/pulumi/pulumi/issues/8872 it can take minutes for pulumi to plan changes if using azblob backen…

I think that terraform etc. are largely the wrong way of doing it. I think NixOS (or just the Nix package manager) is the right way of doing it but the Nix ecosystem has it's own separate set of issues. Mostly these are around (lack of) documentation making it impenetrable to get on board with. On the other hand, my feeling is that as your problems become harder and harder (your infrastructure gets more complex) Nix…

I use nix on my personal machines, and I think I agree, but the nix tooling has a lot to be desired. A well-implemented language server would be enough to drive things forward: I’m constantly unsure as to what types various variables are, or what kind of flags or options I can set in derivations.

Re: Infrastructure as Code Should Feel

#28

Post by falcolas »

iamtew wrote: post #8
drewcoo wrote: post #3

I am an IaC advocate. I see articles like this as a barrier to meaningful IaC adoption. > In the tech industry, we can be guilty of the same crime sometimes. Certain practices get ingrained into the profession to the point where we forget exactly why we did it in the first place. But in school he hadn't known why he did it in the first plave. And more often in tech I see cargo cult practices that people don't underst…

The real world don't care about feelings.Feelings are extremely subjective making these kind of statements quite vague. As a person with alexithymia, this is so confusing, I have no idea what "feels good" is supposed to mean. I know it's not bad, but that's a big spectrum of meaning. Good doesn't mean great or brilliant either. Just confusing. Emotional blindness: https://en.wikipedia.org/wiki/Alexithymia

FWIW, "feel" and "good" as used in this article is not about emotions; it's more of a shortcut that means "Do I trust that this is doing what I expect it to regarding (safety | stability | understandability)?"

"Feel": "I trust."

"Good": "Does what I expect it to."

Re: Infrastructure as Code Should Feel

#29

Post by falcolas »

throwaway787544 wrote: post #22
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…

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-key solutions, so we're left to keep rebuilding the same things and running into the same problems.

That's what IAC can do for us. IAC is, at it's heart, providing a desired state, which Terraform (ansible, etc) checks to see if the environment state matches what I requested, and if the answer is no, changes it to match the provided state.

If I was writing code to do this myself, it would do the exact same thing.

> We need GUIs that allow anyone to safely make changes without being an expert.

Amazon has a GUI that, for most operations, is perfectly acceptable. And I'd still rather use IAC than make changes via a GUI in production. And the reason is simple: I'll make mistakes. I'll forget or fat-finger one of dozens of required options for setting up a secure S3 bucket.

If everyone uses IAC against production, then it will work most of the time (the exceptions that I've run up against are very rare).

Re: Infrastructure as Code Should Feel

#30

Post by NateEag »

falcolas wrote: post #28
iamtew wrote: post #8

Earlier quoted context omitted.

The real world don't care about feelings.Feelings are extremely subjective making these kind of statements quite vague. As a person with alexithymia, this is so confusing, I have no idea what "feels good" is supposed to mean. I know it's not bad, but that's a big spectrum of meaning. Good doesn't mean great or brilliant either. Just confusing. Emotional blindness: https://en.wikipedia.org/wiki/Alexithymia

FWIW, "feel" and "good" as used in this article is not about emotions; it's more of a shortcut that means "Do I trust that this is doing what I expect it to regarding (safety | stability | understandability)?" "Feel": "I trust." "Good": "Does what I expect it to."

"Trust" is (or at least can be) an emotion.
Post reply on HN