Questions about lightbend's practicality in the new license pricing in variable workload/autoscaling/dynamic fleet environments

Akka Libraries
1

I have some questions for Lightbend devs/managers about the practicality of this pricing plan, particularly in auto scaling environments.

Lets say I have a fleet of X instances each with N cores at steady state running on an auto scalable fleet. Each of those instances run some software that uses Akka as a direct or transitive dependency.

  1. Lets say I have an auto scaling event and increase by Y instances from X due to some unpredictable workload. Would the pricing be for (X + Y) * N cores? Even if the auto scaling event was a temporary spike.
  2. Lets say I have over committed my fleet and wish to remove Z instances from the original X. Would the pricing be ? X * N or (X - Z) * N? I would presume the pricing would still be for the higher of the two but the current language is not clear. Plus is the pricing on the ceiling on all capacity utilization for a calendar year?
  3. How would light bend enforce the pricing in a variable workload environment? There are two obvious problems here
    3.1. A corporation/client of Lightbend could very well try to use Akka truthfully and still get their estimates on how many cores they use wrong, and they would most likely get it wrong entirely for a variable workload system.
    3.2. There is the obvious risk that a corporation will try to under commit their core usage to Lightbend as well (as in Lightbend cant and should not assume good intentions here) and there is no way for Lightbend to refute or assert a claim if say corporation runs something like local akka actors in a proprietary code base.

4, How would the pricing work if it here an android fleet? Would there be per core pricing per device in which an app using akka is installed? That would be higher than the cost of almost all Android phones.

To me the pricing model is ambiguous right now and there are tons of unanswered questions that needs to be clarified in very explicit terms.

2

Hi Khalian.
Thanks for raising your questions.

With most enterprise customers using Lightbend software, we expect that many particular circumstances can arise. There would be no way to reasonably post all the combinations of the usage needs that our customers have, and the posted pricing is a baseline for very simple deployment. A highly elastic system or distributing instances to end-users are great examples of when the baseline pricing doesn’t quite work. In elastic environments, we know usage can fluctuate a lot, which is a concept we encourage. In end-user applications, you may have no way of knowing how many cores your user may have.

In the cases you have presented, we would encourage you to reach out to us with your needs, and we can customize a package that makes sense and is reasonable. We certainly don’t want to be sticklers for the exact core count or introduce complex formulas and tracking for usage.

We have a great sales team that can work through these types of questions with you. You can contact us via this link: Akka - Build Reactive Microservices | Lightbend

3

Hi Jonas,

While I’m sure the Lightbend team worked through many potential licensing models, the per-core model as the basis for a tool that is meant to drive reactive/elastic architectures is clearly, in my opinion, short-sighted. The licensing model should try to embrace the nature of what the platform is meant to enable, not penalize it. I think a “per-core” model will drive most companies away, especially those who are only leveraging Akka HTTP directly, which is probably where most usage comes from. The innovation of Akka is Actors (Cluster) & Streams (with Alpakka connectors), and clearly not the HTTP capability.