I do not want the definitions of my infrastructure to be Turing complete.
The definitions can be declarative but generated from code
Yoke: Infrastructure as code, but actually
121–130 of 169 posts
Re: Yoke: Infrastructure as code, but actually
#122I feel like the whole distributing webasm binaries thing is tough to swallow. I get the argument, but surely there's a better way, like maybe you could make a tiny interpreter in webasm and distribute that with a human readable script.
Re: Yoke: Infrastructure as code, but actually
#123Re: Yoke: Infrastructure as code, but actually
#124Who are these ops people that want to write golang and rust? It seems like a tiny niche. If you're that comfortable writing golang or rust then why not just become a developer? I'm a lifelong ops person, since 2000, and I use Ansible or Terraform daily. I often wanted to learn golang better but I just never had the motivation. I'm a mean Python scripter, I can write a system integration in hours, but there's somethin…
Being a developer is not necessarily a life-long goal of ops people. I like playing with all the toys in the toybox - sometimes I need to write code to make things play the way I want. I went to school to become a programmer, and discovered that while I enjoyed programming for myself, I hated doing it for others -- otoh, I had been working as an ops guy to pay beer money, and found that it was a lot more aligned with my interests.
Most of these tools though, are written by engineers who don't want to understand the tools they were given, and want to write their own. Even the vaunted pulumi's 'aws-native' package is just built on top of cloud control which is built on top of cloudformation which is often cited as the reason terraform (which pulumi is based on top of) was created: "eww, I don't like that tool".
Which is all to say - people write code because they have a problem - engineering, operational, it doesn't matter. Assuming an ops person wants to become a developer is akin to assuming all developers want to become managers, and that all managers want to become TV stars. The logic presumes a viewpoint that simply isn't true.
Re: Yoke: Infrastructure as code, but actually
#125I think I've commented this elsewhere, but using Cue [1] is also great for this purpose, with no extra infrastructure. E.g. you define a Cue Template [2], which seems analogous to Yoke/ATC's CRDs, and then your definitions just include the data. Here's an example of Vaultwarden running on my K8s cluster: deployment: bitwarden: { spec: { template: { spec: { containers: [{ image: "vaultwarden/server:1.32.7" env: [{ nam…
I really want to dive in with Cue, but one thing that I got burned on when using jsonnet to generate CloudFormation templates years ago was lack of discoverability for newcomers to the repo.
Taking your sample code as an example, someone might look at the myapp deployment definition and ask: “does this deployment get created in the default namespace or does it automatically create a myapp namespace? What’s the default number of replicas? Are there any labels or annotations that get automatically added?” Etc.
On the flip side, there’s potential lack of “greppability.” The user may have found a problem with a deployed resource in, say, the development cluster, and go to grep for some resource-specific string in the repo, only to come up empty because that string is not in the source but rather generated at by the templating system.
To be clear, both of these problems can affect any method of generating config, be it yoke, helm, ksonnet, kustomize, or cue. It’s like a curse of abstraction. The more you make things into nice reusable components, the easier it is for you to build upon, and the harder it is for others to others to jump in and modify.
At least with Cue you get properly typed values and parameter validation built in, which puts it miles ahead of “everything is a string” templating systems like the helm templates the article complains about.
Re: Yoke: Infrastructure as code, but actually
#126I think a majority of the rants about Terraform I read are written from the perspective of someone managing inherently ephemeral infrastructure - things that are easily disposed of and reprovisioned quickly . The author of such a critique is likely managing an application stack on top of an account that someone else has provided them, a platform team maybe. CDK probably works for you in this case. Now, if you belong…
For me Terraform's biggest strength is also its biggest source of pain: it can integrate all sorts of technologies under one relatively vendor-agnostic umbrella and enforce a standard workflow across a huge amount of change. However, that means any bug in any provider is sort of Terraform's fault, if only in the developer's mind.
Having debugged this sort of thing before, it's actually really hard to figure that out.
The entire stack is kind of bad at both logging and having understandable error messages.
You get things like this:
╷
│ Error: googleapi: Error 400: The request has errors, badRequest
│
│ with google_cloudfunctions_function.function,
│ on main.tf line 46, in resource "google_cloudfunctions_function" "function":
│ 46: resource "google_cloudfunctions_function" "function" ¨
In complex setups, this will be deep inside a module inside a module, and as the developer who did not use any google_cloudfunctions_function directly, you're left wondering what the heck is going on.
Re: Yoke: Infrastructure as code, but actually
#127These sorts of posts are fascinating "nerd snipes" to cryptids like me. On the surface, they look incredibly interesting and I want to learn more! Terraform isn't code? Please explain to me why not, you have my attention.
Then I get to the real meat of the issue, which is often along the lines of, "I'm a software developer who has to handle my own infrastructure and I hate it, because infrastructure doesn't behave like software." Which, fair! That is a fair critique! Infrastructure does not behave like software, and that's intentional!
It's almost certainly because I come from the Enterprise Tech world rather than Software Dev world, where the default state of infrastructure is permanent and mutable, forever. Modern devs, who (rightly!) like immutable containers and block storage and build tools to support these deployments by default, just don't get why the Enterprise tech stack is so much more different, and weird, and...crufty compared to their nifty and efficient CI/CD pipeline, just like I cannot fully appreciate the point of such a pipeline when I'm basically deploying bespoke machines for internal teams on the regular because politics dictates customer service over enterprise efficiency. It's the difference between building an assembly line for Corollas and Camrys (DevOps), and building a Rolls-Royce Phantom to spec for a VIP client (BizTech). That's not to say there hasn't been immense pressure to transform the latter into more like the former, and I've been part of some of those buildouts and transitions in my career (with some admittedly excellent benefits - Showback! Tenancy! Lifecycles!), but these gripes about Terraform are admittedly lost on me, because I'll never really encounter them.
And if I did, I don't need to pickup programming to fix it necessarily. I just need to improve my existing system integrations so Ansible runbooks can handle the necessary automation for me.
Re: Yoke: Infrastructure as code, but actually
#128> If you're using a language like Go, you need to have either the Go compiler toolchain installed or prebuild binaries for every permutation of CPU architecture and OS that you want to run your infrastructure on. This doesn't scale well. This is exactly the approach that Terraform takes. Both Terraform and its providers are written in Go, which is a great language for this purpose because of GoReleaser and the ease o…
>Did the author talk to any senior Terraform practicioners before building this?
They clearly did not. Their example of something that's supposedly not possible in Terraform:
"If you really do think that Terraform is code, then go try and make multiple DNS records for each random instance ID based on a dynamic number of instances. Correct me if I'm wrong, but I don't think you can do that in Terraform."
Is something a junior infrastructure engineer can do in about a dozen lines of Terraform code: https://www.perplexity.ai/search/if-you-really-do-think-that... (Taken from another comment here)
If they would have asked anyone that uses Terraform, they would not have written that.
Re: Yoke: Infrastructure as code, but actually
#129These sorts of posts are fascinating "nerd snipes" to cryptids like me. On the surface, they look incredibly interesting and I want to learn more! Terraform isn't code? Please explain to me why not, you have my attention . Then I get to the real meat of the issue, which is often along the lines of, "I'm a software developer who has to handle my own infrastructure and I hate it , because infrastructure doesn't behave…
what sort of cryptid are you?
Re: Yoke: Infrastructure as code, but actually
#130These sorts of posts are fascinating "nerd snipes" to cryptids like me. On the surface, they look incredibly interesting and I want to learn more! Terraform isn't code? Please explain to me why not, you have my attention . Then I get to the real meat of the issue, which is often along the lines of, "I'm a software developer who has to handle my own infrastructure and I hate it , because infrastructure doesn't behave…
what sort of cryptid are you?
As the username implies, the "dinosaur on the internet" kind. The classic trope of the IT person who live(d) in their windowless cave, surrounded by a cacophony of whirling fans and grinding hard drives, retired kit repurposed into a lab since the budget never allowed for a proper one. Graphic tees and blue jeans, an enigmatic mystery to the masses who complain stuff is broken but also that they don't know why I'm here since everything always works.
So just your average IT person, really. What we lack in social graces, we make up for with good humor, excellent media recommendations, and a loved passion for what we create because we like seeing our users smile at their own lives being made easier. I guess the "cryptid" part comes in because I'm actively trying to improve said sociability and round out my flaws, unlike the stereotypical portrayals of the BOFH or IT Crowd.