In the last few months we have been working on extending the Kill Bill multi-tenancy feature. As its core, Kill Bill was designed as a multi-tenant system, where each object (account, invoice, etc.) pertains to a specific tenant, and where every API in the system carries over the tenancy information. However, to make it fully practical some pieces were missing and have recently been implemented:
- Ability to upload a per-tenant catalog,
- Ability to upload per-tenant invoice templates, catalog translations,
- Ability to upload a per-tenant overdue rules,
- Ability to upload a per-tenant plugin configurations; for example, a given payment plugin can now have separate configurations per tenant allowing to share that plugin across tenants while ensuring that payments get routed to the right place.
In the presentation that we made on how we are using the system at Groupon, we highlighted two use cases for Kill Bill. The first use case is what we called Subscription As A Service (or SaaS in that context) and what we want to discuss in that post. It is really about leveraging the multi-tenancy feature so that one deployment can host multiple tenants, each of which corresponding to a specific merchant/product/billing model. But what are the use cases for SaaS exactly?
We can think of several use cases:
- In a large company, where there are many different teams, products, etc., we see a lot of opportunities for billing customers using subscriptions and or usage billing model. The traditional approach is to have each team independently solve that problem on its own, ending up with many different solutions, and in many cases ending up with nothing because the Time To Market to implement the solution is too costly (resources, time, $$),
- Another use case, is to become a billing provider by putting Kill Bill in the cloud and assigning a separate tenant for each new customer (and potentially also keeping a special tenant for billing those very customers). This is the very same model that all the cloud billing providers are following, and offers the same advantages (and same drawbacks) for customers to delegate their billing problems to a third party solution. The additional advantage of using Kill Bill, is that if a customer decides after a while that the cloud model does not work anymore (ownership of data, customization of the billing system through plugins, etc.), the migration becomes quite easy to do because the same system can now be deployed in house, and data migration is pretty much equivalent to an SQL export-import,
- Another very interesting use case is the one of creating separate tenants for separate purposes:
- In a production environment, one could create a ‘live’ production tenant and a ‘test’ production tenant that could be configured slightly differently if needed
- In the case of multi-region deployments, a single deployment per region could now host all the regions, each one on its own tenant: for instance in the US, we could have one deployment where the US region is active in one tenant, and where the other regions are passive but ready to be enabled in case of a disaster recovery,
- Finally another use case has to do with testing, where each tenant can have its specificities in complete separation from the other tenants
Now, naturally, our roadmap to make the Subscription As A Service fully complete does not end, and we already have some next steps to do. For instance:
- In the test scenario:
- The ability to move the clock on a per-tenant basis would make a great story
- Providing an easy way to cleanup test tenants
- Providing an easier deployment story is also something we are interested in pursuing
- On the KAUI (Kill Bill Admin UI) side, providing full CRUD per-tenant configuration screens
If you have any thoughts on the topic, please let us know on the Community mailing list.
