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

The golden age of configuration languages

cosminilie.ro

Post reply on HN
Print view View original

21–30 of 53 posts

Re: The golden age of configuration languages

#21

Post by tapoxi »

This article, like so many others, makes an assumption that Salt is the 4th place configuration management tool. It is not, it is a python orchestration framework that just happens to have a configuration state module.

Deployments I've written in Salt just use the Python API (https://docs.saltstack.com/en/latest/ref/clients/) to make changes to machines or infrastructure. That's the power of it, and unfortunately its terribly underutilized.

There are legitimate criticisms of Salt of course. There's a lot of moving parts, there's a lot of half-baked stuff, the crypto has been questioned, but the core idea is honestly pretty great and its always been a pleasure to work with.

Re: The golden age of configuration languages

#22

Post by awakeasleep »

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

This may be the subject of an amazing HBR article in 10-15 years.

"Businesses need to evaluate before blindly using AWS" - Why is that seemingly logical sentence proven false so many times every day in so many companies?

In my opinion, the success of AWS is due to the way it interacts with corporate hierarchy. It allows every level to externalize some annoying part of their job in exchange for a little more money. Even Finance is happy because capital expenditures (that require more complex planning and tax handling) turn into operating expenses.

Eventually the board will wonder what happened to earnings per share, but by that time the project to migrate off amazon will be impossibly large and most people with the skills to run their own infrastructure will have retired.

Re: The golden age of configuration languages

#23

Post by anentropic »

knrz wrote: post #11
anentropic wrote: post #4

Earlier quoted context omitted.

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.

I understood it was basically Terraform under the hood...

I have little experience with either, do you find another tool more reliable?

I guess all of these tools are dependent on the consistency of the cloud provider APIs they're working with

Re: The golden age of configuration languages

#24

Post by dpc_pw »

Not sure why all previous comments are all negative. I can read this article just fine, it has nice examples, and presents the vision I also agree with - I don't want strict Dev vs DevOps split, I want Devs to be more in charge of the infrastructure of the application, and as a primarily-Dev I don't want to be dealing with bunch of half-assed DSLs that break under any complexity. I want to write a piece of code in my language of choice and use it to generate the infra description.

Re: The golden age of configuration languages

#25

Post by _wolfie_ »

anentropic wrote: post #23
knrz wrote: post #11

Earlier quoted context omitted.

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.

I understood it was basically Terraform under the hood... I have little experience with either, do you find another tool more reliable? I guess all of these tools are dependent on the consistency of the cloud provider APIs they're working with

We did evaluate pulumi. Our experience was that it basically gives you alternative, more error prone way to create terraform resource graph. Also while they claim to support python, it definitelly feels like second class citizen, it's not very idiomatic (more like almost-literal rewrite from the typescript).

So for time being we are sticking with terragrun&terraform combo.

But the concept of pulumi looks interesting and we will likely re-evaluate in a year or so to see if it has moved in the right direction.

Re: The golden age of configuration languages

#26

Post by npsimons »

calpaterson wrote: post #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 t…

As an old school sysadmin for a long time, the feeling I've always gotten from DevOps is that it is like anything else in the big ball of mud we call "computer science": a new generation re-inventing the wheel.

To be sure, the scale is larger than ever before. But history is replete with "IT in the large". Just look at mainframes, quietly ticking away for decades on loads that people are re-discovering how to handle.

Partly I blame this on the hubris of the young - "this ain't your granddad's IT." Heck, I recognize it in myself from years ago, when I was all in on Linux, but the BSDs had been around a while.

But I do believe there is a wanton lack of communication in the industry and academia. Part of this is on purpose - companies don't like "giving away" their hard won lessons, nor is it (short term) profitable to pay people to write documentation. But there's a bigger culture around "if you don't understand, you're just not smart enough." It's toxic.

We could sorely use something like the group in "Anathem" that does nothing but study history and remind others of it.

I wish we could learn the lessons of the past without having to repeat them and adding yet another standard to the fourteen already out there.

Re: The golden age of configuration languages

#28

Post by npsimons »

tapoxi wrote: post #21

This article, like so many others, makes an assumption that Salt is the 4th place configuration management tool. It is not, it is a python orchestration framework that just happens to have a configuration state module. Deployments I've written in Salt just use the Python API ( https://docs.saltstack.com/en/latest/ref/clients/ ) to make changes to machines or infrastructure. That's the power of it, and unfortunately i…

I chose salt after failing to get Puppet and Chef working. Out of the box on Debian, just no luck. Salt was just plug and go.

Haven't bothered with Ansible (yet) as it didn't officially support states when I was evaluating options, and statefulness was my number one need. I can pick up languages fairly easy (I'm a software dev by trade), so different languages don't bother me, it was more about feature set. It is annoying, though, that it seems everyone treats Salt as forgettable. I wish I could find things like https://github.com/dev-sec for Salt, but they only have Ansible, Puppet and Chef versions.

Re: The golden age of configuration languages

#29

Post by curryst »

tapoxi wrote: post #21

This article, like so many others, makes an assumption that Salt is the 4th place configuration management tool. It is not, it is a python orchestration framework that just happens to have a configuration state module. Deployments I've written in Salt just use the Python API ( https://docs.saltstack.com/en/latest/ref/clients/ ) to make changes to machines or infrastructure. That's the power of it, and unfortunately i…

> It is not, it is a python orchestration framework that just happens to have a configuration state module.

I've seen small pieces of utilization like this that looked awesome. I totally agree with the sentiment.

> There are legitimate criticisms of Salt of course. There's a lot of moving parts, there's a lot of half-baked stuff, the crypto has been questioned, but the core idea is honestly pretty great and its always been a pleasure to work with.

I could deal with that, but I have had absolutely misery trying to stabilize Salt minions. I had constant issues with them crashing or just hanging. Complexity is manageable, I can work around the parts that aren't totally there yet, I can live with maybe insecure crypto, but I can't have any stage of the deployment pipeline be flaky. It's annoying for me because I have to fix it; it's annoying to the people that need to deployments because they can never tell if their pipeline will succeed or not, and they have to wait on me to fix it. It ends up building a lot of animosity towards the tool, and by association, to the team that introduced it.

I just use Ansible now. It's not nearly as powerful (the ability to drop into Python in Salt is really nice, and I find equivalent things difficult to write in Ansible), but it pretty much always works. The abstractions are messier, but at a certain point, the less powerful but stable solution just makes more sense.

I really hope Saltstack can turn around on their reliability, because I would love to use it again.

Re: The golden age of configuration languages

#30

Post by jnwatson »

calpaterson wrote: post #20
tacker2000 wrote: post #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…

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 technol…

You could say that cloud companies exploit company dysfunction. That engineering is usually not incentivized (until too late) to keep costs down is the key to this whole mess.

I've seen the pendulum swing the other way, too. At former large employers, I've had to cobble together (shadow IT) servers from discarded equipment because the process of getting cloud boxes allocated was so onerous.

Post reply on HN