对于DevOps内部工具(即云形成运行程序、脚本)来说，JS是一个合理的选择吗？

Question

我正在进行一个项目，将我们当前的堆栈从半手动、半无文档、半无文档的混合结构转移到AWS上的可靠的代码定义体系结构中。我们的计划是大量使用AWS CloudFormation，并将以下任务卸载到内部工具中：

• 流水线(按顺序运行CFs /脚本)
• 编写脚本任务(不能通过CloudFormation完成)
• 模板(如有必要)
• 内部验证

这个工具可以或多或少地从头开始构建我们的整个环境(除了一些不能被自动化的东西)。

我们的产品(至少在后端)完全是用Javascript构建的，虽然它不是我选择的第一种语言，但我倾向于用Javascript编写这个工具。我的另一个选择是Python，因为我更喜欢这种语言。然而，我认为能够坚持单一语言(库、工具、范例等)是很有价值的。

• 对于这种类型的工具，JS是一个可接受的解决方案吗？
• 如果我们在未来引进一名DevOps工程师，会不会引起很大的争议？
• 在DevOps社区中使用JS是否不寻常？

我们已经利用JS (通过https://serverless.com/)实现了一些自动化。

Answer 1

一定。特别是在使用AWS服务时，JavaScript的JavaScript非常出色。

使用JavaScript编写代码的商店中，有两个前端的人在某个框架内编写JS (角形/反应/Vue/.)后端用户使用Node.js可以消除障碍。仅仅是推动使用JS就提供了这个组织。有更多的开发人员没有阅读和修复基础架构代码的障碍。

例如，我非常精通使用Python、Ruby、JavaScript (甚至Perl)。但当涉及到修改或添加一些东西到HashiCorp的工具，如Terraform，我只是没有足够的时间来学习足够的前进，所以我没有这样做。如果像Terraform这样的工具是使用JavaScript编写的，我很久以前就会为缺少的服务添加我的贡献。

JavaScript支持在AWS中也是非常优秀的，这是一个相当大的问题。例如，让CloudFormation做您从未想过的事情的方法之一是编写一个在Lambda函数中实现的AWS::CloudFormation::CustomResource。

另一个很好的例子是将CloudWatch日志流到ElasticSearch中。如果您尝试按下该按钮，您会发现AWS只是在Lambda中为您创建一个JavaScript函数。

JavaScript在DevOps和AWS中随处可见，使用DevOps或C#甚至Go做同样的事情需要花费更多的时间。

如果你将来带一个"DevOps工程师“(请不要)，而那个人不知道JavaScript，而你所有的代码都是后端，前端在JavaScript中，那么就不要雇佣这样的人了。这对你和他们都不合适。