This is another segment of my ongoing “Capabilities of the Platform” series. My last blog looked at Multitenancy, the differences between Fully Isolated and Commingled models and the different layers of multitenancy offerings. What isn’t immediately obvious is that architectural multi-tenancy isn’t useful if the newly multi-tenant application isn’t surrounded by multi-tenant aware business and operating support systems (BSS and OSS, respectively). After all, how can we answer seemingly simple questions like “I have a multi-tenant application, but how does a tenant get added to the system so they can use this multi-tenant application?”
This blog is the first in a sub-series that describes the capabilities Apprenda provides surrounding multi-tenant architectures. Our focus, after all, encompasses running and enabling Cloud Applications, which can be SaaS-type (multitenant), webscale (massively scaled), distributed or highly available. My goal is to explain what we’ve already encountered in our dealings with large enterprises, and perhaps explain specifics you may not have thought of, when considering using a PaaS. To begin – let’s talk about getting a tenant added as an account to a multi-tenant application – a process we refer to as tenant Provisioning.
Provisioning a Customer? No Problemo.
Put yourself in the position of a developer or company wanting to offer a cloud service. The majority of interactions taking place with your customer will need to be automated, and one of them is provisioning (or sometimes referred to as on-boarding). Without automation, friction is introduced into your operations model and the cost of both acquiring and servicing customers goes up. In the margin-thin world of cloud services, this is a cardinal sin.
Regarding provisioning, there is a list of things that need to occur in order to allow that new customer to be able to use their app. For example- consider configuration, which is needed to structure the entitlements a specific customer might have. Customer A may be enabled to take actions 1 and 2 because they’ve paid for them, whereas Customer B might have purchased a separate plan, which enables them to take actions 1, 3, 5 and 7.
Different Entitlements of a Customer?
You’ll need to provision resources for each customer enabling them to use your app. Depending on the isolation model employed, there may be things you need to do, or don’t need to do. For example, if you’re using a Commingled Model for deploying the interface, a customer that just got on-boarded doesn’t need to get a new website provisioned for it because it automatically uses one that already exists for the app. We might need to provision database access so that it can securely access data for its app, as it starts to use it, and we might need to provision an entitlement so that it can use the app according to the plan that may have been purchased.
Again- different things need to be done depending on the isolation layer of your app. If your Database Model was chosen as an isolated model, then at some point in time we have to automatically create a database for your customer and do the automatic provisioning of the data records that might be required to run the app. Obviously, we need to configure load balancers to make sure that we can forward the request to the proper location that propagates further down the line (possibly to the database).
My next blog will dive a little further into how we enable different multitenant architectures, specifically by highlighting our Metering API, and explaining how we enable our customers to elegantly define how their app can be consumed, separate from the application’s business logic.