I don’t view this ratio as a better/worse thing. Config as code it a good practice already, and once you have that, it’s moving complexity, not creating it.https://twitter.com/springrod/status/1002379190174302208 …
-
-
Replying to @ben11kehoe
im with you. trading my chef+CFN code for SAM + CFN has resulted in a drastic reduction in management code. the CI/CD bits become boiler plate and change less often so shouldn't be a big pain with scale
1 reply 0 retweets 2 likes -
Replying to @chrismunns @ben11kehoe
Is part of the issue dev perception? I worked to keep devs out of Puppet. It was invisible to them. Now they’re finding themselves having to do infra code that others did for them before.
3 replies 0 retweets 0 likes -
Replying to @tmclaughbos @chrismunns
there's also this weird resistance to declarative code that I'm seeing. Lots of config approaches are being driven by "let devs code it in JS because that's where they're comfortable", which I sort of get, but seems like in the long run loses a lot of benefits
3 replies 0 retweets 4 likes -
I'm in this camp. I see both sides. To me, there is a big benefit to JS everywhere. By turning JS into a declarative plan can't we get the best of both worlds?
1 reply 0 retweets 0 likes -
I don't think so. The JS is what gets checked in to source control, and thus you lose the easy inspectability and language independence
4 replies 0 retweets 2 likes
Why not check in the intermediate plan? We do this with .lock files. Language independence I care less about. JS everywhere :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.