<p>Definitely. Especially when using AWS services, the <code>aws-sdk</code> for JavaScript is superb.</p>

<p>Writing code using JavaScript in a shop that has both frontend people writing JS in some framework (Angular/React/Vue/...) and backend people using Node.js removes barriers. Just pushing to use JS provides the org. with even more developers who don't have barriers to reading and fixing infrastructure code.</p>

<p>For example, I am quite proficient in using Python, Ruby, Shell, JavaScript (even Perl). But when it comes to fixing or adding something to HashiCorp's tools like Terraform, I just don't have the time to learn Go sufficiently enough - so I don't do it. If a tool like Terraform was written using JavaScript, I would have added my contribution for that missing service a long time ago.</p>

<p>JavaScript support is excellent in AWS Lambda as well, and that is quite a big 
deal. For example, one of the ways to make CloudFormation do things you never thought it could is to write an <code>AWS::CloudFormation::CustomResource</code> implemented in a Lambda function.</p>

<p>Another good example is streaming CloudWatch Logs into ElasticSearch. If you ever try to press that button you discover that AWS just creates a JavaScript function for you in Lambda.</p>

<p>JavaScript is everywhere in DevOps and AWS, doing the same thing with Java, or C# or even Go would take much more time.</p>

<p>Should you bring a "DevOps Engineer" in the future (please don't), and that person does not know JavaScript while all your code is the backend and frontend is in JavaScript then simply don't hire such a person. It is a bad fit for both you and them.</p>

CC BY-SA 3.0
2018-01-23T04:55:04.810Z
2018-01-23T04:55:04.810Z
Evgeny Zislis
<p>I'm working on a project to move our current stack from a mix of half-manual, half-undocumented, half-ansible into a solid code-defined architecture on AWS. Our plan is to use AWS CloudFormation heavily and off-load the following tasks to an internal tool:</p>

<ul>
<li>Pipelining (running CFs / scripts in order)</li>
<li>Scripting tasks (that cannot be accomplished through CloudFormation)</li>
<li>Templating (if/as necessary)</li>
<li>Internal Validation</li>
</ul>

<p>This tool would be expected to build our entire environment more or less from scratch (bar a few things which can't be automated). </p>

<p>Our product (at least on the backend) is built entirely in Javascript, and while it isn't my first language of choice I'm leaning towards writing this tool in Javascript. My other option would be Python as I favor that language more. However I see major value in being able to stick with a single language (libraries, tooling, paradigms, etc.) </p>

<ul>
<li>Is JS an acceptable solution for this type of tool? </li>
<li>Would it raise major eyebrows if we were to bring on a DevOps Engineer in the future? </li>
<li>Is it unusual to use JS in the DevOps community?</li>
</ul>

<p>We already leverage JS (via <a href="https://serverless.com/" rel="nofollow noreferrer">https://serverless.com/</a>) for some of our automation.</p>

<amazon-web-services>
Is JS an reasonable choice for a DevOps internal tool (i.e. cloud-formation runner, scripts)?
Aea
# Is JS an reasonable choice for a DevOps internal tool (i.e. cloud-formation runner, scripts)?

(Asked by: username_0 on 2018-01-22)

I'm working on a project to move our current stack from a mix of half-manual, half-undocumented, half-ansible into a solid code-defined architecture on AWS. Our plan is to use AWS CloudFormation heavily and off-load the following tasks to an internal tool:

* Pipelining (running CFs / scripts in order)
* Scripting tasks (that cannot be accomplished through CloudFormation)
* Templating (if/as necessary)
* Internal Validation

This tool would be expected to build our entire environment more or less from scratch (bar a few things which can't be automated).

Our product (at least on the backend) is built entirely in Javascript, and while it isn't my first language of choice I'm leaning towards writing this tool in Javascript. My other option would be Python as I favor that language more. However I see major value in being able to stick with a single language (libraries, tooling, paradigms, etc.)

* Is JS an acceptable solution for this type of tool?
* Would it raise major eyebrows if we were to bring on a DevOps Engineer in the future?
* Is it unusual to use JS in the DevOps community?

We already leverage JS (via <https://serverless.com/>) for some of our automation.

**Tags:** amazon-web-services


---

## 1 answers

### Answer by username_1 on 2018-01-23. Score: 3 | Accepted answer

Definitely. Especially when using AWS services, the `aws-sdk` for JavaScript is superb.

Writing code using JavaScript in a shop that has both frontend people writing JS in some framework (Angular/React/Vue/...) and backend people using Node.js removes barriers. Just pushing to use JS provides the org. with even more developers who don't have barriers to reading and fixing infrastructure code.

For example, I am quite proficient in using Python, Ruby, Shell, JavaScript (even Perl). But when it comes to fixing or adding something to HashiCorp's tools like Terraform, I just don't have the time to learn Go sufficiently enough - so I don't do it. If a tool like Terraform was written using JavaScript, I would have added my contribution for that missing service a long time ago.

JavaScript support is excellent in AWS Lambda as well, and that is quite a big
deal. For example, one of the ways to make CloudFormation do things you never thought it could is to write an `AWS::CloudFormation::CustomResource` implemented in a Lambda function.

Another good example is streaming CloudWatch Logs into ElasticSearch. If you ever try to press that button you discover that AWS just creates a JavaScript function for you in Lambda.

JavaScript is everywhere in DevOps and AWS, doing the same thing with Java, or C# or even Go would take much more time.

Should you bring a "DevOps Engineer" in the future (please don't), and that person does not know JavaScript while all your code is the backend and frontend is in JavaScript then simply don't hire such a person. It is a bad fit for both you and them.


---

