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.