Reproducibility and peace of mind! There's nothing worse that getting woken up at 3:30 AM and realizing that it'll probably take a few hours to rebuild a server because it's dead and not coming back.
When infrastructure is code, you just spin up a new machine...no thinking involved. Also, since you're used to deploying this way, the process is smooth and as quick possible.
When you build the server by hand...you're often searching around for old ssl certificates, installing packages you forgot were dependencies, etc. Takes a long time to get it right.
If you're skeptical of the cost/benefit of the approach, you realize really quick that it's worthwhile when stuff starts to fail. Especially if it happens more than once.
Another benefit that hasn't been mentioned in the comments is that it serves as documentation. As new developers come into your team, you need to describe the infrastructure setup. Having your infrastructure defined in a clean repository is one of the best ways to do that.
Well, IaC is way better than nothing but it isn't a substitude for documentation. I had to learn an AWS CloudFormation codebase and although it's pretty clean it's still loaded with quirks (for how stuff worked years ago and to workaround shortcomings of our application).
Most IaC describes how something is configured, you should also describe why something is configured. Most IaO platforms allow you to write comments, make use of it!
The alternative is setting it up by hand which is error prone. When you're starting out, that might be OK but it'll grow and the difference between your staging and production accounts will drift.
Also, then let's say you get a mega-enterprise customer that wants to host it in their own cloud account, you simply apply the same configuration to that new account. It's quite something to see thousands of cloud resources created over the space of an hour, thinking how long it'd take to do it by hand.
I think consistency is a big benefit. Having the infrastructure described as code means that configurations are recorded in a uniform way (as opposed to just clicking around in a web interface to spin up resources and _maybe_ documenting it, for example). You can also check this code into source control and have a handle on how changes were made over time, which can be useful if a problem occurs and you want to isolate the change that broke your setup.
The old way straight up setting up a new server could eat hours of time, let alone the network, etc ... now I can copy and paste.... and I know there are no variations, someone didn't miss a setting, and so forth.
That's a crazy big cost saving.
Longer:
Physical hardware is hard.
I worked with data center networking for a long time and the efforts to generic-ify everything enough to be predictable was endless.
Eventually you have so much identical redundancy and when VMs came around you just wondered ... "wait this has to be able to go farther" and here we are.
Infrastructure-as-code is just automation. Automation eliminates the capacity for human error which can occur wherever a person manually follows some steps that might be read wrong or recalled incorrectly, and it eliminates human bottlenecks like waiting for a person to set up a server, waiting for a person to update documentation, waiting for a person to publish new packages etc. I think human error and human bottlenecks are the root cause of a lot of stress in our industry and with automation we can minimize this burden on ourselves.
One cool thing about it is that, if the infra is just a bunch of k8s pods, you can efortlessly create any number of per-developer environments using the same deployment scripts as are used for production deployments (ideally, you just change address of the k8s cluster and some environment-specific stuff like secrets), and these environment are guaranteed to be extremely production-like.
It's kind of like the saying "Teach a man to fish...". You can build a server once, but let's say one region in your hosting service goes down, can you really build a new server or cluster for that matter from scratch in time before your users notice?
We delegate to developer to make modification on the infrastructure even they don't have the access right to the servers. The change can also be reviewed by all the parties.
[+] [-] rmurri|5 years ago|reply
When infrastructure is code, you just spin up a new machine...no thinking involved. Also, since you're used to deploying this way, the process is smooth and as quick possible.
When you build the server by hand...you're often searching around for old ssl certificates, installing packages you forgot were dependencies, etc. Takes a long time to get it right.
If you're skeptical of the cost/benefit of the approach, you realize really quick that it's worthwhile when stuff starts to fail. Especially if it happens more than once.
[+] [-] gas9S9zw3P9c|5 years ago|reply
[+] [-] dmarinus|5 years ago|reply
Most IaC describes how something is configured, you should also describe why something is configured. Most IaO platforms allow you to write comments, make use of it!
[+] [-] hvgoldie|5 years ago|reply
[+] [-] gtsteve|5 years ago|reply
Also, then let's say you get a mega-enterprise customer that wants to host it in their own cloud account, you simply apply the same configuration to that new account. It's quite something to see thousands of cloud resources created over the space of an hour, thinking how long it'd take to do it by hand.
[+] [-] hvgoldie|5 years ago|reply
[+] [-] tomvalorsa|5 years ago|reply
[+] [-] hvgoldie|5 years ago|reply
[+] [-] duxup|5 years ago|reply
The old way straight up setting up a new server could eat hours of time, let alone the network, etc ... now I can copy and paste.... and I know there are no variations, someone didn't miss a setting, and so forth.
That's a crazy big cost saving.
Longer:
Physical hardware is hard.
I worked with data center networking for a long time and the efforts to generic-ify everything enough to be predictable was endless.
Eventually you have so much identical redundancy and when VMs came around you just wondered ... "wait this has to be able to go farther" and here we are.
[+] [-] benologist|5 years ago|reply
[+] [-] burntoutfire|5 years ago|reply
[+] [-] poletopole|5 years ago|reply
[+] [-] franzwong|5 years ago|reply
[+] [-] vanusa|5 years ago|reply
[+] [-] hvgoldie|5 years ago|reply