Hacker News Reader

Comment by bostik | Hacker News Reader

I think couple of our engineers have said it really well, so I'm going to quote them both.

1. All config management systems suck in equal measure, but in different fashion. This is why you pick the tool that sucks the least for your particular usecase, and hope that two years down the line you made the right choice.

2. People who don't know how to write proper code end up creating two kinds of things. Either they write a config management system, because they believe it doesn't require deep diving; or they try to write a monitoring system, because they don't understand what they are getting into. One way or the other, the hidden and emerging complexities will eat them all.

Config management is hard, and the more stuff you have to massage on various hosts, the harder it gets. (For the record: I'm a big fan of slim hosts and immutable infrastructure movement.)

View on HN

I've started using terraform and packer since I wrote that post. I'm going to stick with those tools for the time being. Configuration management is solving a problem that no longer exists. Pre-bake your infrastructure and then download the rest at runtime if you can't do it at bake time.

Coupled with docker, hashicorpt vault, and fpm I think the problem of deploying and configuring anything is pretty much solved and the remaining issue is basically how you go about doing orchestration for things like rabbitmq clustering which I don't think any of the existing configuration management tools try to address anyway. You either need to configure the topology ahead of time which kinda defeats the purpose of having a reactive infrastructure or you have to write some kind of custom thing on top of what you are using already which again kinda defeats the purpose since most of these configuration management tools try to be declarative and you often need imperative things to configure something like a rabbitmq cluster.

Terraform is a neat tool. From my limited experience so far, it manages to hide most of the complexity when dealing with EC2 network setup. We haven't tested it with VPC peerings yet, but do expect to see that one in a near future too.

I don't quite agree with you about config management being useless, but its role certainly can be reduced. A real life example: database hosts with dedicated high performance volumes, their read replicas, and due to regulatory compliance, always up-to-date off site replicas on physical hardware.

Same holds for load balancers, btw.

And as for docker, I have mixed feelings. I disagree with quite a few of their design and engineering decisions, let alone with their QA so far. However - I do think that they nailed the basics of the devs' workflow UX. Anyone can write a dockerfile, and the deployment story is pretty well thought out. (I happen to disagree with the registry address being part of image namespace, tbh.) Things start to get a bit iffy when you need to consider exported volumes, and host interaction in general; why can't you declare per-image default export paths on the host configuration? Why is restart policy controlled by arguments to dockerd, instead of metadata inside the built docker image?

I know the engineer in us all screams "that's a job for the orchestration engine, stupid!" but the fact that you need to accept and integrate with a lot of external complexity tells me that a lot of questions in this space are still open.

Reply on news.ycombinator.com