Mandating IaC 100% reduces velocity of change
Image credit: https://scand.com/company/blog/infrastructure-as-code/

Mandating IaC 100% reduces velocity of change

Infrastructure as Code (IaC) is talked about as the only "right" way of using the cloud. Unfortunately, that is far from the truth, just like "Agile" is to "development". As your employees are learning about the cloud, they are referring to documentation/blog articles published by the vendor (AWS being the #1 example). Almost all such documentation guides the user to implement the task at hand using the GUI console. It is quite rare for the same article to also have an IaC configuration for the exact same task. If IaC is the "preferred" way, why are the cloud vendors treating it at a lower priority than the GUI console?

Simple, it's about $$$.

It's faster for a naive user to follow step by step instructions to use the GUI and configure something vs investing a few days to learn to use IaC to implement the same thing. Human labor costs $$$, if a human can achieve something in 1hr vs 1 day, they are going to pick the shortest path as they are paid to deliver business value which pays their salary. Additionally, faster adoption of something new, equates to more revenue to the cloud service provider.

Likewise, if you are using tools like "Terraform", it typically takes 1-2 months for it to catchup and support the new shiny feature that the cloud vendor released. The cloud vendors release cadence is faster than "Terraform" for the simple reason that the vendor have more developers than Hashicorp (primary developer of Terraform modules).

Over time you will also notice that within the cloud vendor's product feature releases, they prioritize the GUI over the CLI/IaC. In some cases the CLI or IaC solution from the cloud vendor does not arrive for a few months.

Given these constraints, mandating 100% IaC has a massive dampening effect on change velocity. Developers/Infrastructure engineer love to try new features as these can help reduce costs and/or improve security.

IaC is great for objects that you re-configure quite often or need to built in a repeatable manner across multiple accounts/projects. However if you are using IaC for something that you are only going to do rarely, you are better off just using the GUI or CLI, you will end up saving a ton of time.

Moral of the story:

  • Mandate IaC based on use cases within the company.
  • Allow the use of GUI/CLI as appropriate.
  • Business unit have differing levels of expertise, be adaptive to their needs.

Your last paragraph nails it - The right time to focus on the automation/IaC is after some maturity exists for both your team and the vendor. It’s still a great goal, but don’t prematurely optimize!

要查看或添加评论,请登录

Ashish Desai的更多文章

社区洞察

其他会员也浏览了