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

Rethinking Infrastructure as Code from Scratch

nathanpeck.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: Rethinking Infrastructure as Code from Scratch

#51

Post by taeric »

zokier wrote: post #8
kristianpaul wrote: post #4

The author seems to considers that the only infrastructure available these days is “the cloud”

I don't see how majority of the stuff wouldn't be applicable for on-prem too?

At large, the problem with on prem in this will be that a lot of the items in any of these "infrastructure as code" tools abstract a ton of things a human will have to do. Unless you are using "on prem" to be more akin to "private overprovisioned cloud."

Adding a new machine to your setup? When is it delivered? Who is physically connecting it to power and a network rack? Adding additional storage? Same questions, basically.

All of the software that goes onto these machines can still be done this way, of course. But that is bog standard deployment scripts. Well, it was. Not sure when we changed that.

Re: Rethinking Infrastructure as Code from Scratch

#53

Post by flanked-evergl »

naavis wrote: post #47
flanked-evergl wrote: post #40

Earlier quoted context omitted.

Bicep has limitations which makes it non-declarative even though it is marketed as declarative: https://learn.microsoft.com/en-us/azure/azure-resource-manag... MSFT is trying to add features to make this better, but it is not in production yet: https://github.com/Azure/bicep/issues/10460 Additionally, Bicep does not support interacting with Azure Active Directory: https://github.com/Azure/bicep/issues/7724 So it real…

We use it in our company to provision all our cloud resources. Granted, you can't create app registrations and such with it (yet) like you mentioned, and there are rough spots, but I think that is quite far from "not very useful".

I also worked for a company that used it, but the reasons they used it seemed almost entirely political.

Also, the issues I highlighted are quite old, I don't think deployment stacks will exist before 2024.

And not deleting resources, including role assignments, when they are deleted from your IAC source files makes it sub-optimal by Microsoft's own reckoning https://learn.microsoft.com/en-us/devops/deliver/what-is-inf...

> IaC should use declarative definition files if possible.

Bicep just is not good. It may be better than nothing, but there are better alternatives.

Re: Rethinking Infrastructure as Code from Scratch

#54

Post by mike_hearn »

drewcoo wrote: post #29
whoomp12342 wrote: post #12

this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…

> he structure and syntax for AWS is entirely different from Azure is entirely different from GCP This! We're essentially writing locked-in vendorscript. What we want is an actual infrastructure language. One that lets us write once and deploy anywhere (nods to Java). That would also allow us to standardize the way additional tooling (monitoring, logging, etc.) hooks into everything. It would allow us to easily deplo…

You could also just use Java (or Kotlin Scripting, which is a bit more ergonomic for such use cases).

I know it's super unpopular in these parts but a lot of what the article asks for is satisfied by conventional statically typed OOP (with inheritance), and other features common in full blown programming languages. You don't have to actually do the setup imperatively, but you can construct the data structures describing what you want with such tools and let some engine bring your real infrastructure into compliance.

That's why the author is experimenting with TypeScript.

Obviously, full languages allow you to eliminate repetition in many different ways. Java interfaces with default methods are very close to 'traits', Kotlin has the same features with real properties and convenient syntaxes. It also supports builder DSLs which would be ideal for this.

The main reason to use such languages is that you get full IDE features out of the box, for instance, "show me everything that uses this trait/interface/abstract base class" is one click away. Refactoring is easy.

But there are other reasons. You will often want to define some behavior that can be composed, but which leaves "slots" that the user has to fill out. Other times you need to say "something just like that, but adjusted a bit". OOP type systems are good at this sort of thing.

The DevOps world seems to continually go through cycles where someone says, full languages are too powerful, we need a declarative subset! And then it's too limited and leads to too much repetition, so you start getting stuff like if statements encoded into YAML and other nonsense. And then people get dissatisfied and try to invent another minimal declarative markup, and the cycle repeats.

Re: Rethinking Infrastructure as Code from Scratch

#55

Post by rirze »

firesteelrain wrote: post #30
twic wrote: post #7

Earlier quoted context omitted.

What i think we really need: 1. A low-level, open-ended language for describing infrastructure; it should have absolutely no facilities for abstraction, should be human-legible and machine-readable (so based on JSON, probably), and should be applicable to everything from configuring physical hosts and switches up to containers. 2. For each kind of infrastructure, a tool which can apply that language to the infrastruc…

You just described the role of Terraform. HCL is very JSON like and human readable

fwiw, you can write Terraform in JSON too. Not recommending it, but it's equivalent.

Re: Rethinking Infrastructure as Code from Scratch

#56

Post by bob1029 »

I've been side-stepping this whole conversation by using as little infrastructure as possible. I'd absolutely be digging into IAC abstractions if I had a circus on my hands and no say over why it had to be a circus.

Going into a "cloud native" stance and continuing to micromanage containers, VMs, databases, message buses, reverse proxies, etc. seems absolutely ridiculous to me. We're now using exactly 2 major cloud components per region: A Hyperscale SQL database, and a FaaS runner. Both on serverless & consumption-based plans. There are zero VMs or containers in our new architecture. We certainly use things like DNS, AAD, VNets, etc., but it is mostly incidentally created by way of the primary offerings, and we only ever have to create it 3 times and its done forever and ever - Dev cloud, Prod cloud, DR cloud. And yes - we are "mono cloud", because any notion of all of Azure/AWS/GCP going down globally and not also dragging the rest of the internet with it is fantasy to me (and our customers).

When you literally have one database to worry about for the entire universe, you stop thinking in terms of automation and start thinking in terms of strategic nuclear exchange. Granted, one big thing to screw up is a big liability, but only if you don't take extra precautions around process/procedure/backup/communication/etc.

The benefit of doing more with less also makes conversations around disaster recovery and compliance so much easier. Our DR strategy is async log replication of our 1 database. I really like the abstraction of putting 100% of the business into one place it magically showing up on the other side of the flood event.

How about this for a litmus test: If your proposed solution architecture is so complicated that you would be driven to IAC abstractions to manage it, perhaps we need to re-evaluate the expectations of the business relative to the technology.

Re: Rethinking Infrastructure as Code from Scratch

#57

Post by datahead »

firesteelrain wrote: post #13
whoomp12342 wrote: post #12

this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…

You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP

How did you approach testing this? Anything to watch out for when defining abstractions? I'm following Crossplane's abstraction model.

Re: Rethinking Infrastructure as Code from Scratch

#58

Post by wrs »

cyberax wrote: post #11

My problem with the current IAS systems is the state storage. It should not be needed! Instead, the IAS tool should introspect the systems it's managing and build the necessary state on the fly.

That is how Puppet works. Introspect the current state, compare with the desired state, fix as needed. It mostly works, but in reality it will never reach the point of introspecting literally all of the current state. So there are always ways to subtly break things without the tool noticing. (E.g., a file object that ensures the correct path, contents, ownership, and mode, but doesn’t check xattrs or ACL. [That’s hypothetical, not how the actual Puppet file module works.])

Re: Rethinking Infrastructure as Code from Scratch

#59

Post by whoomp12342 »

jerf wrote: post #24
whoomp12342 wrote: post #12

this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…

"This is what I want from infrastructure as code and I have yet to see it." If you sit down with the terraform specifications for an AWS instance, a GCP instance, and an Azure instance, and start trying to write that harmonization, you will rapidly discover why for yourself. Even just trying to specify a network setup and putting an instance on the public internet is impossible to harmonize, without making something…

I never said it was easy. I would expect complicated things to suffer, just as bytecode binary is not as efficient as a c++ binary.

Re: Rethinking Infrastructure as Code from Scratch

#60

Post by m_0x »

firesteelrain wrote: post #13
whoomp12342 wrote: post #12

this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…

You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP

> We have done it at my work to make it cloud agnostic just in case we need to go to another CSP

Have you actually tested migrating Cloud Providers with your cloud-agnostic infrastructure?

Post reply on HN