When the new transport was designed, there were various considerations in favour of or against each feature that was created in the legacy ASB transport. Each decision was not taken lightly and we’ve worked with the updated Microsoft Service Bus team guidelines to better position the transport.
You’ve made some analysis and concluded that the biggest issue is de-duplication. It’s not the biggest issue, far from that. There are more interesting scenarios when it comes to re-inventing the wheel and solving the problem the Premium tier has solved. Let me try and list a few.
The article you’ve pointed to was not re-written when the Premium tier was introduced. It was updated with the Premium tier part, leaving the Standard tier as-is. I don’t know if that was intentional or just overlooked, but not mentioning that would be omitting the fact that Microsoft itself has been saying for quite a while now use Premium tier for production. Standard tier is intended for testing, QA, or light production that can accept the drawbacks of the tier (throttling, decreased performance, latency, etc).
When it comes to HA, the Standard tier didn’t offer any. The recommendation that you find in the document refers to the days when workloads could only be executed in that tier. It’s more of a workaround than a solution. Here’s why.
Assume your endpoint is running with
SendsAtomicWithReceive transport transaction mode. We’ve received a message and lost the connection just before dispatching an outgoing message from the processing handler. We can’t send the message to another (fail-over) namespace. If we do, we violate the transactional guarantee. This is what happened with the legacy ASB transport and customers didn’t even know it was happening. And then we fail to complete the incoming message. Meaning we’ll repeat the processing and send a duplicate when the failing namespace becomes active.
Regarding de-duplication - we can’t do that either. Not without having some additional persistence mechanism. Or using the Outbox feature which is not always possible (in case you’re using the Azure Storage Persistence).
Premium is too much
You’re correct. I also think that the way the Premium tier is marketed leaves a certain segment of customers left with no option but to use the Standard tier. Does that mean Particular should build it? Or rather provide feedback to Microsoft to allow something in the middle? Not as expensive as the Premium, but not as feature stripped as Standard when it comes to premium features.
At the same time, we don’t want to compete with the broker. The broker can implement features we won’t be able to compete with. And frankly shouldn’t. E.g. cross-namespace forwarding or Geo-DR with a data plane.
We’re listening to the customers and carefully considering feature requests. Features added are going through a rigorous cost and benefits analysis before approved. Multi-namespace support is no exception.