lawnchair

6 ms·

1.
by lawnchair 1mo ago
> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it. I like chocolate I like vanilla
2.
What Bazel taught us about Terraform(stategraph.com)
2 points by lawnchair 5mo ago|0 comments
3.
Terraform's unit of work is too large(stategraph.com)
2 points by lawnchair 7mo ago|0 comments
4.
Show HN: Fast, Static GitHub Pull Requests(github.com)
2 points by lawnchair 8mo ago|1 comments
5.
by lawnchair 10mo ago
I have to say that if an incident becomes so overwhelming that nobody can spare even a moment to communicate with customers, that points to a deeper operational problem. A status page is not something you update only when things are calm. I
6.
by lawnchair 11mo ago
We're still figuring out what balance makes sense between openness and sustainability, and we'd rather take the time to get it right than rush into a license we'll regret later. The goal is for Stategraph to last a long time.
7.
by lawnchair 11mo ago
Definitely agree. Most teams don't choose a language for purely rational reasons, and we're not pretending we did. We like OCaml, it makes us excited to build. We know the language deeply, which means we can reason about performan
8.
We chose OCaml to write Stategraph(stategraph.dev)
163 points by lawnchair 11mo ago|123 comments
9.
by lawnchair 11mo ago
Finding good candidates is easy.
10.
by lawnchair 11mo ago
We already made it. Thanks for the callout.
11.
by lawnchair 11mo ago
Terrateam | Remote (EU/US timezones) | Full-time | OCaml Terrateam builds GitOps automation for Terraform and OpenTofu. We help large engineering teams plan, review, and apply infrastructure changes safely, directly from GitHub and Git
12.
The infrastructure stack is getting faster. Terraform is not(stategraph.dev)
2 points by lawnchair 11mo ago|1 comments
13.
by lawnchair 1y ago
Using another company's funding announcement to shill your own is lame.
14.
by lawnchair 1y ago
Terraform Cloud does not actually solve this. It moves the state into their service and manages locking centrally, but the underlying model is unchanged. It is still one file with a global lock. That is why refresh bottlenecks and contentio
15.
by lawnchair 1y ago
Hi Alex. Great question and definitely something top of mind as we build Stategraph. The short answer is there is always a service layer in front of the database. Users and teams interact with that service, not the database directly. That i
16.
by lawnchair 1y ago
From my experience the problem at scale isn't that Terraform stops being useful. The problem is how state gets managed. Every IaC approach still has to coordinate changes across shared resources and none of them escape that. Other tool
17.
by lawnchair 1y ago
Agreed. One of the frustrating things about using Terraform or OpenTofu is that all the data is sitting there in state but you can't really query or report on it. Making that information accessible is a big part of why we are building
18.
by lawnchair 1y ago
Regular tools (jq, cat, etc.) still work. That ability doesn't go away.
19.
by lawnchair 1y ago
We are already in that space [0] though that's not the focus of this post. Working with teams at scale on orchestration is what pushed us to look deeper at state itself and eventually create this project. 0: https://terratea
20.
by lawnchair 1y ago
You are right that the simplicity of the state file is a strength and we do not want to lose that. One of our goals with Stategraph is to make state just as easy to inspect through both the command line and the UI. Not every Terraform setup
21.
by lawnchair 1y ago
I don't know enough about Pulumi to make a fair comparison on locking granularity. Pulumi's model is pretty different from Terraform/OpenTofu in general and state management is only one part of that. We're focused on opt
22.
by lawnchair 1y ago
The pain really shows up when teams manage large sets of infrastructure in one place with thousands of resources. Even a small change forces a global refresh and a global lock, so you end up waiting on operations that have nothing to do wit
23.
by lawnchair 1y ago
I don't think it fixes it. Atmos makes splitting and managing multiple states easier, but it still splits the graph. It doesn't change the underlying execution model.
24.
by lawnchair 1y ago
Author here. You are right that splitting by microservice reduces overlap. The problem is shared resources never go away such as VPCs IAM or databases so contention shows up there. Splitting state files is the common workaround but that onl
25.
Stategraph: Terraform state as a distributed systems problem(stategraph.dev)
136 points by lawnchair 1y ago|61 comments
26.
Stategraph – Terraform without the state file bottleneck(stategraph.dev)
9 points by lawnchair 1y ago|1 comments
27.
by lawnchair 1y ago
I noticed on your open source page it says: > You can make a build that includes our trademarks to develop System Initiative software itself. You may not publish or share the build, and you may not use that build to run System Initiative
28.
by lawnchair 1y ago
Makes sense. We are still a bit under the radar. Terrateam focuses on Terraform and Tofu automation through GitHub pull requests. No long running agents or syncing YAML. Everything runs in response to pull request, comment, and merge events
29.
by lawnchair 1y ago
Great to see OCaml getting some attention. We wrote our product in OCaml at my startup, Terrateam[0]. It has helped us build and ship a complex system with a very small team. We ended up building a lot in OCaml. Our own build system, a ligh
30.
by lawnchair 1y ago
Terrateam is hiring ;)

More ›