If you are doing it right, infra is code. The only distinction in terms of this article is that the "orchestration" is not innately tied to the design of an app

If you are doing it right, infra is code. The only distinction in terms of this article is that the "orchestration" is not innately tied to the design of an application. Loosely coupled and composeable software using (sometimes) standard interfaces. > Pick the right tool for the job This is such an abused phrase. How about pick the right methodology for the use case? Tooling quickly becomes a cargo cult, be it languages, frameworks, or "infra tools". The deficiencies in said "tools" can often force bad designs or patterns that people apologize for rather than fix. You don't have to pick one tool for the job if you can pick a method that allows an array of tools used in a standard way. For example, S3 bucket changes. Everyone first thinks "Terraform". But there are certain S3 changes that are either difficult or impossible with Terraform. What if it's easier to allow a developer IAM role to make specific changes to specific objects and leverage said role outside Terraform? You can craft your Terraform to ignore those changes, and use any AWS SDK to make ad-hoc object changes. Maybe later you find that not using Terraform at all for that bucket, and instead just managing roles that can manipulate that bucket, works better for a larger array of use cases.