3

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.

Aea
  • 133
  • 3

1 Answers1

3

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.

Evgeny Zislis
  • 8,963
  • 5
  • 38
  • 72