If you're doing something with a couple of machines and it's simple, sure. However, the benefit of 'infrastructure as code' is that you have a _description_ of

If you're doing something with a couple of machines and it's simple, sure. However, the benefit of 'infrastructure as code' is that you have a _description_ of your infrastructure. Once you get above a small number of machines, keeping things consistent (because humans are humans) when you're managing pets, not cattle, is difficult and time-consuming; rolling out changes is difficult and time-consuming; understanding why something is the way it is is difficult and time-consuming. OTOH, if you have descriptions of your infrastructure in version control, you can read a description of how everything is set up and know how a given machine or VM with a given role ought to look. You can also dig through history, even if the people committing changes were lazy, and get an idea of why something ended up the way it did. Sure, doing it as a cargo cult is a bad idea, but that's a criticism that can be levelled at just about anything a start-up might do with regard to the infrastructure side of things, because they'll tend to skimp too much on people with an ops background. But that doesn't mean that it's overrated, just that it's something that you should understand the reasons for doing before doing it.