4 ms·

> Hand-writing YAML. YAML has enough foot-guns that I avoid it as much as possible. Instead, our Kubernetes resource definitions are created from TypeScript wit

> Hand-writing YAML. YAML has enough foot-guns that I avoid it as much as possible. Instead, our Kubernetes resource definitions are created from TypeScript with Pulumi. LOL so, rather than linting YAML, bring in a whole programming language runtime plus third party library, adding yet another vendor lock, having to maintain versions, project compiling, moving away from K8S, adding mental overhead...

p_l 3y ago
Managing structures in programming language is easier than dealing with finicky optional serialization format. I have drastically reduced the amount of errors, mistakes, bugs, plain old wtf-induced hair pulling, by just mandating avoidance of YAML (and Helm) and using Jsonnet. Sure, there was some up-front work to write library code, but afterwards? I had people introduced to JSonnet with example deployment on one day, and shipping production-ready deployment for another app the next day. Something we couldn't get with yaml.
paulgb 3y ago
We use Pulumi for IAC of non-k8s cloud resources too, so it doesn't introduce anything extra. In reality all but the smallest Kubernetes services will want something other than hand-written YAML: Helm-style templating, HCL, etc. TypeScript gives us type safety, and composable type safety. E.g. we have a function that encapsulates our best practices for speccing a deployment, and we get type safety for free across that function call boundary. Can't do that with YAML.
Aurornis 3y ago
Most devops disaster stories I’ve heard lately are the result of endless addition of new tools. People join the company, see a problem, and then add another layer of tooling to address it, introducing new problems in the process. Then they leave the company, new people join, see the problems from that new tooling, add yet another layer of tooling, continuing the cycle. I was talking to someone from a local startup a couple weeks ago who was trying to explain their devops stack. The number of different tools and platforms they were using was in the range of 50 different things, and they were asking for advice about how to integrate yet another thing to solve yet another self-inflicted problem. It was as though they forgot what the goal was and started trying to collect as much experience with as many different tools as they could.
- izietto 3y ago
  Would you believe that there is a company that is using cdk8s to handle its K8S configuration, and that such "infrastructure as code" repo ("infrastructure as code", this is the current hype) counts 76k YAML LoCs and 24k TypeScript LoCs to manage a bunch of Rails apps together with their related services? Like, some of such apps have less LoC.
bananapub 3y ago
yaml is objectively a bad language for complicated configurations, and once you add string formatting on top of it, you now have a complicated and shitty system, yay. hopefully jsonnet or that apple thing will get more traction and popularlity.

p_l 3y ago

Managing structures in programming language is easier than dealing with finicky optional serialization format. I have drastically reduced the amount of errors, mistakes, bugs, plain old wtf-induced hair pulling, by just mandating avoidance of YAML (and Helm) and using Jsonnet. Sure, there was some up-front work to write library code, but afterwards? I had people introduced to JSonnet with example deployment on one day, and shipping production-ready deployment for another app the next day. Something we couldn't get with yaml.

paulgb 3y ago

We use Pulumi for IAC of non-k8s cloud resources too, so it doesn't introduce anything extra. In reality all but the smallest Kubernetes services will want something other than hand-written YAML: Helm-style templating, HCL, etc. TypeScript gives us type safety, and composable type safety. E.g. we have a function that encapsulates our best practices for speccing a deployment, and we get type safety for free across that function call boundary. Can't do that with YAML.

Aurornis 3y ago

Most devops disaster stories I’ve heard lately are the result of endless addition of new tools. People join the company, see a problem, and then add another layer of tooling to address it, introducing new problems in the process. Then they leave the company, new people join, see the problems from that new tooling, add yet another layer of tooling, continuing the cycle. I was talking to someone from a local startup a couple weeks ago who was trying to explain their devops stack. The number of different tools and platforms they were using was in the range of 50 different things, and they were asking for advice about how to integrate yet another thing to solve yet another self-inflicted problem. It was as though they forgot what the goal was and started trying to collect as much experience with as many different tools as they could.

izietto 3y ago
Would you believe that there is a company that is using cdk8s to handle its K8S configuration, and that such "infrastructure as code" repo ("infrastructure as code", this is the current hype) counts 76k YAML LoCs and 24k TypeScript LoCs to manage a bunch of Rails apps together with their related services? Like, some of such apps have less LoC.

bananapub 3y ago

yaml is objectively a bad language for complicated configurations, and once you add string formatting on top of it, you now have a complicated and shitty system, yay. hopefully jsonnet or that apple thing will get more traction and popularlity.