I get CLI users, sometimes using the cli is faster and more efficient.
However I have had frequent discussions with people (all of them also avid CLI users) that set up infrastructure as code. I prefer the super understandable Gui of a tool like octopus deploy over hundreds of yaml files whose content can only be understood by doing a year long deep dive any day.
They always use the same two arguments:
Infrastructure as code allows you to rebuild your entire software deployment from scratch, and the code can be versioned, thereby providing an audit trail for deployments.
In decades of software development I have exactly had to redeploy an entire network from scratch 0 times. If you’re in that stage the cause is most likely hardware and re-provisioning that will probably take the bulk of your time.
About the versioning: I’m not arguing against storing deployments as yaml files, but writing them by hand is insanely inefficient. There should be a nice GUI that generates and writes these yaml files, so you don’t have to know every option an value and every validation rule by heart.
Also, I am relatively certain that a tool like octopus deploy also has auditing of who deployed what software in which location.
To me the power of IaC is less in “I can stand this whole thing back up a single deploy” and more "The entire history of every configuration decision and change I’ve ever made is right here, not buried 4 submenus deep in a “new enhanced ui”.
When we’re being audited for security/privacy/legal compliance, I have one source of truth to look at, and when it gets changed, those changes get peer reviewed just like any other code change, and git history is a great audit trail if you use decent commit messages.
Also, knowledge transfer and onbording is way easier too, here’s all our infrastructure, here’s the rules surrounding how it gets updated, yes you will be fired if you break them. Here’s the docs regarding how to write this code, and here’s some handy formatting and validation scripts to help you along the way.
Doing it by hand in the console is fine if you have full confidence in your ability to hand over the project to another human on your way out the door, but when it comes to that one hacky workaround you had to implement with no documentation due to the limitations of your in-house apps, you’re probably forcing the next guy to rediscover why you did it that way by breaking it half a dozen times on the next deploy after your departure, rather than just noticing the inconsistency in the IaC, then looking into the git blame and mumbling “heh, that’s dumb”.
Thanks for your reply. I get the pros you mention, and auditing is more relevant for bigger shops than smaller ones of course.
Your remark on peer review reminds me of a situation where I had to change a database scheme. So that’s in a database project, and I have to do a PR on that. Now I can’t deploy it because argocd won’t allow me to manually scale down the pods of our application, and I need the database to be idle. It will revert to the defined state, so I’m unable to update without also doing a second PR on the infrastructure yaml. Then after the update I have to reverse the situation again and do a third PR.
So now I’m waiting for two approvals, and I haven’t even touched any code yet.
It just seems like so much overhead for doing something that used to take two minutes.
I think this is a question of trust and the bigger the organization, the harder it is to trust everyone.
That’s why small shops can get a lot more done in less time.
I get CLI users, sometimes using the cli is faster and more efficient.
However I have had frequent discussions with people (all of them also avid CLI users) that set up infrastructure as code. I prefer the super understandable Gui of a tool like octopus deploy over hundreds of yaml files whose content can only be understood by doing a year long deep dive any day.
They always use the same two arguments: Infrastructure as code allows you to rebuild your entire software deployment from scratch, and the code can be versioned, thereby providing an audit trail for deployments.
In decades of software development I have exactly had to redeploy an entire network from scratch 0 times. If you’re in that stage the cause is most likely hardware and re-provisioning that will probably take the bulk of your time.
About the versioning: I’m not arguing against storing deployments as yaml files, but writing them by hand is insanely inefficient. There should be a nice GUI that generates and writes these yaml files, so you don’t have to know every option an value and every validation rule by heart.
Also, I am relatively certain that a tool like octopus deploy also has auditing of who deployed what software in which location.
To me the power of IaC is less in “I can stand this whole thing back up a single deploy” and more "The entire history of every configuration decision and change I’ve ever made is right here, not buried 4 submenus deep in a “new enhanced ui”.
When we’re being audited for security/privacy/legal compliance, I have one source of truth to look at, and when it gets changed, those changes get peer reviewed just like any other code change, and git history is a great audit trail if you use decent commit messages.
Also, knowledge transfer and onbording is way easier too, here’s all our infrastructure, here’s the rules surrounding how it gets updated, yes you will be fired if you break them. Here’s the docs regarding how to write this code, and here’s some handy formatting and validation scripts to help you along the way.
Doing it by hand in the console is fine if you have full confidence in your ability to hand over the project to another human on your way out the door, but when it comes to that one hacky workaround you had to implement with no documentation due to the limitations of your in-house apps, you’re probably forcing the next guy to rediscover why you did it that way by breaking it half a dozen times on the next deploy after your departure, rather than just noticing the inconsistency in the IaC, then looking into the git blame and mumbling “heh, that’s dumb”.
Thanks for your reply. I get the pros you mention, and auditing is more relevant for bigger shops than smaller ones of course.
Your remark on peer review reminds me of a situation where I had to change a database scheme. So that’s in a database project, and I have to do a PR on that. Now I can’t deploy it because argocd won’t allow me to manually scale down the pods of our application, and I need the database to be idle. It will revert to the defined state, so I’m unable to update without also doing a second PR on the infrastructure yaml. Then after the update I have to reverse the situation again and do a third PR.
So now I’m waiting for two approvals, and I haven’t even touched any code yet. It just seems like so much overhead for doing something that used to take two minutes. I think this is a question of trust and the bigger the organization, the harder it is to trust everyone. That’s why small shops can get a lot more done in less time.