3 ms·

He did forget to mention Terraform, a tool that suffers from none of the problems he mentioned. And I'm sure there are other DevOps tools that handle state mana

by curun1r 12y ago

He did forget to mention Terraform, a tool that suffers from none of the problems he mentioned. And I'm sure there are other DevOps tools that handle state management. All these tools have to deal with the problem of state. Most of them choose to handle it implicitly...the state of the system is the state and the tool tries to determine it at runtime. This strategy has all the problems listed in the article. Other tools attempt to keep a record of the state. This solves the issues from the article but has it's own set of issues (mostly state management and state corruption). Neither approach is objectively right and both have their tradeoffs. I honestly agree with the original, down-voted, poster...the article is a bit preachy without much insight. The rise of DevOps has turned system administration into a CS problem. And, like most other CS problems these days, it all boils down to managing state. And just like there are many approaches to state management in application architecture (RDBMS, NoSQL, Paxos/Raft, etc) where no solution is objectively right, there will be many approaches to state management in DevOps where no solution is objectively right. The author obviously has his preferences, but his analysis is biased and incomplete and should be called out as such.

gfxmonk 12y ago
OP here. I've heard of terraform, although I've not investigated it much further than that. It sounds like it's mostly a provisioning tool, and doesn't really help with configuration management once your machines exist. From the "terraform vs chef / puppet" page: > Terraform enables any configuration management tool to be used to setup a resource once it has been created. Terraform focuses on the higher-level abstraction of the datacenter and associated services [...] So it sounds like like a very nice provisioning tool, but doesn't really compete with NixOS itself. Perhaps you could even use it to provision NixOs machines?
- bojo 12y ago
  You probably want to check out HashiCorp's full stack they recently released dubbed 'Atlas', in which Terraform is one small component: https://atlas.hashicorp.com/ https://atlas.hashicorp.com/
- curun1r 12y ago
  I don't want a tool that does both provisioning and configuration management as I feel the latter should be a real-time concern rather than a deploy-time concern. Using Consul (https://consul.io https://consul.io) and Consul Template (https://github.com/hashicorp/consul-template https://github.com/hashicorp/consul-template), we're able to keep configuration centralized, secure and have it deployed automatically every time it changes. And it removes the distinction between configuration changes that are triggered by some event (machine failure, network partition, monitoring, auto-scaling, etc), changes that are triggered by a developer commit and changes that operations wants to make (maintenance, DDoS response, etc). Terraform provisions all of that and then configuration management happens on an ongoing basis. I'm really not trying to sound like a shill for Hashicorp, but we use a bunch of their tools and find them to be, overall, very worthwhile and focused on accomplishing a single logical task which makes them easily composable with tools from other vendors. I also don't want it to sound like I'm criticizing Nix or NixOS...they sound like excellent tools. My only point was that there are other ways to solve the problems expressed in the posting and that each solution has tradeoffs that DevOps needs to consider when designing infrastructure. Your blog struck me as being a strawman criticism of somewhat dated tools without consideration for newer options, especially since your discussion of Docker was so narrowly focused on the actual Docker tool without any consideration given for Fleet, Swarm, ECS or any of the host of orchestration options in the Docker ecosystem. If you'd written it more from a position of "here's how NixOS has made my life easier," you'd probably find that people would be more receptive to it. But, instead, it had a "here's why NixOS is better than the alternatives" feel to it which is going to rub people the wrong way when it's pretty clear that you're not aware of all the alternatives. NixOS is one good option, but it's by no means the only good option. > Perhaps you could even use it [Terraform] to provision NixOs machines? You definitely can, so long as your servers are virtualized. Terraform is significantly less useful in a bare-metal world. However Terraform is really about provisioning specific machines. For example, you might write Terraform to provision 1 SMTP server, 3 web front-ends behind a load balancer and 2 database hosts. But it's pretty crude at doing provision-time tasks...it basically allows you to run shell commands. Where you'd do the bulk of your provisioning would be in a tool like Packer, Aminator or other such tool that creates VM images that can be deployed. That's where you'd start with a base NixOs image and then declare what's installed on an SMTP server, a web front-end and a database server. Terraform would just reference those images and size the machines.

by curun1r 12y ago

gfxmonk 12y ago

OP here. I've heard of terraform, although I've not investigated it much further than that. It sounds like it's mostly a provisioning tool, and doesn't really help with configuration management once your machines exist. From the "terraform vs chef / puppet" page: > Terraform enables any configuration management tool to be used to setup a resource once it has been created. Terraform focuses on the higher-level abstraction of the datacenter and associated services [...] So it sounds like like a very nice provisioning tool, but doesn't really compete with NixOS itself. Perhaps you could even use it to provision NixOs machines?

bojo 12y ago
You probably want to check out HashiCorp's full stack they recently released dubbed 'Atlas', in which Terraform is one small component: https://atlas.hashicorp.com/ https://atlas.hashicorp.com/
curun1r 12y ago
I don't want a tool that does both provisioning and configuration management as I feel the latter should be a real-time concern rather than a deploy-time concern. Using Consul (https://consul.io https://consul.io) and Consul Template (https://github.com/hashicorp/consul-template https://github.com/hashicorp/consul-template), we're able to keep configuration centralized, secure and have it deployed automatically every time it changes. And it removes the distinction between configuration changes that are triggered by some event (machine failure, network partition, monitoring, auto-scaling, etc), changes that are triggered by a developer commit and changes that operations wants to make (maintenance, DDoS response, etc). Terraform provisions all of that and then configuration management happens on an ongoing basis. I'm really not trying to sound like a shill for Hashicorp, but we use a bunch of their tools and find them to be, overall, very worthwhile and focused on accomplishing a single logical task which makes them easily composable with tools from other vendors. I also don't want it to sound like I'm criticizing Nix or NixOS...they sound like excellent tools. My only point was that there are other ways to solve the problems expressed in the posting and that each solution has tradeoffs that DevOps needs to consider when designing infrastructure. Your blog struck me as being a strawman criticism of somewhat dated tools without consideration for newer options, especially since your discussion of Docker was so narrowly focused on the actual Docker tool without any consideration given for Fleet, Swarm, ECS or any of the host of orchestration options in the Docker ecosystem. If you'd written it more from a position of "here's how NixOS has made my life easier," you'd probably find that people would be more receptive to it. But, instead, it had a "here's why NixOS is better than the alternatives" feel to it which is going to rub people the wrong way when it's pretty clear that you're not aware of all the alternatives. NixOS is one good option, but it's by no means the only good option. > Perhaps you could even use it [Terraform] to provision NixOs machines? You definitely can, so long as your servers are virtualized. Terraform is significantly less useful in a bare-metal world. However Terraform is really about provisioning specific machines. For example, you might write Terraform to provision 1 SMTP server, 3 web front-ends behind a load balancer and 2 database hosts. But it's pretty crude at doing provision-time tasks...it basically allows you to run shell commands. Where you'd do the bulk of your provisioning would be in a tool like Packer, Aminator or other such tool that creates VM images that can be deployed. That's where you'd start with a base NixOs image and then declare what's installed on an SMTP server, a web front-end and a database server. Terraform would just reference those images and size the machines.