In Part 3, we used Dapr’s state management building block to store and retrieve data without database‑specific SDKs. Now we’ll shift to another core pattern in distributed systems: event‑driven communication. As systems grow, synchronous service‑to‑service calls become brittle. Tight coupling, cascading failures, and deployment coordination all get harder. Event‑driven architectures help but they often introduce new complexity: broker‑specific SDKs, consumer groups, retry logic, and environment‑specific configuration.

In Part 2, we got Dapr running locally and saw how the sidecar fits into a normal development workflow. Now we can start using Dapr for real work and state management is usually the first building block teams adopt. State is one of the earliest places where infrastructure concerns leak into application code. Even simple services end up tightly coupled to a specific database client, connection logic, retry behavior, and environment‑specific configuration.

In Part 1, we explored what Dapr is and why it exists. Now it’s time to make it real. Before you can use state management, pub/sub, or any other building block, you need a smooth local development workflow, one that feels natural, fast, and familiar. Dapr is often associated with Kubernetes and cloud deployments, but most development happens on a laptop.

Distributed systems are powerful, but they come with a familiar cost: every service ends up carrying a surprising amount of infrastructure code. Database clients, message broker SDKs, storage SDKs, retry logic, connection handling, secrets, configuration, observability, the list grows quickly. Most teams don’t notice this at first. It feels normal.But over time, the weight becomes obvious: Every service looks different…

By this point in the series, you now have a fully working, multi‑environment observability pipeline, deployed and reconciled entirely through GitOps: Jaeger v2 running on the OpenTelemetry Collector Applications emitting traces automatically via the OpenTelemetry Operator Environment‑scoped Collectors and Instrumentation CRs Argo CD managing everything through ApplicationSets and sync waves This final part focuses on what matters most in real‑world environments: …

In the previous parts of this series, we focused on instrumentation, the OpenTelemetry Operator, and the Collector. Now we shift gears and build the GitOps architecture that will manage everything, platform components, workloads, and environment‑specific configuration in a clean, scalable, production‑ready way. This is where the project becomes a real platform. All manifests, ApplicationSets, and configuration used in this series are available in the companion…

In Part 2, we deployed Jaeger v2 using the OpenTelemetry Collector and exposed the Jaeger UI. Now it’s time to generate real traces without modifying application code or rebuilding container images. This part shows how to use the OpenTelemetry Operator to inject the .NET auto‑instrumentation agent automatically. This approach is fully declarative, GitOps‑friendly, and ideal for platform teams who want consistent instrumentation across many services.

In Part 1, we explored why Jaeger v2, OpenTelemetry, and GitOps form a natural, modern observability stack. Now we get hands‑on. This part walks through deploying Jaeger v2 using the OpenTelemetry …

Modern distributed systems generate a staggering amount of telemetry. Logs, metrics, and traces flow from dozens or hundreds of independently deployed services. Teams want deep visibility without d…

I’ve been diving into the world of MLOps lately, curious about how modern ML pipelines can be made more scalable and maintainable. Machine learning is so much more than just training a model, there…

Introduction Feature flags have revolutionised how teams deploy and test features, allowing controlled rollouts, A/B testing, and quick toggling of functionality. But teams adopting feature flaggin…