7 ms·

The golden age of configuration languages

46 points by iliec 6y ago

iliec 6y ago
It's an article about the fact that DevOps as we know it, might be coming to an end.
Okkef 6y ago
Unreadable on pc.
- anentropic 6y ago
  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
  - knrz 6y ago
    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.
    - anentropic 6y ago
      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
      - _wolfie_ 6y ago
        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.
- vesinisa 6y ago
  Totally agree. The font size is defined as 3% of min(viewport width, viewport height). On my full-screen desktop browser this results in so large text it is unbearable to read. Fiddling with browser window size results in varying font sizes ranging from way too large to way too small to read. Massive accessibility fail. Font size is one of the few things that usually works fine out of the box with modern browsers across devices of all sizes - unless someone decides to do crazy stuff like defining the font size in relation to the viewport size.
- deleted 6y ago
  [deleted]
- drcongo 6y ago
  I had to put it into Outline: https://outline.com/S8at4k https://outline.com/S8at4k
- snazz 6y ago
  It's quite readable if you make your window size super short and wide, but it's weird that this is even necessary.
- arc-in-space 6y ago
  "Ah, this font is a little too large. Let's just zoom out-" https://i.imgur.com/l7Gh3jX.png https://i.imgur.com/l7Gh3jX.png
  - athorax 6y ago
    Weirdly enough, zooming in actually widens the columns and makes it almost normal looking
- recursive 6y ago
  Reader mode on firefox rescues it.
- oftenwrong 6y ago
  The sad part is the page is perfectly readable if you remove the CSS. They took something that was easy to read by default, and made it less readable in an attempt to make it more readable. https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/
- andoriyu 6y ago
  Reader mode in whatever browser you're using will help you. That said, you're not missing much by not reading it...
blargmaster42_8 6y ago
XML or death
tacker2000 6y ago
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.
- calpaterson 6y ago
  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.
  - jnwatson 6y ago
    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.
    - calpaterson 6y ago
      > You could say that cloud companies exploit company dysfunction. Like every large software vendor, yes, it's moderately profitable to produce good software and sell it but it is much, much more profitable to abuse bad procurement practice. Shadow IT is a sad state of affairs but at least it builds the skills and culture to economise on computing cost.
oftenwrong 6y ago
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.
EdwinLarkin 6y ago
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.
calpaterson 6y ago
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.
- npsimons 6y ago
  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.
  - jjoonathan 6y ago
    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.
valenterry 6y ago
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.
tapoxi 6y ago
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/ 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.
- npsimons 6y ago
  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 https://github.com/dev-sec for Salt, but they only have Ansible, Puppet and Chef versions.
- curryst 6y ago
  > 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.
dpc_pw 6y ago
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.
jevgeni 6y ago
Please don't do things like "font-size: 3vmin".
0xbadcafebee 6y ago
> 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.
purpleidea 6y ago
You should have a look at https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ Disclosure, I'm the main author.
marcopolo 6y ago
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.
neonate 6y ago
These are more readable: https://outline.com/S8at4k https://outline.com/S8at4k https://archive.is/sElqB https://archive.is/sElqB
Tehchops 6y ago
This article is interesting but it is nigh unreadable.
closeparen 6y ago
>The need to handle application infrastructure (I see this different than managing core business services infrastructure like AD, email, finance systems, etc.) This point goes by quickly but it's important. One of the biggest factors in my employer's relative reasonableness is IT's corporate network and engineering's production environment have nothing to do with each other. Separate teams, datacenters, stacks, and cultures. We still have a group that will write a change management plan in Microsoft Word to work on the corporate finance Oracle instance during a scheduled downtime window. But I can release my new API endpoint to customers whenever I want (after code review) using a contemporary CI/CD workflow.
0xCMP 6y ago
Author should check out https://arc.codes https://arc.codes and https://begin.com https://begin.com because I think that's what they're looking for. I would err to say that Pulumi is not and should not really be used for this, but I was just thinking of how annoying it is setup some open source projects in AWS (especially if they're made for it or any other specific env) and that having the Pulumi config, at least some basic modules, would make it so much easier to get started.

46 points by iliec 6y ago

iliec 6y ago

It's an article about the fact that DevOps as we know it, might be coming to an end.

Okkef 6y ago

Unreadable on pc.

anentropic 6y ago
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
- knrz 6y ago
  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.
  - anentropic 6y ago
    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
    - _wolfie_ 6y ago
      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.
vesinisa 6y ago
Totally agree. The font size is defined as 3% of min(viewport width, viewport height). On my full-screen desktop browser this results in so large text it is unbearable to read. Fiddling with browser window size results in varying font sizes ranging from way too large to way too small to read. Massive accessibility fail. Font size is one of the few things that usually works fine out of the box with modern browsers across devices of all sizes - unless someone decides to do crazy stuff like defining the font size in relation to the viewport size.
deleted 6y ago
[deleted]
drcongo 6y ago
I had to put it into Outline: https://outline.com/S8at4k https://outline.com/S8at4k
snazz 6y ago
It's quite readable if you make your window size super short and wide, but it's weird that this is even necessary.
arc-in-space 6y ago
"Ah, this font is a little too large. Let's just zoom out-" https://i.imgur.com/l7Gh3jX.png https://i.imgur.com/l7Gh3jX.png
- athorax 6y ago
  Weirdly enough, zooming in actually widens the columns and makes it almost normal looking
recursive 6y ago
Reader mode on firefox rescues it.
oftenwrong 6y ago
The sad part is the page is perfectly readable if you remove the CSS. They took something that was easy to read by default, and made it less readable in an attempt to make it more readable. https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/
andoriyu 6y ago
Reader mode in whatever browser you're using will help you. That said, you're not missing much by not reading it...

blargmaster42_8 6y ago

XML or death

tacker2000 6y ago

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.

calpaterson 6y ago
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.
- jnwatson 6y ago
  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.
  - calpaterson 6y ago
    > You could say that cloud companies exploit company dysfunction. Like every large software vendor, yes, it's moderately profitable to produce good software and sell it but it is much, much more profitable to abuse bad procurement practice. Shadow IT is a sad state of affairs but at least it builds the skills and culture to economise on computing cost.

oftenwrong 6y ago

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.

EdwinLarkin 6y ago

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.

calpaterson 6y ago

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.

npsimons 6y ago
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.
- jjoonathan 6y ago
  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.

valenterry 6y ago

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.

tapoxi 6y ago

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

npsimons 6y ago
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 https://github.com/dev-sec for Salt, but they only have Ansible, Puppet and Chef versions.
curryst 6y ago
> 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.

dpc_pw 6y ago

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.

jevgeni 6y ago

Please don't do things like "font-size: 3vmin".

0xbadcafebee 6y ago

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

purpleidea 6y ago

You should have a look at https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ Disclosure, I'm the main author.

marcopolo 6y ago

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.

neonate 6y ago

These are more readable: https://outline.com/S8at4k https://outline.com/S8at4k https://archive.is/sElqB https://archive.is/sElqB

Tehchops 6y ago

This article is interesting but it is nigh unreadable.

closeparen 6y ago

>The need to handle application infrastructure (I see this different than managing core business services infrastructure like AD, email, finance systems, etc.) This point goes by quickly but it's important. One of the biggest factors in my employer's relative reasonableness is IT's corporate network and engineering's production environment have nothing to do with each other. Separate teams, datacenters, stacks, and cultures. We still have a group that will write a change management plan in Microsoft Word to work on the corporate finance Oracle instance during a scheduled downtime window. But I can release my new API endpoint to customers whenever I want (after code review) using a contemporary CI/CD workflow.

0xCMP 6y ago

Author should check out https://arc.codes https://arc.codes and https://begin.com https://begin.com because I think that's what they're looking for. I would err to say that Pulumi is not and should not really be used for this, but I was just thinking of how annoying it is setup some open source projects in AWS (especially if they're made for it or any other specific env) and that having the Pulumi config, at least some basic modules, would make it so much easier to get started.