3 ms·

I think infastructure as code is mostly overrated. I can't tell you the amount of startups wasting time cargo culting best practices without knowing why or how.

I think infastructure as code is mostly overrated. I can't tell you the amount of startups wasting time cargo culting best practices without knowing why or how. Most people would be better off just launching shit and keeping it simple

lowmagnet 9y ago
It's super useful if you embrace disposable environments. The easier it is to build a system or cluster, the more different situations you can assist your internal testing teams in replicating.
- toomuchtodo 9y ago
  Most environments that persist data are not disposable. Works great for web servers and microsevices though.
talideon 9y ago
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.
- jhundal 9y ago
  I'd like to add that a first cut as infrastructure-as-code could be as simple as putting your manual setup tasks (including SSHing into a host) into a shell script and committing it to your repo. But it takes a only trivial amount of additional time to set up an Ansible playbook (which abstracts away SSHing to a host) and then runs a shell script that's only concerned with actual setup tasks. Enough for shipping code and a good starting point for using the declarative aspects of Ansible to make your setup/deploy processes more automated and less error-prone. It is possible to cargo-cult infrastructure best practices and make the mistake of investing too much engineering resources in making your deployment practices perfect (for some definition of perfect). Infrastructure-as-code should be understood as a continual process, not something to get completely right on day one, but that applies to any part of your code/product/infrastructure. Edited: typos
mattbillenstein 9y ago
Keeping it simple is good advice, but that's not shell scripts once you have more than ~10 boxes. Picking a good config management and deployment tool, getting everything checked into git, and being disciplined about how you do things will save you mountains of time in the long run. I'm currently on saltstack and it's a nice system; it eliminates a lot of the slowness I experienced with Ansible while conceptually working similarly (playbooks -> states, templates, inventory -> pillar, roles, etc). Everything is committed in git; sensitive data like keys are encrypted with a secret not in the repo using nacl. When I deploy, I know every machine is in exactly the same state running the same software and packages -- that is much much harder with ssh and shell scripts.

lowmagnet 9y ago

It's super useful if you embrace disposable environments. The easier it is to build a system or cluster, the more different situations you can assist your internal testing teams in replicating.

toomuchtodo 9y ago
Most environments that persist data are not disposable. Works great for web servers and microsevices though.

talideon 9y ago

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.

jhundal 9y ago
I'd like to add that a first cut as infrastructure-as-code could be as simple as putting your manual setup tasks (including SSHing into a host) into a shell script and committing it to your repo. But it takes a only trivial amount of additional time to set up an Ansible playbook (which abstracts away SSHing to a host) and then runs a shell script that's only concerned with actual setup tasks. Enough for shipping code and a good starting point for using the declarative aspects of Ansible to make your setup/deploy processes more automated and less error-prone. It is possible to cargo-cult infrastructure best practices and make the mistake of investing too much engineering resources in making your deployment practices perfect (for some definition of perfect). Infrastructure-as-code should be understood as a continual process, not something to get completely right on day one, but that applies to any part of your code/product/infrastructure. Edited: typos

mattbillenstein 9y ago

Keeping it simple is good advice, but that's not shell scripts once you have more than ~10 boxes. Picking a good config management and deployment tool, getting everything checked into git, and being disciplined about how you do things will save you mountains of time in the long run. I'm currently on saltstack and it's a nice system; it eliminates a lot of the slowness I experienced with Ansible while conceptually working similarly (playbooks -> states, templates, inventory -> pillar, roles, etc). Everything is committed in git; sensitive data like keys are encrypted with a secret not in the repo using nacl. When I deploy, I know every machine is in exactly the same state running the same software and packages -- that is much much harder with ssh and shell scripts.