5 ms·

“Data plane” and “control plane” aren’t terms I’ve seen before, and I’m having trouble understanding what they are, even after reading the post. Can you explai

by ed 4y ago

“Data plane” and “control plane” aren’t terms I’ve seen before, and I’m having trouble understanding what they are, even after reading the post. Can you explain them in a more concrete, conversational way? Does this service let me e.g. take any docker image and turn it into a SaaS, handling user accounts and billing etc?

beberlei 4y ago
I understood a data plane is for example the MySQL/pgsql/redis servers of all customers of your db as service
infra_dev 4y ago
Hey ed, this is Ram, the author of the post. In the context of Infrastructure SaaS, a data plane is the system that is the infrastructure that you provide as service. For example, let us say you are building a company that provides Postgres as a service. In this case, Postgres is your data plane. Typically, your users will want the Postgres to be deployed in a specific region or cloud provider.They would run queries against the Postgres cluster. Control plane is the central lifecycle management system that helps provide all the SaaS experience for your Infra SaaS application, manages the metadata for your application and also pushes this information to all the data planes. Example of lifecycle management operations could be creating an user, a new organization, provisioning your data plane in a specific region, deleting a cluster etc. The data plane is your product that you want to sell to your customers and control plane is the central system that helps you to make your product work in a self serve way with your customers. This example can also be mapped to internal use cases. Many companies manage their own infrastructure internally and end up having to build a central control plane to manage all the different infrastructure that they provide as a service to their developers. Hope this helps.
arccy 4y ago
think old school ftp ports, 1 for data (your actual files being transferred) 1 for control (out of band messaging).
squarecog 4y ago
These terms usually show up in the context of networking protocols. Cloudflare has a very quick explainer: https://www.cloudflare.com/learning/network-layer/what-is-the-control-plane/ https://www.cloudflare.com/learning/network-layer/what-is-th.... To make it even shorter: a control plane is where all the coordination that controls activity (data) happens. The data plane is where the data actually moves around. Explainers seem to not cover _why_ you would want to separate these "planes". There are several reasons, and I'm no authority, but for starters: * control messages will have different expectations around them: their amount and frequency, delivery guarantees, urgency with which they are processed. Treating this traffic separately means you can engineer appropriately for data and control traffic. * last thing you want is the control message "stop processing traffic from IP x.x.x.x port y" to be stuck behind traffic from said IP/port... In this context, the meaning is somewhat different. They are referring to administrative traffic vs "actual work" traffic. Auth, billing/accounting, configuration updates, that sort of thing. If you are running a SaaS, and your customer is very security conscious and wants none of their precious data to ever leave their VPC, you have 2 options: deploy your software into their VPC completely, making it hard to do a variety of things like upgrades, and increasing complexity; or you can separate control actions from your "worker nodes" and storage, and only deploy the latter into the VPC. You can then work on your control panels, monitor usage, continuously evolve various admin panels and config options, etc, using normal SaaS approaches while the security conscious customer knows that their core data is not leaving their virtual walls and only "bob ran a thing and stored results" goes to the vendor. This post is about abstracting out common bits of how one implements that, and allowing SaaS offerings to provide that sort of separation easier.
- ed 4y ago
  Awesome explanation, thanks! (Particularly "last thing you want is the control message "stop processing traffic from IP x.x.x.x port y" to be stuck behind traffic from said IP/port..")
  - squarecog 4y ago
    I should've added, there's an obvious example for the "SaaS control plane" separation, which is equivalent: "stop processing job X that is destabilizing the cluster" should be processed without needing to fight for resources with job X. Same for ACL changes, user deactivations, etc etc. It's generally a good idea to have your control stuff not be subject to whatever instabilities you might be controlling against.
fragmede 4y ago
Data plane is the data, what you traditionally think of a service's inputs and outputs. Eg, a database server gets queries and returns rows/results. That's data plane. But when a system becomes large enough, the management stuff adds up to be notable in and of itself. Pretend we're a SaaS company offering a database as a service. Adding and removing users, and the setting of passwords is control plane stuff. In a sufficiently web scale system, adding and removing users becomes, not just its own microservice, but a collection of microservices to authenticate and send updates to the main product database, and have its own separate database.
icedchai 4y ago
In the old days, we'd call this the "app" and the "management" (or "admin", or "provisioning") interface. The app is the application(s) providing the actual service your SaaS offers, the management interface manages/configures the app, handles migrations, updates, etc. Example: Maybe your app needs a separate DB per tenant. Your management thing handles spinning that up, etc.

by ed 4y ago

beberlei 4y ago

I understood a data plane is for example the MySQL/pgsql/redis servers of all customers of your db as service

infra_dev 4y ago

Hey ed, this is Ram, the author of the post. In the context of Infrastructure SaaS, a data plane is the system that is the infrastructure that you provide as service. For example, let us say you are building a company that provides Postgres as a service. In this case, Postgres is your data plane. Typically, your users will want the Postgres to be deployed in a specific region or cloud provider.They would run queries against the Postgres cluster. Control plane is the central lifecycle management system that helps provide all the SaaS experience for your Infra SaaS application, manages the metadata for your application and also pushes this information to all the data planes. Example of lifecycle management operations could be creating an user, a new organization, provisioning your data plane in a specific region, deleting a cluster etc. The data plane is your product that you want to sell to your customers and control plane is the central system that helps you to make your product work in a self serve way with your customers. This example can also be mapped to internal use cases. Many companies manage their own infrastructure internally and end up having to build a central control plane to manage all the different infrastructure that they provide as a service to their developers. Hope this helps.

arccy 4y ago

think old school ftp ports, 1 for data (your actual files being transferred) 1 for control (out of band messaging).

squarecog 4y ago

These terms usually show up in the context of networking protocols. Cloudflare has a very quick explainer: https://www.cloudflare.com/learning/network-layer/what-is-the-control-plane/ https://www.cloudflare.com/learning/network-layer/what-is-th.... To make it even shorter: a control plane is where all the coordination that controls activity (data) happens. The data plane is where the data actually moves around. Explainers seem to not cover _why_ you would want to separate these "planes". There are several reasons, and I'm no authority, but for starters: * control messages will have different expectations around them: their amount and frequency, delivery guarantees, urgency with which they are processed. Treating this traffic separately means you can engineer appropriately for data and control traffic. * last thing you want is the control message "stop processing traffic from IP x.x.x.x port y" to be stuck behind traffic from said IP/port... In this context, the meaning is somewhat different. They are referring to administrative traffic vs "actual work" traffic. Auth, billing/accounting, configuration updates, that sort of thing. If you are running a SaaS, and your customer is very security conscious and wants none of their precious data to ever leave their VPC, you have 2 options: deploy your software into their VPC completely, making it hard to do a variety of things like upgrades, and increasing complexity; or you can separate control actions from your "worker nodes" and storage, and only deploy the latter into the VPC. You can then work on your control panels, monitor usage, continuously evolve various admin panels and config options, etc, using normal SaaS approaches while the security conscious customer knows that their core data is not leaving their virtual walls and only "bob ran a thing and stored results" goes to the vendor. This post is about abstracting out common bits of how one implements that, and allowing SaaS offerings to provide that sort of separation easier.

ed 4y ago
Awesome explanation, thanks! (Particularly "last thing you want is the control message "stop processing traffic from IP x.x.x.x port y" to be stuck behind traffic from said IP/port..")
- squarecog 4y ago
  I should've added, there's an obvious example for the "SaaS control plane" separation, which is equivalent: "stop processing job X that is destabilizing the cluster" should be processed without needing to fight for resources with job X. Same for ACL changes, user deactivations, etc etc. It's generally a good idea to have your control stuff not be subject to whatever instabilities you might be controlling against.

fragmede 4y ago

Data plane is the data, what you traditionally think of a service's inputs and outputs. Eg, a database server gets queries and returns rows/results. That's data plane. But when a system becomes large enough, the management stuff adds up to be notable in and of itself. Pretend we're a SaaS company offering a database as a service. Adding and removing users, and the setting of passwords is control plane stuff. In a sufficiently web scale system, adding and removing users becomes, not just its own microservice, but a collection of microservices to authenticate and send updates to the main product database, and have its own separate database.

icedchai 4y ago

In the old days, we'd call this the "app" and the "management" (or "admin", or "provisioning") interface. The app is the application(s) providing the actual service your SaaS offers, the management interface manages/configures the app, handles migrations, updates, etc. Example: Maybe your app needs a separate DB per tenant. Your management thing handles spinning that up, etc.