Infrastructure as Code Should Feel

Some folks seem to be taken back by the word &quot;feel&quot; in the title, but it rings true to me.<p>I work at a place with lots of super smart people. Almost everything is automated, but a lot of that automation breaks and you have to constantly get the creator involved to turn that &quot;one little knob&quot; to get it working for your job. That&#x27;s fine for the creator because he&#x2F;she knows exactly what to do when the problem occurs. However, if you&#x27;re an internal customer trying to use that system, its infuriating.<p>If you&#x27;re going to create IaC tooling for a team of 50 people, it needs to work without contacting the author. If not, you&#x27;ve just taken a 5 minute job and turned it into a 2 hour search for the bug event.

I am an IaC advocate. I see articles like this as a barrier to meaningful IaC adoption.<p>&gt; In the tech industry, we can be guilty of the same crime sometimes. Certain practices get ingrained into the profession to the point where we forget exactly why we did it in the first place.<p>But in school he hadn&#x27;t known why he did it in the first plave.<p>And more often in tech I see cargo cult practices that people don&#x27;t understand but follow some steps that may or may not &quot;work.&quot; Often these are misunderstood &quot;best practices.&quot;<p>He goes on to say:<p>&gt; Infrastructure as Code (IaC) is a practice I really feel should be implemented everywhere it is relevant. It is good common practice, the popularity of which continues to grow.<p>Which is exactly how cargo cult practices spread. What do they do? How do the do it? I dunno but everyone seems to be doing something and I think it must be like FOO.<p>It&#x27;s also incredibly dangerous to say we should follow a practice because of how it &quot;feels.&quot; Does it &quot;feel stable&quot; or &quot;feel understandable&quot; or &quot;feel fast?&quot; Who cares. Show me the value, don&#x27;t try to give me the tingles!

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time.<p>My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see <a href="https:&#x2F;&#x2F;github.com&#x2F;pulumi&#x2F;pulumi&#x2F;issues&#x2F;8872" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pulumi&#x2F;pulumi&#x2F;issues&#x2F;8872</a> it can take minutes for pulumi to plan changes if using azblob backend) with little incentive for teams like pulumi to investigate or fix unless you use their cloud. I get that pulumi is in the business of promoting their own cloud, but there are few (if any im aware of) IaC solutions not intrinsically tied to for-profit SaaS because it’s incredibly labor intensive to build consistent interfaces to several constantly changing cloud providers.

Why is the “how” cut off at the beginning of the article title. Makes it really confusing without it.

I&#x27;ve been doing IaC in AWS since terraform 0.11 (now added Azure and AWS CDK to the mix).<p>Most cloud providers (and don&#x27;t get me started with software platforms) support IaC as a complete afterthought. The day you decide to use IaC, you will have chosen to spend your days fighting against their APIs to make things nice and immutable.<p>Moreover, most languages and tooling are rather immature. Things like secrets, testing, CI&#x2F;CD, multi repo infra, collaboration, describing stuff that changes itself (e.g. databases that update automatically) are not well understood, solved problems.<p>Consequently I&#x27;m quite diligent when writing my infra as code nowadays. I reserve it for things that really play nice with immutability and are not likely to change all the time. Also, as the author says, not coupling infra code with apllication code is gold advice.

Okayish article. It&#x27;s more a marketing one than technical.

The &quot;safe&quot; section is directed primarily at the development environment but once you start collaborating with something like Terraform, there are a whole bunch of ways you can forget to plan or apply a change (for example applying in a PR but forgetting to merge or closing it because you don&#x27;t want to go forward with the change but forgot you applied it or a part of it). Shameless plug but my co-founder and I started Terrateam to try to make it really easy to get going with Terraform on GitHub and stay safe doing it. <a href="https:&#x2F;&#x2F;www.terrateam.io&#x2F;blog&#x2F;posts&#x2F;safety-first&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.terrateam.io&#x2F;blog&#x2F;posts&#x2F;safety-first&#x2F;</a>

On the other hand I can&#x27;t think in automating something like this:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30371604" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30371604</a>

IaC is unfortunately the wrong abstraction for most use cases. People have become religious about it and it’s slowing down development.<p>I’ve been doing IaC since terraform and k8s came around. We initially all thought it was great, now I think we’re covering up these wonderful UIs for a much worse interface that takes significantly longer, and in many cases gives us very little.<p>What we will hopefully converge on is UIs that basically do the same things as IaC.

I feel like infrastructure as code is one of those things that highlights your companies poor practices more than it does highlight the failures in say terraform or cloudformation.<p>A company that is willing to work at the code level to automate their systems will find tools like terraform and cloud formation useful, companies that have a LAMP stack from 2010 and no way to test their infrastructure changes in a safe way will not...

I think more about culture that you should have &quot;automate first&quot; mindset.<p>Yes, changing 500 lines in a text file if you can write grep replace in 30 seconds is nice.<p>Automating deployment that you are doing once a month and is taking 20 mins to prepare and run, I don&#x27;t feel it. Because developing such automation takes considerable resources especially if you cannot test it right away on prod and have to make test env and other overhead.<p>Maybe one should automate preparation parts of such deployment first and then see how it goes.

I like Terraform but I&#x27;ve grown to not fully trust its plan output.<p>There are lots of cases where you can plan something successfully without errors but then when you go and apply it you&#x27;ll run into errors and now your infrastructure is in a half working state where some resources applied successfully and others failed.