To Farm or not to Farm That is the Question

I get that question a lot...I think the reason I get that question so much is people are so used to using mid tier products a certain way...But before I get into that let's do the easy case. If you want to bootstrap API clients from a single ip and you want those API clients to be able pub sub reliably across multiple servers then farm.

But what about people that want to use Neuron as services intermediary only so that they don't take a depency on our DLL's? Now it gets more interesting...Why farm? Most of the time I get the "Well how do I do fail over then?"...My answer usually is well how do you do failover for the services sitting behind Neuron?..They usually pause for a second and say "We don't have to we just put a load balancer in front of them and then if one fails we're fine"..I then ask why it works... After a pause they'll usually say "Well there's nothing actually on the server just a service..."

So why use Neuron any differently? Neuron can be a stateless intermediary. For some reason some people have a hard time with that one...They get hung up on durability on the mid-tier...They don't want things lost. They want things "durable"...When they tell me this I ask them what happens when a message leaves Neuron and then hits their service and they lose it...They'll usually tell me something like "Oh we would log it in such and such a place with our enterprise logging framework" or "We would throw an exception and the client would be forced to retry"...

Ok...So why not do the same with Neuron? If you use TCP transport and you're concientius with your pipelines and use either plain old try catch blocks or our spiffy drag and drop try catch blocks and use those libraries that already exist to log anything bad that happens...well it seems to me that you get a powerful pub/sub based intermediary to do transforms and EAI etc. and still maintain an easy to administrate stateless architecure.

Most of the time when people avoid the Neuron API they are using us between two stateless environments like a web tier and their own services and they're using request reply...In most of those cases they put logic in the client to try again if they get an exception...So if you use a durable topic and the server drops then the client is in a mess anyways because it expects a reply..Now say the server comes back up within the period that someone is told on the web "There has been unexpected error...Please try again or contact support"... You will have a message delivered by the mid - tier with a reply to no one and you will have the same message delivered again when the user tries again...I can think of cases where that would be bad..especially if the end points are not designed to detect duplication..

Can that scenario theoretically happen in a stateless architecure? Does farm mode enable service connector failover? Sure...Are those game changers to me? Nope. I always go for simple first and to me having servers that are completely unaware of each others existence and don't require yet another shared database and sharing an esb config are simple.

Once again though if you've seen the light and are using our cool API to be productive then farm it all day!