Hacker News Reader

Comment by bbrazil | Hacker News Reader

A phenomenon I've noticed is some believing that containers solves configuration management. It's true that containers through being immutable means you don't have to worry about what cruft has built up from previous changes (which is a big win). That still leaves you with the core problem of how you manage your configs.

The core of configuration management is a) how you express the state of the world and b) how you move from state to state safely, with potentially hundreds of changes in flight at once. For the former I'm excited about projects like https://github.com/apmasell/flabbergast, and the latter is mostly a matter of breaking rollouts into individually rollbackable changes combined with good policy.

View on HN

Thing is containers themselves are not immutable. One implementation (Docker) enforces this but it's not so when using raw namespaces/cgroups, systemd-nspawn or lxc/lxd etc.

IMO it's not tools that are the problem but a lack of deep understanding. A lot of people practicing "DevOps" lack the raw knowledge.

This I can agree with. It almost seems as though this new kind of "DevOps" (to use the same air-quoted term as you) is being used as a band-aid for companies to be able to accomplish traditional sysadmin goals, without having to pay for people with depth of knowledge. Things like Docker and cloud services make it easy to think that one does not need the knowledge a sysadmin needed to have ten years ago, but that's not true. What's happened is that applications like Docker have obscured the need for that knowledge by making things easier to accomplish. And then when those companies run into problems, nobody on the tech team knows how to put out the fire. Now, I suppose that's not such a bad thing if you're outsourcing all that work to a cloud services provider. Then it's a matter of opening a support ticket. But then again, you're at the mercy of those providers. I can see why Docker is so attractive for companies, which implies one can self-host these cloud services and save a ton of money, while also appearing to not need that raw knowledge because of ease-of-use provided by applications like Docker. It looks like an attractive way to cut down on quite a lot of cost. But what happens is that the cost is actually offloaded from needing the knowledge to build and maintain the infrastructure, and onto the moment of failure. And the thing about that cost offloading is that this cost could kill your business. Just picture a tech team with red status pages and buzzing phones, but without the knowledge to dissect what's happening. It's a ticking time bomb. Also I should mention I'm saying this as a huge, huge fan and user of Docker, but also as someone with twenty years in the industry, watching the "new DevOps" crowd.

More specifically I've noticed less reliance on configuration management frameworks like puppet and chef.

If you're building a container cloud, consisting of 'immutable' servers and a scheduler like kubernetes, then there's not much of a role left for one. You might use the lightweight versions (e.g. chef-solo) to bootstrap the servers, bake an AMI (or god forbid a container image). And you'll use something like cloudformation or terraform to configure the cloud. But if I'm going to toe the immutable infrastructure line I'm not going to use a config mgmt tool to update the state of my existing servers.

I've only just glanced at flabbergast but in terms of readability at least - it seems far short of something like Ansible

https://github.com/apmasell/flabbergast/blob/master/flabberg...

(I'm not arguing that they solve the same problem - I really have no idea - but readability matters and choosing a JSON syntax over YAML or similar when humans are meant to be parsing it seems like a mistake)

Flabbergast is solving a different but related problem, it's about expressing the state of your system. Lots of times you want to say the dev environment is like the prod environment, except for these 3 things. And by the way, anything in the European region needs different settings too that interact with dev/prod.

I'm a fan of Ansible, but it isn't really suitable for expressing multi-dimensional and multiple-levels of exceptions, from experience it works for about 2.

How that state is actually rolled out is the job of something else (which could be Ansible or the update portion of your cluster scheduler).

Fair enough but does that affect my thoughts on readability? YAML is actually a superset of the capabilities of JSON so as far as I know there's no inherent advantage to choosing JSON as the syntax.

Reply on news.ycombinator.com