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.
Don’t hate me here but this feels like that meme where the guy puts a stick in the spokes of his bike and blames the stick.
I think that’s just a process problem, definitely depends on the specifics of your organization but I think if you raised that concern, you could probably come up with a solution that isn’t quite so burdensome, while maintaining the maturity level of IaC.
And I hate to be that guy but that last sentence doesn’t seem have much at all to do with IaC. Big shops can use IaC, so can small shops. In my case it’s the latter, we just have so much tech spread across so many platforms that maintaining it purely via GUI is infeasible. IaC is simply the best way to go for us, due to the sheer number of moving pieces.
Well, we can certainly agree to disagree. I’m not oblivious to having a blind spot here and there.
In fact, I very much enjoyed our discussion here, and your perspective. It almost feels like a 2000s era forum discussion, before all the sour people got access to the internet. So thanks, and get well soon!
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.
Don’t hate me here but this feels like that meme where the guy puts a stick in the spokes of his bike and blames the stick.
I think that’s just a process problem, definitely depends on the specifics of your organization but I think if you raised that concern, you could probably come up with a solution that isn’t quite so burdensome, while maintaining the maturity level of IaC.
And I hate to be that guy but that last sentence doesn’t seem have much at all to do with IaC. Big shops can use IaC, so can small shops. In my case it’s the latter, we just have so much tech spread across so many platforms that maintaining it purely via GUI is infeasible. IaC is simply the best way to go for us, due to the sheer number of moving pieces.
Then again, I’m sick and maybe I’m misreading it, if that’s the case, my apologies.
Well, we can certainly agree to disagree. I’m not oblivious to having a blind spot here and there. In fact, I very much enjoyed our discussion here, and your perspective. It almost feels like a 2000s era forum discussion, before all the sour people got access to the internet. So thanks, and get well soon!