Terraform and Ansible often struggle with true cross-provider portability. BigConfig Package bridges this gap, allowing developers to deploy both stateful and stateless applications seamlessly across any hyperscaler, from Oracle Cloud to Hetzner.
Greenspun’s Tenth Rule warns that every complex system eventually reinvents a buggy version of Lisp. From YAML-hell in CI/CD to the “accidental” programming languages of Helm, Terraform and Ansible, the DevOps world is living this prophecy. Discover how shifting from rigid configuration to the power of Clojure and BigConfig can help you escape the trap of ad-hoc infrastructure logic.
BigConfig Package moves beyond the “Kubernetes-only” mindset of Helm by treating infrastructure and software as a single unit. By replacing specialized CLIs with Babashka (Clojure), it eliminates the friction between shell scripts and compiled binaries. This approach allows developers to move seamlessly between a CLI, a REPL for debugging, and a library for deep automation.
Traditional DevOps workflows are often bogged down by the “Edit/Run” loop, requiring developers to constantly switch between editors, directories, and terminal tabs.
BigConfig solves this by leveraging a persistent Clojure REPL to create a unified “Edit/Evaluate” environment.
By orchestrating tools like Terraform through a centralized “workbench map”, BigConfig eliminates context switching and replaces traditional debugging with instant, stateful feedback.
It transforms fragmented operations into a seamless, code-driven flow where infrastructure and development live in a single, interactive workspace.
A control plane acts as an API for provisioning and managing infrastructure. Well-known examples include AWS itself and Kubernetes (K8s).
A common pain point when using infrastructure-as-code (IaC) tools like Terraform (using HCL) and GitOps is the difficulty in transitioning or upgrading to an internal control plane.
Teams that have invested significant time in writing Terraform’s HCL code traditionally face a complete rewrite to build a custom control plane API over their existing infrastructure definitions.
This limitation is no longer the case with BigConfig. We’ve demonstrated that a functional control plane can be created with as little as 200 lines of code, leveraging existing Terraform configurations.
The world of cloud infrastructure often involves interacting with complex APIs. While services like AWS EKS provide robust management for Kubernetes clusters, there might be scenarios where you need a more tailored or localized control plane. This article will guide you through reimplementing the AWS EKS API using a powerful Clojure stack: Pedestal for the API, BigConfig to wrap Terraform and Ansible in a workflow, and Rama for state and jobs.
For anyone working with Infrastructure as Code (IaC), managing configurations and deployments efficiently is key. Engineers are constantly seeking ways to enhance their workflows. Today, we’re diving into a powerful combination: OpenTofu and BigConfig, highlighting a killer feature that makes your build step practically invisible!
As a long-time infrastructure enthusiast, I’ve had my share of dalliances with various tools and workflows. For a good while, Atlantis was my reliable partner in managing Terraform deployments. It brought order to the chaos of collaborative infrastructure-as-code, and for that, I’ll always be grateful.
However, like many relationships, sometimes you just grow apart. And in the rapidly evolving world of DevOps, staying stagnant means falling behind. So, after much deliberation, I’ve decided to move on from Atlantis for my Terraform needs, and I want to share why.
