Tenant Provisioning
So far, we’ve highlighted the role of onboarding within the control plane. We also looked at how the onboarding process may need to provision and configure application infrastructure as part of the onboarding experience. This raises an important question: should tenant provisioning live within the control plane or the application plane?
Figure 2-10 provides a conceptual view of the two options. On the left, you’ll see the model where tenant provisioning runs within the application plane. In this scenario, all the elements of onboarding (tenant creation, billing configuration, and identity setup) still happen within the scope of the control plane. The provisioning step is triggered and orchestrated by the onboarding service, but runs within the application plane.
Figure 2-10. Placing the tenant provisioning process
The alternate approach is shown on the right side of this diagram. Here, tenant provisioning is executed from within the control plane. This means that the tenant provisioning would execute infrastructure configuration scripts that are applied within the application plane. This puts all the moving parts of onboarding within the control plane.
The tradeoffs, to me, center around the encapsulation and abstraction of the application plane. If you believe the structure and footprint of application infrastructure should be unknown to the control plane, then you’ll favor the model on the left. If you feel strongly that onboarding is already owned by the control plane, you could argue that it’s natural for it to also own the application provisioning process.
My bias here leans toward keeping provisioning closest to the resources that are being described and configured. I’d prefer not to make updates to the control plane based on changes in the architecture of the application plane. The tradeoff here is that the control plane must support a more distributed onboarding experience and rely on messaging between the control and application planes to track the provisioning progress/status. Both models have their merits. The key here is that provisioning should be a standalone part of the onboarding experience. So, if at some point you choose to move it, it would be somewhat encapsulated and could move without significant re-think.
