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

111–120 of 124 posts

Re: Rethinking Infrastructure as Code from Scratch

#111

Post by slotrans »

I was with it right up until this statement:

> Centrally updatable: Sometimes best practice or corporate policy changes over time. You can update what LowCost or SecurityPolicy means later on, in one place, and that change will reapply to all resources that used it.

It sounds great but it's not. This is essentially the Fragile Base Class problem. You may _think_ that updating one of these traits in a single place will be safe and do what you want, but it may be disastrous for whoever is using it. And you're not going to find out until you deploy it.

Re: Rethinking Infrastructure as Code from Scratch

#112

Post by cyberax »

thorgaardian wrote: post #88
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.

A lot of people will argue that state helps protect against drift, but the real reason I find that you have to have state is to store values that won't be returned a second time and still construct and connect the graph of resources in the IaC templates. For example, if you declare the need for an RDS database and connect its output credentials into another application, you'll need state in order for the applies to w…

Yeah, and now all your creds are available for everyone to see. Instead use IAM authentication for RDS, or if it's impossible, store creds in SSM or Secrets Manager.

Yeah, it's not fully transactional, but it will work fine in practice.

State is just a poor crutch.

Re: Rethinking Infrastructure as Code from Scratch

#114

Post by firesteelrain »

twic wrote: post #83
firesteelrain wrote: post #30

Earlier quoted context omitted.

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

I've never used Terraform. So HCL is the low-level language i talk about; what does a human write to generate it?

They write HCL/JSON. It’s not by definition low level anything per computer science standards. It’s very high level. It’s declarative.

Re: Rethinking Infrastructure as Code from Scratch

#115

Post by VectorLock »

xorcist wrote: post #96

The split between parameterized classes and logic sounds a bit like the split between Puppet and Hiera. The idea was probably a good one, but something about the implementation made people go overboard with it. I feel IaC really peaked around Puppet 3 and Chef 1. IaC should be simple enough that people use it, and trivial to write providers for. People tend to glue much too large libraries to their IaC platforms and…

Chef and Puppet are configuration management systems, not really Infrastructure as Code.

Re: Rethinking Infrastructure as Code from Scratch

#116

Post by VectorLock »

taeric wrote: post #51
zokier wrote: post #8

Earlier quoted context omitted.

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, bas…

Yeah there are people who are talking about blah blah blah cloud complexity and how on-prem is some panacea. What they're really getting at is "why go through all this trouble to setup autoscaling groups and load balancers when I'm perfectly fine running things on a single Pentium II whitebox sitting in my closet?" It doesn't seem to occur to them that although that might work _for them_ the whole reason we go through this labor is we need MORE than that.

Re: Rethinking Infrastructure as Code from Scratch

#117

Post by twic »

firesteelrain wrote: post #114
twic wrote: post #83

Earlier quoted context omitted.

I've never used Terraform. So HCL is the low-level language i talk about; what does a human write to generate it?

They write HCL/JSON. It’s not by definition low level anything per computer science standards. It’s very high level. It’s declarative.

So not what i described at all then. The whole idea is to have a low-level language you can generate with high-level code written in a real programming language.

Re: Rethinking Infrastructure as Code from Scratch

#118

Post by gunapologist99 »

bob1029 wrote: post #56

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…

ransomware, cancellation, billing snafus, attackers, insiders,..

https://threatpost.com/hacker-puts-hosting-service-code-spac...

Re: Rethinking Infrastructure as Code from Scratch

#119

Post by NathanKP »

jen20 wrote: post #110
NathanKP wrote: post #78

Earlier quoted context omitted.

I'm the author of the article. I actually shared a prototype towards the end of the article, of the idea implemented in CDK. I agree that you can do a lot of this already in CDK, CDKTF, and Pulumi. I just don't think most people are actually doing it (yet). I've been using CDK since early beta, and have actively contributed to the project. But most people that I'm seeing using it today are just wrapping up new higher…

Most people are still clicking around the console. A new paradigm is not required to allow them to use what already exists, just education. The question of WHY the mixins are required is interesting to me - they point to the abject failure of cloud providers to keep up with their customers.

As I work at a cloud provider I have a different perspective on the mix-ins. The problem is that at scale there is no one customer type. Some customers absolutely require a specific way of configuring things, while other customers require exactly the opposite. Cloud providers are always trying to add more features to please all people, its a fundamental side effect of growth. And an often unstated aspect is that the most custom features are often extremely high value ones that were added for customers that worth large amounts of money to the business, even though the other 90% of small users and startups may not need that.

I think mix-ins can be a way to make the growth in features accessible while not overwhelming. Out of the box mix-ins can provide 80% of the value for 80% of the people and the long tail of 20% customers with the super custom needs that are worth high dollar amounts can still build their own custom mix-ins that target their specific use cases.

Re: Rethinking Infrastructure as Code from Scratch

#120

Post by firesteelrain »

twic wrote: post #117
firesteelrain wrote: post #114

Earlier quoted context omitted.

They write HCL/JSON. It’s not by definition low level anything per computer science standards. It’s very high level. It’s declarative.

So not what i described at all then. The whole idea is to have a low-level language you can generate with high-level code written in a real programming language.

IaC isn’t programming. It is more like config files that have some scripting elements like for loops
Post reply on HN