License model issues

Architecture & Design
1

I’m trying to wrap my head around the pricing of NServicebus for our application style. I’ll try to stay abstract and short, I hope the problem is understandable.

I’m designing an application that consist of a large number of microservices implementing a very specific task. Could be as simple as combining a few message properties and then move it to the next service. Such services would be dynamically brought up and down based on need. Basically any customer can turn any “flowchart” they have by designer in a “network of related activities”

For those that know it, it’s basically an equivalent of Microsoft SQL integration services where every functional block is a microservice that would be using nservicebus for handling messages.

This network can have a lot of data flowing through it. And customer could change the flows and rules and then reprocess the data flowing through the network. This means we have a lot of messages through the system. But unlike a “productorder” these data messages have no intrinsic value. Therefore we cannot distribute the cost of message throughput to the customer this way.

For a crude example. A customer could process the results of a survey. The answers to the survey are the input message. The message flows through the system based on rules that give value to answers a result is reaches and processing is done. a survey that is answered 20 times (without nservicebus) has the same price as one that is answered 20.000 times or 2.000.000. With cheap hardware and dynamic scaling this works well. However with nservicebus there would be a LARGE price difference. And what if the customer changes the rules of processing and then reprocessed the survey. Resource wise (cpu ram etc) this is all very cheap. But nservice bus would make it expensive since the price is based on endpoints and even worse throughput.

One could put multiple handlers in a single endpoint. But that would defeat the purpose of the network, distribution of load, failsafes, redundancy, fast updates, with minimal impact etc. And most importantly the dynamic routing of messages.

We have no clue in advance what the exact throughput or endpoint count of the system is going to be. An active customer could make the entire system uneconomical just because of nservicebus. From the pricing calculator 20 endpoint with a million messages a day would cost us 13.000 a year extra. And that might just be one customer. The other cost would be a mere fraction of that.

So with this pricing model, It seems I have to build something like nservicebus myself. Or find another lib to do the work. Is that correct or am I misunderstanding the pricing model?

1 Like
2

Hello!

Not sure exactly what you’re trying to build, but it seems to sound a little bit like Zapier in a way, so I’ll use that as a point of comparison.

I can’t see how any customer activity would result in new code being deployed in brand new endpoints. So the number of endpoints you have is going to remain fairly stable with whatever functionality is available in the system. To compare to Zapier, all “send an email” type functionality could be in an Email endpoint. Adding 1000 new customers would affect total throughput, but not the number of endpoints. You could scale out that Email endpoint to handle all the load and there are no additional licensing implications for number of endpoints, just throughput. Or coming from a different angle, if you have 20 endpoints and add a new customer, you don’t suddenly have 40 endpoints. There’s an economy of scale.

And would you even have 20 endpoints? It sounds entirely possible you could have a single logical endpoint and a single message type of “DoCustomerConfiguredStuff” that is scaled out to a hundred instances.

Though if I were building Zapier, for example, I could see how it would make sense to carve out endpoints roughly around their concepts of “Apps”. One endpoint for Gmail related actions, one for Dropbox, one for Slack, one for Salesforce, etc. since messages flowing through those endpoints would need specific dependencies in order to do the communication with those services that wouldn’t be required in other endpoints.

How you structure what is in those messages and how they are grouped, however, is of course a design choice.

When you say “Could be as simple as combining a few message properties and then move it to the next service” that doesn’t sound all that efficient. That’s almost like every single method having its own message, which just introduces a ton of latency into a system. Even without the cost of NServiceBus…is that worth it?

Similarly, you say you could put multiple handlers in a single endpoint. Definitely! I commonly recommend grouping message handlers in some way, like by dependencies as I mentioned in the example above, but most importantly by message SLA. You don’t want a message that takes 50ms to process and is expected to complete within a couple seconds stuck in a queue behind a message that takes 45 seconds to process.

There’s a spectrum from “everything in one endpoint” to “every message gets its own endpoint”. The everything in one endpoint side is definitely foolish. The everything in its own endpoint is probably a bit foolish as well, unless the system REALLY requires that sort of isolation. The endpoint is the unit of scalability, so putting every message handler in its own endpoint gives you the ultimate control over the scalability of every message handler. But most customers do not need that. And doing so results in a system that is more complex to manage so you are getting more value from NServiceBus to manage that complexity. That’s why you pay more.

You mention that 20 endpoints with a million messages per day would cost 13,000 … you didn’t use a unit but I’m going to guess Euro. I believe that’s the price for 20 endpoints up to 10 million messages per day. Per day. So the next 9 additional customers just like that wouldn’t cost anything more.

And 1 million messages per day is a lot. That’s ~30 million messages per month. Let’s draw one last comparison to Zapier. The biggest plan they have is 2 million tasks per month, not per day. So if a customer can generate a million messages per day but that work doesn’t have enough business value to justify NServiceBus, then there seems to be a mismatch either in the customer’s expectations of what they’re getting, or in the design that is resulting in a set amount of work with X business value being unnecessarily subdivided into too many discrete units of processing.

3

Hello Thanks for the answer,

Based on a quick look zappier might not be the worst comparison. Though I am not familiar with the product. And I do note, that if the product has value and takes away complexity I am willing to pay “more”, but as I understand the conditions We are still worried about investing in NServicebus and at the end discover it is uneconomical for what we want to do. The license is basically open ended. A fixed price or maximum would be much more reassuring. With shopping systems every message has intrinsic value. With random data processing this is much less the case.

Part of the problem is the definition of endpoint. On the site there is an explanation of the term “logical endpoint”. But it helps me very little. Logical endpoint. Is that a queue? Or is it an NServicebus using application or microservice.

If I build and endpoint for message sending. It could do SMS and Email and whatapss etc. I would think I would make different message types for each of those and thus handlers. And a separate rabbitMQ queue for each message type. So one does not hold up the other. To me that sounds like multiple endpoints, but in your definition it might only be one. I am still not sure and that complicates this discussion.

To extend that. I prefer to give each messaging tech its own application/service and thus most likely an separate endpoint. Why? Because to maintain whatsapp messaging I don’t have to bring down the other messaging options. Even just counting common messaging services that would get me at least 5 endpoints, likely more.

then we get to external input systems. There are at least 10 common ones for us. Our services that collect data from those external systems need to be send commands to do so. So not send only. Again I could combine them in one application that could be configured to an specific external system. And deploy that many times. However, that means if have to update for changes in one external system I have to update all of them. Not just the ones implementing that system. Same goes for output systems we talk to, at least 10, none of them very complex, but all very different. So putting them in one application does not make sense.

Our system is basically going to be and “identity” management system, syncing identity information between many totally different external systems.

Many small nodes, may sound more complex. But every single one is more simple and has a lot less complexity, thus a lot less room for error. And taking one done for upgrade or bug fix does not influence functionality that is not related technologically.

As to message count. The same goes. We “fear” it getting higher and higher thus become a economically limiting factor in the long run.

Lets say we take personnel data from an admin system. 20.000 employees. For every employee we have to get one or more contracts, one or more addresses, one or more email addresses etc. Unfortunately most external systems we talk to are not build to deliver those in bulk (bad design, but not our choice). All these entities have separate processing requirements, thus become separate messages. Even assuming all those entities have only 2 instances. you exceed 100.000 messages fast. And that is a single customer. Many admin systems also lack delta output. So every “import” duplicates this traffic. Yes we could join all data into one large message, but that would mean sacrificing parallel processing options and make the bulk message and its processing more complex.

I agree somewhat that more endpoint and larger message count indicate a more complex system. However this is not a universal rule. Keeping nodes simple and more distinct messagetypes can also lessen complexity. In the end one needs to find a balance. But as I said before the open ended nature of your licensing setup scares us. The application is quite simple at the moment, but it will grow. And we cannot predict exactly how and therefore cannot predict NServiceBus cost. At the moment it seems acceptable, but when messagecount grows, the profit from our application does not scale linear with it. This is not acceptable for the managers. Processing a 100.000 extra messages is peanuts for modern hardware running RabbitMQ. Deciding about having another endpoint should not be an purely economic choice. It should be a technical choice or a maintenance choice. Economics are allowed to play a part in that, but we feel with Nservicebus that part is to unpredictable.

We can keep extending our own work using RabbitMQ. But I feel that this might be re-inventing the wheel. But as it stand on the long term it might be less expensive. And we would not have to worry about increasing messages or having an extra endpoint.

4

To address the confusion on logical endpoint: Logical endpoint = a set of message handlers acting on 1 queue and scaled out to as many instances on as many servers as you want.

That means you could put SMS + Email + WhatsApp or whatever together in the same endpoint, and you wouldn’t have to “bring down WhatsApp” to do maintenance, because you could have it scaled out to 6 servers and only ever bring down 1 of them at a time to update the OS or whatever.

If you’re careful about system versioning, you can even do side-by-side upgrades, updating one endpoint instance at a time to test a portion of the traffic that goes through the updated instance before rolling it out to all instances.

If you want to separate all those services into separate endpoints, then yes, that will cost more. But you don’t have to.

At the moment it seems acceptable, but when messagecount grows, the profit from our application does not scale linear with it.

That sounds like a business problem. I can’t help you with that.

We can keep extending our own work using RabbitMQ. But I feel that this might be re-inventing the wheel. But as it stand on the long term it might be less expensive.

Sure, you can just use RabbitMQ, but more importantly than re-inventing the wheel, you should consider the true cost of doing that. Developers aren’t free. Your time isn’t free. How much development time can you pay for with the 13,000€ you save on NServiceBus licenses?

5

Ok please correct me on this if wrong. But if I bundle those together, yes I could update the OS or whatever. but I could not update the Email functionality or whatever separately from SMS. If Email is offline and it is the next message in the queue, what happens? Is it blocked?
Side by side upgrades sound like an unwelcome complication.

That sounds like a business problem. I can’t help you with that.

That is unfortunate. because business is rather important is it not? No business, no money, no license.

You pointing to an blog post on the advantages of NServicebus does not help. I am already convinced it’s the right product. But I am not the bean counter and with the current licensing scheme and the uncertainties it brings for us I cannot properly answer the bean counters. And they have a point. The application should not be dependent on such an arbitrary measure as throughput which we have trouble predicting accurately,

Developers are not free. Time is not free, but neither is NServiceBus. And for 13.000 Euro? a few weeks worth of time. Double the endpoints that and it becomes more and that is per year. It will never be all NServicebus is. But then again we don’t need all of it. Will it be top notch, absolutely not. But “raw” RabbitMQ is working at the moment and over time we can keep enhancing that. It does not need to implement for thousand of scenarios, just ours. Or try mass-transit or dapr or who knows what.

Really, I was very happy and have been happily promoting NServicebus over here. But the response to a valid issue (at least in my mind). has been in my opinion, almost insulting. I get that you want to get payed for your work, so do I. But I very much get an “our way or the highway” vibe and that is not appreciated.

Seems to me, I just have to find something else.

6

It seems my comments have rubbed you the wrong way. I apologize for that. But ultimately, I do not have the authority to change the pricing model, so it is what it is. It’s built to be a consumption model, the same as many of the services in Azure, for example. If it doesn’t provide a positive ROI for you to use it, then we understand that you have to find something else.

Ok please correct me on this if wrong. But if I bundle those together, yes I could update the OS or whatever. but I could not update the Email functionality or whatever separately from SMS. If Email is offline and it is the next message in the queue, what happens? Is it blocked? Side by side upgrades sound like an unwelcome complication.

You are correct that if Email and SMS are in the same endpoint, then from a physical deployment perspective, you would need to deploy both at the same time. If you had multiple instances (recommended for uptime & scalability) you could update them all together or phased any way you like. If you have ALL the instances offline then yes, there will be no traffic through that queue for any messages in that queue. But in all my years of designing systems I’ve never found that to be necessary. You will want to design your updates in a forward-compatible manner anyway, because when you update an endpoint you will have in-flight messages sitting in the queue that were generated beforehand. That makes updating one instance at a time really straightforward.

You pointing to an blog post on the advantages of NServicebus does not help. I am already convinced it’s the right product.

You may have missed my point in that blog post. It’s not about the advantages of NServiceBus, it’s the stuff you have to think about building, maintaining, documenting, and supporting yourself if you build it yourself, all of which has a cost. We’ve found that some organizations (especially the “bean counters” you mention) tend to fall into a fallacy of thinking of their developers as “free” until you bring up those points, which obviously skews the comparison.

7

I do not know your exact position in the company. Thus I never expected you to just change the pricing model. Just if there was an “hidden” option to put some fixed pricing down. Something not open ended that the people doing pricing calculation can easily add without me having to say: "Sorry but while designing, researching and developing I cannot give firm numbers on endpoint and message consumption. They don’t like in the “ballpark” numbers, the “ballpark” tends to change at lot. There is competition for the market to product is to serve so price matters a lot. Before NServicebus I had never even seen a library with a consumption based pricing model. Servers or services yes. but not a library.

As to Azure. We do work a lot with azure. And yes it has prices based on consumption for services. But for that same reason we still deploy a lot of stuff in house on our own servers. Especially where consumption is expected to be high. As a company we have always had our own “data center” and have the knowledge to maintain one. And though much has shifted to azure, most environments still are hybrids. Consumption heavy service are just kept in house. Azure ExpressRoute makes that possible
So this new product is also designed to run in house and have flexible underpinnings. If it proves successful it will move into azure. If the azure consumption model proves to expensive we will just keep it on premise. Hardware is “cheap” is a lousy development policy (in my opinion), but it is how the world seems to act right now.

You may have missed my point in that blog post.

No I didn’t :slight_smile: But like you can’t change the licensing model, I cannot easily change the bean counters. Far to often I get the question, can you make it work simpler and cheaper. The answer is always yes and the caveats don’t concern them until they actually materialize. Is it smart? No. but it’s a fact of life here. Looking into possible futures is not something they do.

I do thank you for answering and explaining your position. We will evaluate.