Live data from Hacker News

The golden age of configuration languages

cosminilie.ro

31–40 of 53 posts

Re: The golden age of configuration languages

#31

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

Yeah, the rule always seems to be "two steps forward, one step back."

I'm not convinced it's a hubris thing. Many of these "two steps forward, one step back" advancements happen because a commercial entity has intentionally blocked the tech tree from advancing in a certain direction that would undercut their position. The tree still advances, but it has to grow around the blockade, and that involves a certain amount of seemingly redundant work. It's only redundant in the sense of technological novelty, though. It's not redundant in the social context.

Re: The golden age of configuration languages

#32
> I think DevOps, as we understand it today, is coming to an end. At least the Ops part of it.

No, this is backwards. Ops in DevOps is more important than it ever has been. Devs honestly have the simplest job in the world: they just have to write some business logic and check out for the day. There's many other teams of people who then take over in order just to make sure that the app will actually work for customers, and will fix it when it stops working. The scope of work covered in QE, Architecture, Data/Privacy, InfoSec, etc teams is massive, and Ops aligns it all so the app works accordingly.

On "configuration languages": Pulumi won't ever take over because 1) some of it requires money and companies are cheapskates, 2) the licensing is not Free (part of #2), 3) there's already this other crap called Terraform that everyone is already using that doesn't have the problems of #1 & #2 and does most of what is needed for infrastructure. For the rest, there's not one thing that can manage it.

CFEngine was where I learned that Configuration Management is the 8th circle of hell. Puppet was slightly better, but now I am trying to burn down every Puppet install in the company whenever I can. Chef isn't any better. Configuration Management as a concept (such as it is up to this point, anyway) is just horrible.

It will take another 10 years, but eventually the industry will wake up to the fact that its current obsession with tooling isn't actually generating any more profit or product quality than a bunch of shell scripts would, and so maybe they should calm down a bit.

The only critical feature of orchestration tools is dependency management. Knowing what changes will impact what other changes and planning for them. Otherwise, a bunch of shell scripts really does work just as well. At that point they'll probably write some other tools, hopefully ones that separate the task of dependency management into a standard independent thing, and let other tools interoperate with it, so that we don't have to custom-code dependency management into anything that wants to use it.

I mean, Terraform is a genuinely crappy product to use, but we literally can't stop using it because of that one feature. Same goes for systems like K8s, where the design is an absolute mess, but nobody can get rid of it because they desperately need something to run a container on multiple hosts for them. And since they have that, they decide, fuck it, let's pile on a bunch of other bullshit while we're doing that and we'll lie to ourselves and say it's better now.

The important parts of modern DevOps are not technology. They are the practices, principles, values, and patterns that have proven to uplift everything else. DevOps is not about Ops, or Dev, or any other team.

Re: The golden age of configuration languages

#34

Earlier quoted context omitted.

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

Yeah, the rule always seems to be "two steps forward, one step back." I'm not convinced it's a hubris thing. Many of these "two steps forward, one step back" advancements happen because a commercial entity has intentionally blocked the tech tree from advancing in a certain direction that would undercut their position. The tree still advances, but it has to grow around the blockade, and that involves a certain amount…

The population growth of the industry is much faster than diffusion rate of best practices.

People become attached to initial ideas, resist any change, regardless of relative merits.

Everett Roger's The Diffusion of Innovation [1962], marketing's seminal textbook, explains all. Everything since is rehash (at best) or worse than wrong.

https://wikipedia.org/wiki/Diffusion_of_innovations

Re: The golden age of configuration languages

#35
I too am surprised with the amount of negative feedback. This isn't a post about locking you into AWS. Pulumi, Terraform, and friends are tools that work across cloud providers, and even your own infrastructure.

The real meat of this argument is that in the future DevOps won't be managing infrastructure to hand off to application developers. It will be creating meta programs that are designed to be used by application developers to let them build their own infra securely and reliably. This is what the `awsx` package in pulumi is. A predefined set of best practices that can be used by the application developer to create.

As someone who's worked as various stages of sysadmin throughout the past 10 years, I see this (pulumi-like) as the future. And I agree with the article in general.

Re: The golden age of configuration languages

#36

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…

I agree that there is a lot of shilling and resume-driven-development going on, but there has also been genuine progress. I would hate to manage infrastructure without Terraform, for example.

Re: The golden age of configuration languages

#40

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

That's not the way I interpret 're-inventing the wheel.' I don't see it as the next gen thinking they are smarter, but rather questioning the assumptions built into the last gen. Mainframes vs Distributed (cloud, kubernetes, etc) systems have different behaviors at different scales and are useful for different kinds of applications and business sizes. A perfect example is the startup economy. I can spool up a service for a few hundred people essentially for free, but still have the ability to scale if things catch on and I need to serve hundreds of thousands. That same scaling using old technologies would be a lot less smooth.

I mean, even if we do assume each new tech fad is mostly driven by hubris, if the results benefit the ecosystem, which cloud undoubtedly has through democratizing scalability, so what?

As far as the secret keeping of industry, I don't by that at all. I've worked for a diverse set of organizations, and every single one of them wanted to either trumpet their own practices to build clout with developers, or utilize knowledge in the public domain so that talent was easier to find. If anything companies avoid having secret sauce in their infra at all costs.

Post reply on HN