2 ms·
Obligatory quote from that XKCD about automating things. Remember, most of these tools simply automate what you already do. If you don't spend much time perform
by IgorPartola 12y ago
Obligatory quote from that XKCD about automating things. Remember, most of these tools simply automate what you already do. If you don't spend much time performing certain things, you don't need the tool. The cargo cult of "I should use Packer to create my Vagrant boxes, so I can have dev/prod parity" only works to a point. Instead, look at where you spend lots of time, and then look for tools that automate that task.
Personally, I try to be pretty conservative with tools that I start relying on. I know by painful experience that some tools get abandoned, some change drastically, making it impossible to upgrade, and some just turn out to be very buggy and horrible once you start putting them through their paces. In lots of cases, it's better to be critical than permissive when it comes to your infrastructure (and that's what these tools are aimed at). In almost all cases, your edge is in knowing the tools you use, and knowing about other tools. It's not in knowing all and using everything under the sun.
- sanderjd 12y agoThis is totally true and a great comment, but where I almost always fall into the trap is when thinking about those things that I (or my co-workers) will spend lots of time on in the future, which are much easier to automate today than they will be then. And increasingly, just knowing about other tools is hard to keep up on!
- ams6110 12y agoSo what I really need to do is automate reading HN. I'll get half my day back!
- koffiezet 12y agoThe main reason for automation is not saving time. It is about being able to reproduce and test the thing you're trying to automate. It's also about tracking changes, accountability on a larger scale. I manage quite a few servers, all running different in-house developed services. Almost all configurations are completely different, with a few exceptions, but I am still automating them. Just leaving it like it is, all manually managed would probably save me a lot of time, so why do I do it? So it can first be deployed on some test VM's, and when someone changes a configuration, I can track it in git/svn/.. and see who committed what change. It would only save me time if I had to deploy service X more than 3 or 4 times (dev/test/qa/prod), but as it stands, nop. Timesink it is.
- IgorPartola 12y agoI would say that if you are not automating something like what you describe, you would have to spend time manually verifying that it is working correctly, so it is about time after all.