What do you guys think of combining IaC with regular code? One language that does it all?
Rethinking Infrastructure as Code from Scratch
91–100 of 124 posts
Re: Rethinking Infrastructure as Code from Scratch
#92My thoughts have been going into another direction entirely: - We need to get rid of YAML. Not only because it's a horrible file format but also because it lacks proper variables, proper type safety, proper imports, proper anything . To this day, usage & declaration search in YAML-defined infrastructure still often amounts to a repo-wide string search. Why are we putting up with this? - The purely declarative approac…
Without suggesting it solves most (if any) of your complaints, https://yglu.io is significantly less horrible than text templating YAML files like everybody else seems to want to do.
Re: Rethinking Infrastructure as Code from Scratch
#93Any similar solution for self-hosting focus, my own comprehensive data center infrastructure management + cloud? router/switches, load balancer, firewall, CGN, bare metal server, VM, Containers, Application and etc.
Re: Rethinking Infrastructure as Code from Scratch
#94My thoughts have been going into another direction entirely: - We need to get rid of YAML. Not only because it's a horrible file format but also because it lacks proper variables, proper type safety, proper imports, proper anything . To this day, usage & declaration search in YAML-defined infrastructure still often amounts to a repo-wide string search. Why are we putting up with this? - The purely declarative approac…
I was only introduced to terraform a few months ago, but my own takeaway so far closely mirrors yours.
One thing that's sorely needed, especially for beginners, is something like a schema. Something that would provide editors with typical language features, but especially autocomplete. Maybe protobuf would work but I've also heard about some language called Cue that may be worth exploring as well.
I also feel that declarative is the wrong approach. Building infrastructure is inherently imperative and making the build process apparent in the code would go a long way towards readability. I'd love to be able to read through the terraform modules like I'm reading a story about how the system gets built.
Re: Rethinking Infrastructure as Code from Scratch
#95Earlier quoted context omitted.
He's suggesting something closer to Pulumi than a declarative (Cloudformation, Terraform), but with more of an inheritance model to apply blanket attributes to the targeted resources. This is possible with Pulumi but requires a lot of boilerplate and some monkeypatching.
Author here. This is correct. I have used Pulumi and I love CDK. I think the models in Pulumi and CDK are both great, but they tend to be either too low level or too high level. For example Pulumi has a `awsx.ecs.FargateService` class that can deploy a container to AWS Fargate, but the API is limited and you don't really have the capability to remix it into other scenarios. For example you have the capability to atta…
I have deep concerns regarding imperative programming w.r.t infrastructure as code. It's mostly developer-experience related: as a developer I just want to tell AWS/GCP/Azure to "give me three boxes behind a load balancer in two regions". I know it's currently popular to hate YAML (or HCL) but it works and at a glance I can get a feel of what my infrastructure should look like. Therefore IMHO declarative should be the preferred standard for infrastructure.
From an infrastructure management standpoint I completely agree with your take - do exactly this enough times and you get skew, compliance problems, pets instead of cattle. Hence you would want a CDK to facilitate those enterprise needs. Any sort of composability that doesn't break and has sane defaults would be ideal in a CDK. The problem I have with current CDKs is the amount of boilerplate to get this reproducibility, and then on top of that I have to write it in a non-declarative way.
I like where your head is at but I do not think AWSCDK extensions are the answer. I think cdktf and Pulumi are a little bit closer to the right ("my right"!) answer but still have a ways to go.
Re: Rethinking Infrastructure as Code from Scratch
#96The split between parameterized classes and logic sounds a bit like the split between Puppet and Hiera. The idea was probably a good one, but something about the implementation made people go overboard with it.
I feel IaC really peaked around Puppet 3 and Chef 1. IaC should be simple enough that people use it, and trivial to write providers for. People tend to glue much too large libraries to their IaC platforms and end up with a maintenance mess which is what kills it in the long run. However both the above projects went corporate and grew legs and arms and a billion other features that everybody won't use more than a subset of. Most people migrated to Ansible which kept more of the open source project culture and was simpler in design.
Now people seems to use a little of this, a little of that. Some Ansible, some Terraform, some other stuff. They don't know what they're missing when the entire stack is built ground up from templated components defined in a common declarative language. Some people seem to really like Nix, which I haven't used professionally, but from what I've seen it seems to inherit the same type of design. There was an experimental project called cfg which worked in real time using hooks such as inotify which was promising, if there was a Kubernetes distribution made like that it would be really easy to manage components that didn't belong to a host.
Re: Rethinking Infrastructure as Code from Scratch
#97The split between parameterized classes and logic sounds a bit like the split between Puppet and Hiera. The idea was probably a good one, but something about the implementation made people go overboard with it. I feel IaC really peaked around Puppet 3 and Chef 1. IaC should be simple enough that people use it, and trivial to write providers for. People tend to glue much too large libraries to their IaC platforms and…
What ever happened to saltstack?
Re: Rethinking Infrastructure as Code from Scratch
#98There's only so much you can do by building on the current towering abstractions offered by GCP, AWS, etc. One of the main problems is just the slowness of it all.
Dark is a good example of something that sidesteps this stuff by more fine grained integration of infrastructure and app code.
Re: Rethinking Infrastructure as Code from Scratch
#99My thoughts have been going into another direction entirely: - We need to get rid of YAML. Not only because it's a horrible file format but also because it lacks proper variables, proper type safety, proper imports, proper anything . To this day, usage & declaration search in YAML-defined infrastructure still often amounts to a repo-wide string search. Why are we putting up with this? - The purely declarative approac…
I was only introduced to terraform a few months ago, but my own takeaway so far closely mirrors yours. One thing that's sorely needed, especially for beginners, is something like a schema. Something that would provide editors with typical language features, but especially autocomplete. Maybe protobuf would work but I've also heard about some language called Cue that may be worth exploring as well. I also feel that de…
> I've also heard about some language called Cue that may be worth exploring as well.
Yup, I've been wanting to look into Cuelang, too.
Re: Rethinking Infrastructure as Code from Scratch
#100My thoughts have been going into another direction entirely: - We need to get rid of YAML. Not only because it's a horrible file format but also because it lacks proper variables, proper type safety, proper imports, proper anything . To this day, usage & declaration search in YAML-defined infrastructure still often amounts to a repo-wide string search. Why are we putting up with this? - The purely declarative approac…
I have a similar view to yours: as soon as you need variables, imports, functions or any other type of logic ... the existing "data-only" formats break down. Over time people either invent new configuration languages that enable logic (i.e. cue or jsonnet), or they try to bolt-in some limited version of these primitives into their configuration.
My personal take is that at some point you are better of just using a full programming langugage like TypeScript. We created TySON https://github.com/jetpack-io/tyson to experiment with that idea.