News for hackers. Stuff that matters.
Re:AWS Copilot by realharo on Wednesday July 15, 2020 @04:23AM (#23842599)
I feel like trying to use a "dumb" declarative config language for everything is part of the problem.

The domain is not simple enough for that, so you end up with all kinds of weird scripts around it all, or other templating/codegen solutions, plus all kinds of ad-hoc conventions that are extremely easy to break and very annoying to navigate.

Having a full blown statically typed language like TypeScript - where things can reference each other strongly (not just by names and other strings), naming conventions can be encoded in functions (or even enforced by types), and structures on every level (even your project-specific ones) have a well-defined and checked schema - would help a lot in my opinion.

Maybe deno could find a use in this niche.

Re:AWS Copilot by scrollaway on Wednesday July 15, 2020 @06:15AM (#23843256)
You're (accidentally, I think?) describing Pulumi in striking detail.

https://www.pulumi.com/

Re:AWS Copilot by realharo on Wednesday July 15, 2020 @07:30AM (#23843738)
Kind of. From a brief look, it looks very framework-y and all-or-nothing (though I could be wrong, they do have a page about gradual adoption at least https://www.pulumi.com/docs/guides/adopting/).

I was picturing something more low level and less opinionated, though I can only guess how such a thing would perform in practice.

Not even necessarily a specific product, just the adoption of workflows that use already existing tools (e.g. the various API client libraries - for AWS, Kubernetes, git, docker registry, etc.) to achieve this. I realize that that could lead to reinventing the wheel, and eventually an in-house framework anyway, but it feels a lot more comfortable to start there, as you can design things closer to your exact needs.

Pulumi definitely looks interesting though.

Re:AWS Copilot by codebeaker on Wednesday July 15, 2020 @06:42AM (#23843430)
It sounds like you're describing HashiCorp's HCL2 and Terraform Configs which are at least a graph.

I find using AWS without Terraform to be nearly impossible.

Re:AWS Copilot by happymellon on Wednesday July 15, 2020 @08:51AM (#23844429)
Terraform, or Troposphere, or cfn-modules/Widdix, or CDK.

Cloudformation as a JSON/YAML vanilla config is just awful, and really exposes the inconsistancies between the different services.

Re:AWS Copilot by akhilcacharya on Wednesday July 15, 2020 @06:45AM (#23843452)
Re:AWS Copilot by londt8 on Wednesday July 15, 2020 @08:18AM (#23844112)
Scripts which generate the config also have their own problems. Check out Dhall, it attempts to solve this.
Re:AWS Copilot by realharo on Wednesday July 15, 2020 @09:06AM (#23844603)
Reminds me a bit of jsonnet (https://jsonnet.org/) which didn't catch on much as far as I can tell.

I see very little practical value in a DSL like this. Using an existing language with an extensive ecosystem and great tooling was half the point of wanting TypeScript in the first place. Most of the "risks" can be handled with just a few eslint rules, tests (e.g. all outputs must satisfy a set of constraints), and code review.

Especially when the moment you need to do more than just generate config files (e.g. fetch some information from an external service, or even write an imperative script for the occasional task), you'd have to switch to a different langauge and all its tooling - where you can't just import the exact same type definitions, etc.

Re:AWS Copilot by huijzer on Wednesday July 15, 2020 @03:43PM (#23850607)
This also sounds like the Nix language (https://nixos.org/).
Re:AWS Copilot by moltar on Wednesday July 15, 2020 @07:47AM (#23843852)
Have you seen aws-cdk or pulumi? Does exactly that with TypeScript to boot :)
Re:AWS Copilot by arvinsim on Wednesday July 15, 2020 @06:43AM (#23843435)
Yep. I prefer to use language files over JSON or YAML files if I can.