Why are we templating YAML?
My belief is that we&#x27;ve been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren&#x27;t sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) points out, we just end up with a funky, poor approximation of a language.<p>I think this approach is a byproduct of thinking about infrastructure and configuration -- and the cloud generally -- as an &quot;afterthought,&quot; not a core part of an application&#x27;s infrastructure. Containers, Kubernetes, serverless, and more hosted services all change this, and Chef, Puppet, and others laid the groundwork to think differently about what the future looks like. More developers today than ever before need to think about how to build and configure cloud software.<p>We started the Pulumi project to solve this very problem, so I&#x27;m admittedly biased, and I hope you forgive the plug -- I only mention it here because I think it contributes to the discussion. Our approach is to simply use general purpose languages like TypeScript, Python, and Go, while still having infrastructure as code. An important thing to realize is that infrastructure as code is based on the idea of a <i>goal state</i>. Using a full blown language to generate that goal state generally doesn&#x27;t threaten the repeatability, determinism, or robustness of the solution, provided you&#x27;ve got an engine handling state management, diffing, resource CRUD, and so on. We&#x27;ve been able to apply this universally across AWS, Azure, GCP, <i>and</i> Kubernetes, often mixing their configuration in the same program.<p>Again, I&#x27;m biased and want to admit that, however if you&#x27;re sick of YAML, it&#x27;s definitely worth checking out. We&#x27;d love your feedback:<p>- Project website: <a href="https:&#x2F;&#x2F;pulumi.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pulumi.io&#x2F;</a><p>- All open source on GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;pulumi&#x2F;pulumi" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pulumi&#x2F;pulumi</a><p>- Example of abstractions: <a href="https:&#x2F;&#x2F;blog.pulumi.com&#x2F;the-fastest-path-to-deploying-kubernetes-on-aws-with-eks-and-pulumi" rel="nofollow">https:&#x2F;&#x2F;blog.pulumi.com&#x2F;the-fastest-path-to-deploying-kubern...</a><p>- Example of serverless as event handlers: <a href="https:&#x2F;&#x2F;blog.pulumi.com&#x2F;lambdas-as-lambdas-the-magic-of-simple-serverless-functions" rel="nofollow">https:&#x2F;&#x2F;blog.pulumi.com&#x2F;lambdas-as-lambdas-the-magic-of-simp...</a><p>Pulumi may not be <i>the</i> solution for everyone, but I&#x27;m fairly optimistic that this is where we&#x27;re all heading.<p>Joe