Feedback on New Pricing Model

#1

I showed the new licensing model to our architect and the first thing that struck him is that the basic price per endpoint goes up as the number of endpoints increase which is backward to any other volume licensing model he’d ever encountered.

His takeaway was “So Particular are encouraging us to run less endpoints? - Weird”

So just to be clear. Using the calculator on the licensing site.

I’d pay $2737 per year for 10 endpoints or $9125 per year for 20 endpoints.

So by distributing the same load over twice as many servers the cost more than triples

#3

Hi Greg!

The rationale behind the price increasing is that as a system grows it becomes more complex. Meaning that with more logical endpoints, NServiceBus is solving more complexity for the system.

Any metric we use to determine license fees will have an incentive to reduce costs. The previous licensing model incentivized running all endpoints on a single machine in order to reduce the number of “nodes”. It also made it tricky to count nodes in containerized environments without special classes of licenses (elastic, SaaS, etc.) meaning there was a lot of confusion around what license was applicable in what environment.

By measuring the number of logical endpoints, it means that systems can grow slowly and adding new endpoints can be done on an opt-in basis. New functionality can be included as new handlers in existing endpoints or new endpoints. If the new handler is added to an existing endpoint, it is easy to move the new handler to a new endpoint at a later stage - copy the handler and message types to a new assembly. Moving to a new endpoint becomes an explicit decision that can be made for specific reasons (e.g. Needing different recoverability policies, or different way of dealing with priority customers).

Perhaps it is important to note that only LOGICAL endpoints are counted for licensing, not physical endpoints.

For interest, we also considered

  • Number of physical endpoints
  • Number of message types
  • Number of message handlers
  • Message size
  • Number of sagas

All of which incentivize different behaviours which are more negative and harder to evolve than the number of logical endpoints.

In your example, you will not be paying more for distributing the same load over twice as many servers. If you are distributing load, that’s scaling out which means it’s the same logical endpoint. You can distribute your endpoints as many times as you need to for scale or recoverability purposes. From a licensing perspective, it is still only 1 logical endpoint.

#4

Thanks William, I’m not a fan of the change; I’d missed the whole logical vs node part of the license. As an environment where we have a lot of small low throughput endpoints all this has done is made me consider amalgamating them into larger endpoints to reduce the licensing cost. I doubt that was the intent of the change. The other thing that seems off to me is the number of endpoints within a tier of licensing has no bearing on the message quota, So regardless if I pay 18900 USD for 26 endpoints in premium or 73000 USD for 100 endpoints the amount of messages I can process is the same.

#5

Hmm, perhaps we need some more clarity on the licensing page as this isn’t accurate:

With 26 endpoints you are in the Professional tier so your system can process 1 million messages a day.

With 100 endpoints, you are in the Premium tier, which means your system can process 10 million messages a day.

#6

William

Ok I was off by 1 :). 99 endpoints is still professional tier,(1 million messages) so my objections still stands, Paying 3 times the price for the same amount of messages seems wrong.

Cheers
Greg

#7

The tier you fall into isn’t solely determined by the endpoints. If you have 3 endpoints but need 1 million messages a day, you are licensed for those 3 endpoints at the professional tier (so $3.75 a month).

#8

Thanks again William,

I appreciate the zippy replies. Now I have a better understanding it’s time to break out Excel and calculate what this will actually cost us. No doubt we’ll complain to Willie if it’s horrendously different from our current renewal :slight_smile:

Cheers
Greg

#9

That’s what he’s there for :smiley:

#10
  1. separated networks

in many cases we have the same app (or infrastructure endpoint) deployed to multiple physically separated networks. so same code and same queue names. Do all those duplicated queues count for licensing purposes? eg So if we have 2 queues per app and (say) 3 prod environments, does that mean we have 6 endpoints for licensing purposes?

  1. Multi tenant

Many of our apps are multi tenanted. so we have a web + processing queues. but multiple isolated duplicates of those pair of queues. So if we have 2 queues per app and (say) 4 tenants, does that mean we have 8 endpoints for licensing purposes?

#11

The duplicate queues do not count. The same code is deployed multiple times, so only 2 logical endpoints exist.

2 endpoints for licensing purposes.

This is not a strict definition, but as long as the same code is deployed, it is logically the same endpoint. If there is custom code per tenant, then it’s possibly a unique logical endpoint (your account owner will be able to decide in specific cases) but to my mind if it’s only configuration differences per tenant, it’s a single logical endpoint. Obviously there are ways to exploit this to reduce the endpoint count, but as always: we trust our customers are not out to rip us off. In any event, there are easier ways for them to pay less.

#12

@WilliamBZA thanks for the clarification. could that information be added to the licensing FAQ, to make it more discoverable moving forward?

#13

Thanks @Simon_Cropp, we’ve added a couple FAQs based on your feedback.