Live data from Hacker News

The golden age of configuration languages

cosminilie.ro

11–20 of 53 posts

Re: The golden age of configuration languages

#11
post #3

Unreadable on pc.

Same here... I tried to zoom out to to make the font size smaller, but it just shrank the column width while leaving the font size the same :( Shame as I'm interested in the topic, been trying Pulumi at the moment

Fair warning, I’ve been in situations with Pulumi where destroying and recreating a “stack” is the only way to solve little intermittent bugs. Not sure what level of stability you’d want from a tool like this but it made me raise an eyebrow.

Re: The golden age of configuration languages

#15
Cloud infrastructure is certainly a big thing nowadays but AWS isnt really the grand solution to all problems. Its quite expensive, and in my case, since im not using any fancy stuff, have transferred all of my servers from EC2 to a more simple service (hetzner) and now pay less than half the cost.

I think most businesses need to really evaluate this issue before blindly putting everything on AWS since it can really get pricey once you need good performance.

So my point is, all these AWS specific config languages really create an even more tight lock in with the platform, maybe it would be best to do it in a cloud agnostic way, which of course also comes with its own issues.

Re: The golden age of configuration languages

#16
I hope that configuration language programming will die soon. The approach of generating a configuration using a "real" programming language is superior (and nothing new).

>But, I think people will try to push this further and integrate the infrastructure code inside the actual app. All of it will be managed, by the application itself, at runtime.

I would only adopt this approach if there is an abstraction layer in between, like k8s, or if it would be easy to create an equivalent implementation for a different cloud provider. Being locked into dependence on AWS isn't the worst thing, but I would like to keep my application independent of a proprietary environment.

Re: The golden age of configuration languages

#17
I dont see any value in this article to be honest.

Heroku was and still is significantly easier to use than any of the tooling or services available. And it's also sufficient for a lot of businesses.

These things are just tools. If your team is skilled enough not to have a dedicated people that care about your infra that's fine.

Re: The golden age of configuration languages

#18
This barely readable webpage notwithstanding (my advice: use firefox's reader mode to remove the CSS) I am sad about how the devops community changed from being about practices (like "don't throw code over the wall" and "release often [for various reasons]") to seemingly being wholly about technology.

A huge proportion of people "doing devops" (whatever that is supposed to mean) are in fact really just lobbying for the likes of terraform and kubernetes to be adopted, preferably via some expensive Amazon/Google/Microsoft service. This article is no different. Now the answer is for the sysadmins to code Javascript and use something called Pulumi. I don't remember this being what DevOps was when I was interested in it in 2015.

Re: The golden age of configuration languages

#19
That sounds a bit like that soon programming will be gone.

No it will not. Nice dream, but it's not gonna happen. Devops is here to stay, or worse, devops will eventually move into the "real" development. With proper languages, not what we have right now. Either programming languages or something like Dhall.

Re: The golden age of configuration languages

#20

Cloud infrastructure is certainly a big thing nowadays but AWS isnt really the grand solution to all problems. Its quite expensive, and in my case, since im not using any fancy stuff, have transferred all of my servers from EC2 to a more simple service (hetzner) and now pay less than half the cost. I think most businesses need to really evaluate this issue before blindly putting everything on AWS since it can really…

Well the truth is, almost no organisations ever consider cost before they get started. That's one of the purposes of "cloud credits" that AWS/GCP/etc give out to new companies and projects that they are very successful in that.

Even worse, organisations rarely do it even once they're up and running and spending large sums - and even then I have never seen the impetus for cost control ever come from within the technology department. It's finance that reins in the spending later, and usually by sticking with the same cloud supplier but limiting activity - so now you need to get someone to sign off on your infrastructure before you provision any of it - which is largely the problem the cloud was supposed to solve.

Post reply on HN