问题描述
正在进行一个项目，将当前的混合半手动、半无文档、半ansible的堆栈迁移到AWS上的一个稳定的代码定义架构中。他们计划在AWS CloudFormation中大量使用，并将以下任务卸载给一个内部工具：
– 管道化（按顺序运行CFs /脚本）
– 脚本任务（无法通过CloudFormation完成的任务）
– 模板化（如果/如有必要）
– 内部验证
这个工具预期将从头开始构建我们的整个环境（除了一些无法自动化的事情）。
我们的产品（至少在后端）完全使用Javascript构建，虽然它不是我首选的语言，但我倾向于使用Javascript编写这个工具。我的另一个选择是Python，因为我更喜欢那种语言。然而，我认为坚持使用一种语言（库、工具、范式等）有很大的价值。
用户的问题是：
– JS是否适合这种类型的工具？
– 如果我们将来雇佣一个DevOps工程师，这会引起很大的关注吗？
– 在DevOps社区中使用JS是否不寻常？
我们已经在一些自动化中使用JS（通过https://serverless.com/）。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
JS作为DevOps内部工具的合理选择
在使用AWS服务时，特别是使用JavaScript的aws-sdk，JS是一个非常合理的选择。使用JavaScript编写代码可以消除前端人员和后端人员之间的障碍。只要推动使用JS，组织就可以获得更多的开发人员，他们没有阅读和修复基础架构代码的障碍。
例如，我熟练使用Python、Ruby、Shell、JavaScript（甚至Perl）。但是，当需要修复或添加一些HashiCorp工具（如Terraform）时，我没有足够的时间去学习Go语言，所以我就不去做了。如果Terraform这样的工具使用JavaScript编写，我早就为那个缺失的服务添加了我的贡献。
在AWS Lambda中，对JavaScript的支持也非常出色，这是非常重要的。例如，让CloudFormation执行您从未想过的操作的一种方法是编写一个在Lambda函数中实现的AWS::CloudFormation::CustomResource。
另一个很好的例子是将CloudWatch Logs流式传输到ElasticSearch。如果您尝试按下该按钮，您会发现AWS只是为您在Lambda中创建了一个JavaScript函数。
JavaScript在DevOps和AWS中无处不在，如果使用Java、C#甚至Go来做同样的事情，将需要更多的时间。
如果将来需要招聘一个”DevOps工程师”（请不要这样做），而这个人不懂JavaScript，而你的所有代码都是后端和前端都是JavaScript，那么就不要雇佣这样的人。这对你和他们都不合适。
所以，总的来说，JS是一个非常合理的选择作为DevOps内部工具的编程语言。
参考链接
以上是关于JS作为DevOps内部工具的合理选择的解决方案。希望对您有所帮助！