Hey friends 👋 We just published a new post on Infrastructure from Code (not as-code), we worked on it with all the startups in the space which gives it a really nice balanced view of the space. Curious on what you guys think 🚀 https://klo.dev/state-of-infrastructure-from-code-2023/

Huh. Never heard of this, thanks for sharing! My initial thought is that this might be fun for university/hobby projects or PoCs. Unfortunately I am skeptical regarding real-world applications,. Just as many get-started-instantly approaches (e.g. AWS Amplify) I suspect it initially looks impressive but IMHO quickly shows it's limitations when it hits the real world in anything but the tinies organisations. Staging, recovery strategies, auditing, security guardrails etc. are likely to be big headaches with this. I would love to be proven wrong but I am personally not going to bet any important initiatives on this any time soon. PS: CDKv2 is amazing and a huge improvement over CloudFormation or TerraForm IMHO, so that will remain my go-to solution for a while.

I appreciate that @Jasper Hahn, related to our own approach with Klotho, it's been in production with multiple companies for almost a year now - we're continuously hardening and handling larger scale. In our case we look at CDK as a description language - and while we use Pulumi today, we're planning on supporting terraform and CDK next. from your perspective what do you think needs to happen for these approaches to become more viable?

Several aspects: • While I would love for all engineers to understand a bit about cloud infrastructure, I keep encountering people that are good at their particular jobs (e.g. payment logic, data science, deep-learning, ...) and generally just want to write code in a single language. It is doable to set up some blueprints and let their CI build their own infrastructure in their team accounts and require limited "hand-holding". I doubt they would be happy to have their code "polluted" by infrastructure details they do not care about. • Infrastructure often relies on specific security hardening needs, connectivity to certain sites, delegation of permissions between systems, passing of ARNs, ... and a lot of those things can be nicely wrapped in e.g. CDK constructs. I would expect the same level of abstraction and sharing of custom modules to be present in an "IfC" tool. • With mature tools come mature 3rd-party tools, such as "IaC-to-diagram", linters, vulnerability-scanners, ... and that is still lacking for something this niche