<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Platform Engineering on Wolkwacht</title>
    <link>https://wolkwacht.nl/tags/platform-engineering/</link>
    <description>Recent content in Platform Engineering on Wolkwacht</description>
    <image>
      <title>Wolkwacht</title>
      <url>https://wolkwacht.nl/images/branding/feature-image.png</url>
      <link>https://wolkwacht.nl/images/branding/feature-image.png</link>
    </image>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 31 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://wolkwacht.nl/tags/platform-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Production Readiness for Dapr on AKS: Upgrades, Disaster Recovery, and Lessons Learned</title>
      <link>https://wolkwacht.nl/posts/production-readiness-dapr-on-aks-upgrades-dr-lessons/</link>
      <pubDate>Sat, 31 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://wolkwacht.nl/posts/production-readiness-dapr-on-aks-upgrades-dr-lessons/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;A Dapr platform moving safely through upgrade, GitOps, backup, and regional recovery stages&#34; loading=&#34;lazy&#34; src=&#34;https://wolkwacht.nl/images/2026/dapr-production-readiness-feature.svg&#34;&gt;&lt;/p&gt;
&lt;p&gt;Production readiness starts where most tutorials end. Installing Dapr, deploying sidecars, and proving the building blocks are necessary milestones, but they do not answer the operational questions: How will you upgrade without moving every workload at once? Which state must survive a lost cluster? Can another region actually receive traffic? How quickly can you undo a bad change?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Securing and Scaling Dapr for Production on AKS</title>
      <link>https://wolkwacht.nl/posts/securing-and-scaling-dapr-for-production-on-aks/</link>
      <pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://wolkwacht.nl/posts/securing-and-scaling-dapr-for-production-on-aks/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;Dapr-enabled application pods protected by identity and policy while scaling across AKS nodes&#34; loading=&#34;lazy&#34; src=&#34;https://wolkwacht.nl/images/2026/dapr-security-scaling-feature.svg&#34;&gt;&lt;/p&gt;
&lt;p&gt;A Dapr-enabled application can work perfectly with one replica and still be unprepared for production. The sidecar may have no resource requests, every application may be able to load every component, a rollout may require capacity the cluster does not have, or an autoscaler may react to application CPU while ignoring a throttled &lt;code&gt;daprd&lt;/code&gt; container.&lt;/p&gt;
&lt;p&gt;Production readiness is therefore not one switch. It is a chain of explicit decisions about identity, authorization, isolation, capacity, rollout behaviour, scaling signals, and control-plane availability.&lt;/p&gt;</description>
    </item>
    <item>
      <title>From OrbStack to AKS: Installing Dapr on a Managed Cluster</title>
      <link>https://wolkwacht.nl/posts/from-orbstack-to-aks-installing-dapr-on-a-managed-cluster/</link>
      <pubDate>Sat, 26 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://wolkwacht.nl/posts/from-orbstack-to-aks-installing-dapr-on-a-managed-cluster/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;A Dapr-enabled application moving from a local Kubernetes workstation to a managed AKS cluster&#34; loading=&#34;lazy&#34; src=&#34;https://wolkwacht.nl/images/2026/dapr-orbstack-to-aks-feature.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;Transferring a Dapr-enabled application from local Kubernetes to AKS should be straightforward. The annotations, app ID, application port, sidecar API, and workload manifest stay familiar. The key difference is ownership: a temporary local setup transforms into a shared runtime that requires a version policy, availability plan, network access, identity strategy, and support structure.&lt;/p&gt;
&lt;p&gt;This post moves the sample from &lt;a href=&#34;https://wolkwacht.nl/posts/installing-dapr-on-kubernetes-locally-with-orbstack/&#34;&gt;Installing Dapr on Kubernetes Locally with OrbStack&lt;/a&gt; to an existing AKS cluster. We will compare the open-source installation path with the AKS Dapr extension, install the extension, verify the control plane, and deploy the same NGINX workload.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dapr on Kubernetes and AKS Series</title>
      <link>https://wolkwacht.nl/dapr-on-aks-series/</link>
      <pubDate>Sun, 13 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://wolkwacht.nl/dapr-on-aks-series/</guid>
      <description>&lt;h1 id=&#34;dapr-on-kubernetes-and-aks&#34;&gt;Dapr on Kubernetes and AKS&lt;/h1&gt;
&lt;p&gt;Dapr gives applications a consistent set of APIs for common distributed-systems concerns while leaving the backing infrastructure replaceable. This series starts with the mental model, builds a fast local development loop, moves the same workload to Azure Kubernetes Service, and then works through the building blocks and production concerns.&lt;/p&gt;
&lt;p&gt;The series is written for developers and platform engineers who already know the basics of Kubernetes but are new to Dapr. Each post stands on its own; reading in order gives you the smoothest path from first principles to production.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is Dapr, and Why Run It on Kubernetes?</title>
      <link>https://wolkwacht.nl/posts/what-is-dapr-and-why-run-it-on-kubernetes/</link>
      <pubDate>Sun, 13 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://wolkwacht.nl/posts/what-is-dapr-and-why-run-it-on-kubernetes/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;A cloud-native application and its Dapr sidecar connect to state, messaging, secrets, and services&#34; loading=&#34;lazy&#34; src=&#34;https://wolkwacht.nl/images/2026/dapr-on-aks-part-1-feature.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;Every distributed application gathers various plumbing components. One service requires retries and timeouts, another needs a message broker client, and a third must store some state, retrieve secrets, or discover other services. Over time, each team ends up with a unique set of client libraries, connection handling methods, telemetry, and failure behaviors.&lt;/p&gt;
&lt;p&gt;Dapr, the Distributed Application Runtime, provides a uniform API for the underlying infrastructure. Your application communicates with a local Dapr process via HTTP or gRPC. Dapr then interacts with services, the state store, the broker, the secret store, or other components on your application&amp;rsquo;s behalf. While the application retains control of its business logic, Dapr offers reusable capabilities for building distributed applications.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
