lawnchair

> 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

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. It is part of the response itself. It is how you keep users informed and maintain trust when everything else is going wrong.

If communication disappears entirely during an outage, the whole operation suffers. And if that is truly how a company handles incidents, then it is not a practice I would want to rely on. Good operations teams build processes that protect both the system and the people using it. Communication is one of those processes.

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.

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 performance and behavior before we run the code. We can onboard new engineers quickly because the type system forces clarity.

The runtime is simple enough that we can predict what it's doing. So yes, part of it is that OCaml feels good to use. But that feeling comes from years of watching it make complex systems simpler to reason about, not harder.

Finding good candidates is easy.

We already made it. Thanks for the callout.

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 GitLab pull/merge requests.

We are looking for a Software Engineer who can move between backend systems, infrastructure, and open source tooling. You'll work on Terrateam's OCaml core, support customers, and contribute to the design of next-generation Terraform orchestration.

You might be a good fit if you:

- Care about correctness and reliability in complex systems

- Have experience with infrastructure automation, CI/CD, or compilers

- Enjoy working in OCaml or another strongly typed functional language

- Value autonomy and precision in engineering

Stack: OCaml, Postgres, Docker

Team: small, remote, and technical

Comp: €90k–€130k depending on experience

We are based in Amsterdam and work async across EU and US time zones. Preference for EU timezones.

Apply: https://terrateam.io/careers

Using another company's funding announcement to shill your own is lame.

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 contention show up there too. What we are pointing at is the model itself, not just where the file is hosted. We know this space well from building Terrateam, which competes with Terraform Cloud on orchestration.

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 is where access control and ownership boundaries live.

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 tools just shift the trade offs around. In house systems usually end up rebuilding the same thing in another form.

At scale the choices are pretty simple. You split state and live with orchestration glue. You move to a controller model and take on the operational overhead (see Crossplane). Or you keep a cohesive graph and fix the state layer. Those are the real options (imo). It's not about outgrowing Terraform.

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 this.

Regular tools (jq, cat, etc.) still work. That ability doesn't go away.

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://terrateam.io

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 runs into scaling pain. The trouble tends to show up in larger repos with thousands of resources where teams share big chunks of infra. That is where global locks and full refreshes become a bottleneck and where we think graph semantics help.

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 optimizing the Terraform execution model and making the state layer match the graph semantics it already uses.

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 with your change. Splitting reduces contention but fragments your view of the system. We want state to behave like the dependency graph it already is.

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.

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 only creates new problems like cross state dependencies and orchestration glue. The real issue is the storage model which is a single JSON blob with a global lock. Treating state as a graph with proper concurrency control avoids contention while keeping a cohesive view of infrastructure.

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 software for any other purpose.

That feels a bit different from what many developers expect when they hear "open source." Nothing wrong with that, just pointing it out.

https://www.systeminit.com/open-source

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.

We are also expanding support beyond Terraform and Tofu. That includes Kubernetes, Ansible, and other tools that follow a plan and apply model. If it runs as a CLI with a dry run capability, we can orchestrate it.

On the VCS side, we started with GitHub and are adding support for GitLab and Azure DevOps.

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 lightweight concurrency runtime, and a Postgres driver, because we wanted full control over how everything works.

[0] https://github.com/terrateamio/terrateam

Terrateam is hiring ;)