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 -
Replying to @ben11kehoe @southpolesteve and
There’s a few attempts for imperative JS abstractions you write in app with magical layers generating infrastructure and it really bothers me. For instance, rollback plan? Sorry, you lose that new bucket with info because of a bug in unrelated critical feature.
1 reply 0 retweets 1 like -
Replying to @ShortJared @ben11kehoe and
Also, why is the canonical example for why these systems are useful just simple loops for generating auto scaling groups?
1 reply 0 retweets 3 likes -
Replying to @ShortJared @ben11kehoe and
Agree 100% the existing examples are garbage. I wish they would take a serverless first approach. Show me a complex system of >10 fns reacting to events from >3 services.
2 replies 0 retweets 0 likes -
Replying to @southpolesteve @ShortJared and
One of the big issues I have with the current setup is your infra dependency graph is prob already split between code and config. Example: dynamo streams -> lambda -> SNS chain. That second edge is expressed in the lambda code. The first one is in CF.
1 reply 0 retweets 0 likes
A tool that unifies application and infra code could understand that. I don't think it exists, but it feels possible.
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.