Can We Just Cut to Infrastructure-as-Declarative-Code?
medium.com
medium.com
Twitter thread I had about it a while ago: https://twitter.com/dpc_pw/status/1182022825361625088
This is more or less exactly what we’re working on at Pulumi. Using a language like TypeScript to describe Kubernetes infrastructure provides a nice mix of simple JSON-like resource definition, strong typing, and the ability to use variables, loops, functions, classes, packages, test frameworks, and more from an expressive general purpose programming language. You still have access to the full fidelity of the raw Kubernetes API, but also all the tools you need to apply proper software engineering on top of it.
Anyway - from what you're saying, that's exactly what I'm looking for.
This had to be pointed out; Pulumi's docs repeat the adjective "real", as if its competitors aren't real. "real code", "real package management" [2], "real languages" [3], "real programming model" [4]... Nix and Dhall are quite real, though. So is this an incomplete survey, or are Pulumi's docs unrealistically self-aggrandizing? TBH even just this one paragraph of yours is pretty tough to stomach, as if loops and functions in a configuration language were a novel concept.
[0] https://github.com/xtruder/kubenix
[1] https://github.com/dhall-lang/dhall-kubernetes
[2] https://www.pulumi.com/docs/intro/vs/k8s_yaml_dsls/
Cruise built a more complex DSL on top of it: https://github.com/cruise-automation/isopod
For what it's worth, that's what AWS cdk is. Not for k8s but for AWS CloudFormation yaml templates. https://docs.aws.amazon.com/cdk/latest/guide/home.html
There's a fundamental problem here that I don't believe a (taking Pulumi at face value) better config language solves: you are working with an inherently complex system, and configs are only one part of that complexity.
Doesn't matter if you have 1k+ microservices, a monolith with 1k+ RPC services, or something in between - at that scale, you have accumulated such complexity in the system that configs are just one facet of the problem.
I do think it's an interesting premise (but I wonder if they've thought about the zip bomb problem, which has persisted across many, many new technologies, including yaml - at some level, you want to try to make guarantees about config parsing runtime requirements - cpu, memory, disk). An idea that's bounced around my head before is letting folks define small programs - Java, Python, whatever - to generate configs, and use static analysis to encourage hermeticity/reproducibility/etc (e.g. disallow random, disallow concurrency, no envvar deps).
A similar, but related problem: people very frequently write configs such that you could change settings x, y, z using this one line, often for the sake of comprehensibility/readability. But we have no way of writing tests for this- all you can do is hope whoever does the code review keeps that in mind.
ansible & friends fell well short.
biggest peeve is vscode allows you to programmatically install extensions yet firefox doesn't.
something something nixos but i'd like that for fedora/ubuntu etc.
1) Prolog/constraint logic programming.
2) Macro recording and code/config generation.
Both have their upsides and downside. Our current Unix configuration model isn't designed for transparent event-sourcing style which macro recorders require. Even Windows with its Registry is half-baked at best. A lot of side effects are not deterministic. What happens if you try to implement Excel-style macro recording is that you end up with a lot of broken generated code due to missing knowledge or specific side effects that can't be reliably triggered. This requires an AGI to solve.
On the other hand, using Prolog works for high level, very specific stuff like firewall configs. But just like automated proof solvers such as Coq, Lean, you need a strong "standard library" of working configs and bindings to get started otherwise you will be starting from scratch everytime. This is a weakness that's going to be difficult to overcome. There aren't many companies doing developer tooling and integrations that are successful, HashiCorp and Jetbrains being the exception, not the norm. Docker may be an unicorn on paper but it still struggles to turn a profit.
Both of the above methods can be successful if a major corporation is willing to throw money at it. Otherwise we will be stuck with whatever software FAANG decides to release because the developer tooling industry is quite cruel to smaller players. Flynn, Deis etc. Behind every Heroku lies countless dead startups.
Even is you make infrastrcture coding as simple as SQL DDL, you have still said naught of the specific application's schema/design.
Once you are past a dirt-simple, low-traffic LAMP app, I'd expect all bets are off.
I think the real problem we have with infrastructure is one of evolution, abstractions and leaky abstractions.
First, infrastructure is not a static thing, it changes over time in response to code updates, environmental load (autoscaling), etc. And the details here matter. How should new code be rolled out (blue/green, how fast, what are the quality metrics, etc.). What should happen to the old instances while the new stuff is rolling out? When should they be killed?
What we really need is a good way to declaratively specify what to do, and how the components in that declarative specification should evolve as new stuff is rolled in, load changes, etc. We need a good way to specify the control plane for our infrastructure. adaptjs (adaptjs.org) is our TypeScript-based open source project to provide this. It is still early stage, but I think it is pretty promising.
The second issue is one of abstraction. All these things are complex and often need customization to suit the particular application challenges. Using templates, CDK, Pulumi, or anything else to generate YAML is fine, but as the article points out, you have no insight into how your specification got realized into the low-level infrastructure.
Moreover, you have to care since you need to know the low-level implementation to debug, understand cost, analyze logs, etc. Adapt has some machinery so that you don't always need to understand the low-level implementation for this stuff, but since it is still early, that part of the system needs work before it is ready for prime time.
(edit: typo)
Pulumi and AWS CDK are taking what I think is a better approach: use your favourite general-purpose language to build the declarative infrastructure definition.