<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Joni Collinge</title>
    <description>The latest articles on DEV Community by Joni Collinge (@joni_collinge_fb2fb5b75f9).</description>
    <link>https://dev.to/joni_collinge_fb2fb5b75f9</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4171441%2F03dd76a8-423b-424b-b86f-59522ef5ba2e.png</url>
      <title>DEV Community: Joni Collinge</title>
      <link>https://dev.to/joni_collinge_fb2fb5b75f9</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/joni_collinge_fb2fb5b75f9"/>
    <language>en</language>
    <item>
      <title>Control Plane vs. Data Plane: Who owns what?</title>
      <dc:creator>Joni Collinge</dc:creator>
      <pubDate>Mon, 12 Oct 2026 13:49:46 +0000</pubDate>
      <link>https://dev.to/joni_collinge_fb2fb5b75f9/control-plane-vs-data-plane-who-owns-what-3n2o</link>
      <guid>https://dev.to/joni_collinge_fb2fb5b75f9/control-plane-vs-data-plane-who-owns-what-3n2o</guid>
      <description>&lt;p&gt;A lot of confusion when evaluating cloud platforms comes from the lack of clarity surrounding two terms: &lt;em&gt;control plane&lt;/em&gt; and &lt;em&gt;data plane&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;In reality, the distinction is simple.&lt;/p&gt;

&lt;p&gt;The &lt;strong&gt;data plane&lt;/strong&gt; handles runtime execution: processing your requests, running workflows and agents, and interacting with application state and dependencies.&lt;/p&gt;

&lt;p&gt;The &lt;strong&gt;control plane&lt;/strong&gt; manages the platform: provisioning resources, distributing configuration, managing upgrades and exposing operational controls.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why does this matter?
&lt;/h2&gt;

&lt;p&gt;&lt;strong&gt;“Where does my data go?”&lt;/strong&gt; Understand what the data plane processes, where it runs, what it stores and what crosses the boundary to the vendor.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“What happens when the vendor has an outage?”&lt;/strong&gt; Understand whether the data plane can continue running independently if the control plane becomes unavailable. A management API going down shouldn't necessarily mean your running workflows stop.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“What does BYOC actually mean?”&lt;/strong&gt; It depends on the architecture. Your data plane might run in your cloud account while the vendor operates the control plane remotely. Or you might operate both yourself. Those are materially different deployment models.&lt;/p&gt;

&lt;p&gt;You don't need to understand every detail of a vendor's internals. You need one clear diagram showing both planes, where they run, and what crosses the boundary between them.&lt;/p&gt;

&lt;p&gt;If a vendor can't explain that clearly, it's worth asking why.&lt;/p&gt;

&lt;p&gt;Here's how we've mapped it across all five of Diagrid Catalyst's deployment models: &lt;a href="https://www.diagrid.io/blog/catalyst-deployment-models" rel="noopener noreferrer"&gt;https://www.diagrid.io/blog/catalyst-deployment-models&lt;/a&gt;&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>cloud</category>
      <category>infrastructure</category>
      <category>systemdesign</category>
    </item>
  </channel>
</rss>
