Sid Sijbrandij

🌍 Managing Environments with Terraform — Which approach do you use? When your infra spans dev, qa, demo, prod (and often multiple regions), you need a clear strategy for handling environments. Over the years, We’ve seen 4 common approaches: 1️⃣ Var-files (-var-file=...) ⟶✅ Simple, built-in, no extra tooling ⟶❌ Easy to drift without proper automation ⟶🔎 Best for small projects or POCs 2️⃣ Terraform Workspaces ⟶✅ Native concept, isolate state per environment ⟶❌ Limited flexibility for per-env config, can get messy in CI/CD ⟶🔎 Works if you just need multiple environments from the same code 3️⃣ Terragrunt ⟶✅ DRY config, powerful hierarchical structure, great for multi-account/region setups ⟶❌ Another layer of tooling, some learning curve ⟶🔎 Best for orgs managing large infra with many environments 4️⃣ Terraform Stacks (e.g. within tools like Atlantis, Spacelift, or custom wrappers) ⟶✅ Explicit, declarative grouping of modules/stacks ⟶✅ Clear promotion pipelines (dev → qa → prod) ⟶❌ Requires additional setup or orchestration layer ⟶🔎 Great for GitOps-style infra pipelines ⚖️ Trade-off — Match the tool to the project size: 🟢 Few environments / small footprint → use var-files or workspaces for simplicity and speed. 🟡 Medium complexity (several envs, some regional needs) → workspaces or start introducing Terragrunt. 🔴 Many environments / large-scale, multi-region, multi-account → Terragrunt or Stacks give scalability, governance, and promotion pipelines. 👉 Our take: Choose your Terraform environment strategy by the size and complexity of the project. The more environments, accounts, and regions you add → the more you’ll benefit from Terragrunt or Stacks. 💬 What about you? Which approach do you use — and why? #Terraform #DevOps #Cloud #InfrastructureAsCode #GitOps

4

Wrote a technical deep-dive on how we redesigned GreptimeDB's storage layer for high-cardinality workloads. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 The original primary-key storage format assumes relatively few series with many data points each. The memtable allocates one buffer per series—fine at 10K series, breaks down at 2M+. When you put something like request_id in your primary key, you're creating millions of series. Memory usage explodes, scans degrade toward row-store performance, dedup becomes expensive. 𝗪𝗵𝗮𝘁 𝘄𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝗱 GreptimeDB 1.0 beta introduces "flat format": - Tag columns stored individually in Parquet (enables predicate pushdown on any tag, not just the first) - BulkMemtable replaces per-series buffers with sorted parts - Multi-series merge/dedup path 𝗧𝗿𝗮𝗱𝗲-𝗼𝗳𝗳𝘀 At low cardinality (4K series), flat format shows ~7% write regression with small batches. Larger batches close the gap. At high cardinality (2M series): 87K → 364K rows/s writes. Some queries 8-10× faster. One user had 14M series per flush—writes were unusable with the old format. Flat format resolved it. 𝗖𝗮𝘃𝗲𝗮𝘁𝘀 - Format switch is one-way (primary-key format can't read flat format files) - If you're under a million series, probably not worth migrating Article covers the implementation details—Parquet layout changes, BulkMemtable internals, benchmark methodology. https://lnkd.in/gyvqcfZX #TimeSeries #Database #Observability

4

Shifting API Quality Left: How Developers Actually Adopted Karate Register https://lnkd.in/enMa8WyV (use the following VIP code at checkout: KARATEUSERVIP) to join us in Paris on December 11, 2025, for "Karate: The Future of API Testing", listen to Mark Hughes speak on this topic.   Most teams say they’re “shifting left,” but the reality on the ground often looks very different: bloated regression packs squeezed into a single day, manual testers burning out, and UI suites so flaky that nobody really trusts the results. I’ve lived in those testing cycle first-hand. In this talk, I’ll share how we used Karate to break that pattern and turn API tests into the source of truth for how our systems behave, not just another layer of noise on top of an already creaking testing pyramid.   Drawing on real adoption stories – this session will show how contract and system integration testing in Karate became the source of truth for how our platforms are supposed to behave. You’ll see how we used Karate to harden the test pyramid: pushing more coverage down into fast API layers, cutting reliance on brittle UI flows, and reducing execution time from hours to minutes. We’ll talk about what actually worked in practice: how QA engineers led the change, how we dealt with legacy flakiness, and how we kept the feedback loop tight enough that developers actually paid attention.   By the end, you’ll have a concrete playbook you can use for your own team! You’ll leave with patterns for introducing Karate into an existing regression process, realistic ways to reduce manual regression load without lying to yourself about coverage, and tactics for stopping automation getting stuck debugging the same false negatives every sprint. If you’re already using Karate but feel your test packs, pipelines, or people are close to breaking point, this talk is about how QA can use Karate to shift API quality left – and actually make it stick.

13

1 Comment

Learn how WarpStream is powering Grafana Labs’ new Mimir architecture: decoupled read/write paths, reduced cloud spend, and proven scalability at 7.5 GiB/s throughput. https://lnkd.in/ejyW4K6R

34

Our vCluster insights are going global 🌍 The latest blog post by @Fabian Brundke got released on the CNCF blog and went live yesterday! 🚀 vCluster is not just about virtual clusters — it’s about solving real multi-tenancy challenges in Kubernetes, while keeping governance and developer experience at the core. 👉 Read Fabian’s blog post on CNCF or his deep dive on our website: 🔗 links in the comments We are looking forward to the community's comments 💡 #CloudNative #Kubernetes #vCluster #PlatformEngineering

19

1 Comment

Today we’re announcing Zilla Platform 1.0! Apache Kafka powers real-time systems, but managing access, governance, and usability at scale remains a major challenge. Zilla Platform solves this by making Kafka discoverable, governable, and self-service by design. With 1.0, teams can: - Centrally manage Kafka environments and access - Publish and discover real-time APIs and data products - Enforce team-based governance and subscriptions - Deploy reliably on Kubernetes and Amazon EKS This is a foundational step toward making real-time data truly operational across the enterprise. Learn more: https://lnkd.in/gBX7PTQK #Kafka #RealTime #EventDriven #DataProducts #PlatformEngineering

10

Getting started with IaC tooling shouldn’t require weeks of refactoring. Terramate Stack On-Boarding is designed for day-0 adoption. With a single command, existing Terraform or OpenTofu repositories can be enhanced with stack orchestration, scaffolding, and code generation. Terramate automatically discovers Terraform and OpenTofu backend configurations and initializes stacks accordingly — no restructuring required. We cover the details in our blog post. 👉 Link in comments

2

1 Comment