Understanding Kill Bill

[Bill Killer]

Dear billers!

I have been asked to evaluate Kill Bill & have done some looking
into it. Thanks for your work and documentation!

I have following questions:

1) Is there a good way to address the scenario where the
subscription includes a product with a multiplier? Say
N=1000 (like 1000 products, identical) in a subscription.
The multiplier will not remain completely fixed however --
say during one billing period all those 1000 products
are active, but during another billing period some of them
are not, e.g. 966 products in subscription are active. Also
multiplier could be increased, when customer gets more
products inside the subscription. Each product from the N
would need to have separate usage metering (usage records),
but the plans would be the same for all N products.

Is such modelling possible with directly, or which of
custom rule set, custom fields, or custom plugins would it
involve?

2) What is the point of "standalone" products in KB? They are
rarely mentioned in the documentation and there seems to be
only one sample of their usage in the catalog. By schema,
they also seem to allow the definition of <available>
<addonProduct> elements (at least catalog loader does not
complain), but via Catalog API such products are never
reported as having any addons, nor can they be added in KAUI.

3) Is it possible for "usage" value reporting to add something
else than number of "units" consumed -- e.g. the time period of
actual consumption -- so that KB would register the consumption
to the billing period by actual consumption time (if that
billing period is still not closed) or to the ongoing billing
period (if billing period for consumption time is already closed),
by the "usage" reception time.

I also made following notes -- I am certain developers there is
awareness of those, but thought they were worth mentioning for
conveying sense of outsider perspective.

Notes:

a) The javadocs of the Kill Bill project are weak or non-existant.
Big APIs like this can greatly ease the learning curve, if
IDE quick documentation dialogs provide good information. This
is completely separate dimension from other Kill Bill docs.

b) The dependencies of many Kill Bill components tend to be
very outdated. To quantify - an inside look to killbill-catalog,
version 18.21-SNAPSHOT, which at the time of looking was identical
to release v18.20.

In those dependencies, OWASP dependency-check plugin finds some
rather unpleasant CVE-s (@attachment
'dependency-check-report.html').
Two last reported suspicions are false positives according to CPE.

To just see how far along some dependency versions have progressed,
the following Maven goal can be helpful:

mvn versions:display-dependency-updates

c) The default platforms used are very old -- inside killbill-cloud
the KPM downloads and starts serving via Tomcat 7.0.42 which was
released in the July of 2013.

Thanks,
Bill Killer

[Pierre-Alexandre Meyer]

On Fri, Jun 8, 2018 at 1:37 AM, Bill Killer <billk...@timedrops.us> wrote:

 1) Is there a good way to address the scenario where the
    subscription includes a product with a multiplier? Say
    N=1000 (like 1000 products, identical) in a subscription.

Could you simply create N subscriptions (each one having its own usage records)? If N ~1000, you might want to load test your deployment (especially the invoice generation part).

 2) What is the point of "standalone" products in KB? They are
    rarely mentioned in the documentation and there seems to be
    only one sample of their usage in the catalog.

We introduced STANDALONE subscriptions to allow for multiple subscriptions of the same kind in the same bundle (as opposed to one BASE with multiple ADD_ON). This feature is quite advanced though: unless you have a specific scenario in mind, better to stay away.

 3) Is it possible for "usage" value reporting to add something
    else than number of "units" consumed -- e.g. the time period of
    actual consumption -- so that KB would register the consumption
    to the billing period by actual consumption time (if that
    billing period is still not closed) or to the ongoing billing
    period (if billing period for consumption time is already closed),
    by the "usage" reception time.

This should be done in a metering system instead, outside of Kill Bill (see http://docs.killbill.io/latest/consumable_in_arrear.html#_usage_and_metering). 

  a) The javadocs of the Kill Bill project are weak or non-existant.
     Big APIs like this can greatly ease the learning curve, if
     IDE quick documentation dialogs provide good information. This
     is completely separate dimension from other Kill Bill docs.

We are indeed aware of it - contributions welcome ;-)

 

  b) The dependencies of many Kill Bill components tend to be
     very outdated.

Kill Bill powers *very* large deployments (i.e. processing billions of $ yearly). As such, we need to be very careful about the stability of the system. It is often quite difficult to audit third-party libraries changes, to make sure upgrades don't impact our system. For this reason alone, we don't upgrade for the sake of upgrading.

  c) The default platforms used are very old -- inside killbill-cloud
     the KPM downloads and starts serving via Tomcat 7.0.42 which was
     released in the July of 2013.

The default KPM installation is primarily used for proof of concepts. Actual deployments wouldn't use this (http://docs.killbill.io/0.19/userguide_deployment.html#_deployment_options), they would instead use our Docker images (with potentially a more recent version of Tomcat) or their own in-house container of choice.

Hope that helps,

--

Pierre

[Bill Killer]

Thanks for getting back with the helpful commentary, Pierre!

On 11.06.2018 21:01, Pierre-Alexandre Meyer wrote:
> On Fri, Jun 8, 2018 at 1:37 AM, Bill Killer <billk...@timedrops.us>
> wrote:
>
>> 1) Is there a good way to address the scenario where the
>> subscription includes a product with a multiplier? Say
>> N=1000 (like 1000 products, identical) in a subscription.
>
> Could you simply create N subscriptions (each one having its own usage
> records)? If N ~1000, you might want to load test your deployment
> (especially the invoice generation part).

As the invoice generation time grows linearly with the number of
subscriptions, I am wary about trying with /N/ subscriptions, the
N=1000 is a sample which can go considerably higher (N ~= 50000
has been mentioned).

> We introduced STANDALONE subscriptions to allow for multiple
> subscriptions of the same kind in the same bundle (as opposed to one
> BASE with multiple ADD_ON). This feature is quite advanced though:
> unless you have a specific scenario in mind, better to stay away.

For now, I am indeed going to stay away from STANDALONE, as I do not
see how it would fit well with per-(item|subscription) metering. Which
is of course something I will need to solve if I somehow go for the
'multiplier' for products inside the subscription.

>> 3) Is it possible for "usage" value reporting to add something
>> else than number of "units" consumed -- e.g. the time period of
>> actual consumption -- so that KB would register the consumption
>> to the billing period by actual consumption time (if that
>> billing period is still not closed) or to the ongoing billing
>> period (if billing period for consumption time is already
>> closed),
>> by the "usage" reception time.
>
> This should be done in a metering system instead, outside of Kill Bill
> (see
> http://docs.killbill.io/latest/consumable_in_arrear.html#_usage_and_metering).

Thanks for that link, https://github.com/killbill/killbill-meter-plugin
reference there is of interest to me. However, I did not express myself
clearly, so illustrating with a sample:

* Let BCD be on 10th of each month.
* Metering system sends records in to billing system
* in form (consumption_time, acknowledgement_time,
consumption_unit, consumption_quantity).
* BCD passes and billing system has generated and sent out invoices.
* Records keep coming in which /consumption/ belongs to previous
billing
period. In such case the billing system (which has the
responsibility
to know when the bills are sent out) acknowledges these delayed
records
and adds them to new bill, /but/ with prices that were in effect
during
actual consumption, not at acknowledgment time.

So metering is in place but can receive information with considerable
delay
which billing system should take into account. Does Kill Bill maybe
already
have support for such case?

>> b) The dependencies of many Kill Bill components tend to be
>> very outdated.
>
> Kill Bill powers *very* large deployments (i.e. processing billions of
> $ yearly). As such, we need to be very careful about the stability of
> the system. It is often quite difficult to audit third-party libraries
> changes, to make sure upgrades don't impact our system. For this
> reason alone, we don't upgrade for the sake of upgrading.

Yep, certainly relate to this. However upgrading components with CVEs
on serialization & other issues I would not consider to be just "for
the sake of it", no matter how well isolated the deployment is assumed
to be. But that is certainly something that can be hard sell to end
customers. OTOH these days cybersecurity issues get considerable
attention, so achieving the the hard sell might be worth it both in the
short and long run.

Best regards & thanks again!
Bill Killer

[Pierre-Alexandre Meyer]

On Thu, Jun 14, 2018 at 6:53 AM, Bill Killer <billk...@timedrops.us> wrote:

As the invoice generation time grows linearly with the number of
subscriptions, I am wary about trying with /N/ subscriptions, the
N=1000 is a sample which can go considerably higher (N ~= 50000
has been mentioned).

Indeed - if you have 50k in mind, creating N subscriptions is probably the wrong model, in which case you would need to code that logic outside of Kill Bill. Custom fields could help here maybe.

However, I did not express myself clearly, so illustrating with a sample:

  * Let BCD be on 10th of each month.
  * Metering system sends records in to billing system
    * in form (consumption_time, acknowledgement_time,
      consumption_unit, consumption_quantity).
  * BCD passes and billing system has generated and sent out invoices.
  * Records keep coming in which /consumption/ belongs to previous billing
    period. In such case the billing system (which has the responsibility
    to know when the bills are sent out) acknowledges these delayed records
    and adds them to new bill, /but/ with prices that were in effect during
    actual consumption, not at acknowledgment time.

So metering is in place but can receive information with considerable delay
which billing system should take into account. Does Kill Bill maybe already
have support for such case?

Yes, this is a very common scenario and is already supported. By default, the 2 previous billing periods are caught up (number configurable).