Observability
Chaos engineering without observability is guesswork. You inject a fault, something breaks (or doesn't), and you're left reading error rates and hoping you measured the right thing. When you combine chaos experiments with trace-based and metric-based assertions, each experiment becomes a falsifiable test: "
Testing
Pulumi's core advantage over Terraform is that infrastructure is real code — you can test it with real testing tools. But most Pulumi testing guides stop at mocking: mock the AWS provider, assert outputs, done. That misses the Automation API, which lets you manage Pulumi stacks programmatically — no CLI
Testing
Writing consumer Pact tests is the easy part. Provider verification is where teams run into real friction — database state, authentication middleware, third-party dependencies, and slow test setup all become problems at once. This post covers practical strategies for handling each of these. The Core Challenge: Provider State Every Pact
gRPC
Schema evolution is one of the hardest problems in distributed systems. When a gRPC service and its clients evolve independently — which they always do — a change to a .proto file can silently break production. This guide covers how to test Protocol Buffer schema compatibility before it becomes a production incident.
Testing
Chaos engineering and SLO management seem to be in conflict. SLOs protect reliability commitments. Chaos engineering deliberately breaks things. How do you test resilience without burning your error budget and violating your SLAs? The answer is planning — scoping experiments to stay within budget, baselining before you inject faults, and defining
Testing
Changing a Protobuf schema without breaking consumers is one of the most error-prone tasks in service maintenance. The rules seem simple, but they're easy to violate under deadline pressure. This guide covers which changes are safe, which are breaking, how to test for both, and how to
Testing
Unit tests verify specific behaviors on specific inputs. Property verification asks a different question: does this code satisfy a mathematical property for all inputs in a domain? The gap between these two approaches is the gap between "it worked on what I tested" and "it is correct.
Testing
Property-based tests find bugs that example-based tests miss, but they have different CI requirements: they're statistically driven, they need reproducible failures, and they can be slow if misconfigured. This guide covers CI integration patterns for the major property-based testing frameworks across Python (Hypothesis), JavaScript (fast-
Chaos Engineering
Chaos engineering without measurement is just breaking things. The metrics that matter are: blast radius (how much of your system was affected), MTTR (how long it took to recover), steady-state deviation (how far metrics drifted from baseline during the experiment), and detection time (how long until your monitoring noticed)
Chaos Engineering
Your microservices work in staging. They fall over in production. Chaos engineering is the practice of intentionally injecting failures to find weaknesses before users do. This guide covers two tools — Netflix Chaos Monkey (for instance/pod termination) and LitmusChaos (for Kubernetes-native chaos) — with a focus on meaningful experiments, not
Testing
LitmusChaos is a CNCF project that runs controlled chaos experiments on Kubernetes — pod deletion, CPU stress, network latency, disk fill. It uses CRDs to define experiments declaratively and produces structured results you can evaluate in CI. This post walks through installation, your first experiments, and how to read the results.
Property-Based Testing
PropEr is the open-source property-based testing library for Erlang, directly inspired by Quviq's commercial QuickCheck. It brings full stateful testing, type-based generation, and targeted property-based testing (TPBT) to the Erlang/OTP ecosystem. For Elixir, PropEr integrates with ExUnit via the PropCheck library. Why PropEr