search

NimbusAPI / Nimbus

Nimbus is a .NET client library to provide an easy abstraction over common messaging frameworks.
http://nimbusapi.com/
MIT License
113 stars 84 forks source link

Documentation on Applications and Instances #222

Closed johnknoop closed 7 years ago

johnknoop commented 8 years ago

Hi

There isn't a lot in the wiki about applications and instances. How to configure if scaling out your application and so on. Whats the point of application name anyway, apart from tracability?

I would deeply appreciate some reading on the subject.

Cheers

KodrAus commented 8 years ago

The application and instance names are related to how Nimbus generates the names for queues, topics and subscriptions in Service Bus. The application/instance name pair is like a key, and each gets its own input queue, and topic subscriptions.

The application name helps stop collisions on the instance name, which in the samples usually uses the machine name. So that way you could run multiple applications on the same machine without ever having to worry about them interfering with eachothers messages. I'll have to have a dig around and remember how scenarios like competing commands use the application/instance name for queue naming.

The best way to see how the application name impacts which queues/subscriptions your bus listens on is to look through the queues that get generated in Service Bus.

Service Bus itself takes steps to stop multiple message receivers from handling the same exact message, so there isn't much danger in letting multiple unrelated receivers read off the same queue, provided there's some kind of eventual consistency in your application itself.

I hope that helps!

johnknoop commented 8 years ago

Hi

But I've set up two applications with different application names, and they communicate just fine as long as they have the same bus connectionstring. So what is the role of application name in this scenario?

Thanks

uglybugger commented 8 years ago

Hi John,

The application name is used to identify the application (not the instance) that is running. This is useful for (amongst other things) competing event handlers.

Consider the simple rules:

We have a UserSignedUp event and a pair of handlers: one to send an email and one to generate an invoice.

Let's say that email is cheap but invoice raising and PDF generation is expensive. It would be nice to scale out just the invoice generation service, so let's say we do that. If we wire up every invoice generation service to the UserSignedUp event, we're going to generate as many invoices as we have service instances, which would probably irritate our customers.

What we can do instead is handle events via competition, which means that only one instance of any application receives a copy of that event. That's what the application name does - it allows us to say "I am one of possibly many instances of the invoicing service."

Does that make sense?

johnknoop commented 8 years ago

Hi

Thanks for a good answer! I think I get it. If we have five instances of PdfApplication listening for UserSignedUpEvent, and only one instance of EmailApplication, also listening to the same event, then only one instance of PdfApplication will get the event, correct?

johnknoop commented 8 years ago

One thing though... does Azure Service Bus do any kind of load balancing? Or does it just randomly pick one of the five PdfApplication instances? Since two UserSignedUpEvents can be handled in parallel by the same instance of PdfApplication, it would be nice to have the workload distributed evenly across the instances.

uglybugger commented 8 years ago

Hi John,

To follow up: here's a slightly more complete explanation of eventing with Nimbus: http://www.uglybugger.org/software/post/eventing_with_nimbus

With respect to load-balancing: yes, we get that nicely for free. Azure Service Bus doesn't play any part in it other than being a dumb queue in that respect - each node that's participating will pop messages from relevant queues as quickly as possible. If you have a slow server and a fast server, the slow one will simply pop fewer messages than the fast one.

What you might see is one node picking up a bunch of jobs to do and another node not getting anything. In that case it's likely to be that the first node popped a batch of messages (i.e. all of them) from the queue and the second node didn't get any. At low loads, this is pretty much irrelevant - if there's that little load then we're not going to care which node is ticking over at slightly more than idle. At higher loads, the message counts will increase and the load will balance out more fairly. You can tune that behaviour via the batch size and maximum concurrent handler settings but the defaults are generally not unreasonable.

johnknoop commented 8 years ago

Thanks for that!

How is the current state of Nimbus in general? Is it still being developed? I see there have been no new issues posted here since I created this one over a month ago. Is Nimbus being used widely in production purposes, or is it still experimental? I can't see any community around Nimbus. Would it therefore be a bad business decision for us to invest time and effort in going along with Nimbus?

KodrAus commented 8 years ago

We use Nimbus pretty extensively in production for our services. Since it's open source you can own as much or as little of it as you want, but I'm not sure what the long term plans for the project are. There's a branch of Nimbus that uses a more recent version of the Service Bus client https://github.com/rebase42/Anubus and I've been looking at CoreCLR compatibility. That's just waiting on the Service Bus client compatibility.

DamianMac commented 8 years ago

Hi @johnknoop This thread should explain where things are at.... we're back!

sptjohn commented 8 years ago

Cool!

markalanevans commented 8 years ago

@DamianMac So for the "Subscriber" side of the applications, are they simply command line apps /exe's that are running on VM's? Where does the background/subscriber services run? What are they in regards to code on a standard web infrastructure. What about on Azure? Do we use Azure Logic Apps, or are these just exe's that are constantly running. This is the area i'm not really clear on.

DamianMac commented 8 years ago

@markalanevans they can be any process. You might have a web app that subscribes to updates to some shared data store, or a windows service / web job that listens for commands and executes them. Does that make sense ?

markalanevans commented 8 years ago

@DamianMac Conceptually yes, implementation wise i'm still wondering what are the more common approaches.

We are looking for a solution to a few problems:

Currently

We have an existing app, which runs in an Azure Web App and we currently use a few VM's to run schedule jobs which are essentially CLI apps that are executed via the Windows Scheduler.

We feel that this can can be organized a bit better from both an infrastructure and organization perspective. Also we just want to level up our skills ;)

Questions:

(Disclaimer: I have a bunch of questions, but don't feel compelled to answer them, I really appreciate your time and am grateful for whatever you are able to share, i'm sure you are extremely busy. My questions mostly stem from the fact that the web is full of posts and talks about the theory of service buses, but there is very little out there on the actual implementation and usage of them in a full system, particularly Azure)

Knowing that some of these "subscriber services" might run long running process and require a fair amount of system resources and others might just just send emails or make quick API calls to 3rd party services...

  1. Are Azure Web Jobs the best approach to handle these "Worker/Subscriber Services" or perhaps LogicApps or is it as simple as having VM's running a bunch of .net CLI apps that each subscribe to their own event/message?
  2. In your docs you have https://github.com/NimbusAPI/Nimbus/wiki/Publishing-an-Event-on-the-Bus if the app is configured to start the bus and is essentailly just waiting for a kill input. Does the mere fact that the class is defined and used inside of a console app make it work?
  3. nServiceBus has the concept of Host apps which are windows services / console apps is there a Nimbus solution for this?
  4. Internally are Nimbus Handlers polling a queue or are messages actually pushed to them?
  5. Have you seen any solutions for monitoring all these "services" that we would build? For ex: while evaluating service buses in general, we also considered "HangFire" which is the typical background worker system, which has a built in scheduler & UI to monitor all the Jobs. (Easily implemented with a bunch of VM's and Console apps or more likely Azure worker roles.

If you made it this far, thank you ;)

DamianMac commented 8 years ago

Hi @markalanevans

The short answer to most of those questions is WebJobs or windows services with Topshelf. If you want to do them as Azure PaaS then WebJobs are great.

We don't have anything like the nServiceBus Host apps, but I use Topshelf to make windows services really easy. That way you can debug a console app, but install it as a service easily. In fact, running in console mode they "just work" in an Azure web job. So TopShelf is definitely something you should look at.

I have a little sample app I used to demo some of this stuff at a user group last year which you can pick at for ideas. https://github.com/DamianMac/MicroPizza If the app is running (as a service of a continuous webjob) then yes it will listen for requests until the process is terminated. Using Topshelf will give you hooks to manage that cleanly.

For monitoring, Nimbus has an automatic Heartbeat message each service will publish. If you hooked in Serilog and Seq then you can see them coming in, or use the messages to build your own app aware dashboard.

Make sense ?

Happy to chat about it a bit more, maybe we could do a skype call or something ? Interested in hearing about the hurdles in getting up and running.

markalanevans commented 8 years ago

Thanks @DamianMac I really appreciate all your help.

I am going to go through your demo, fill in my mental gaps, then build a small example so I can see it all working. I'm going to attempt it with a WebJob as you suggested. I'll create a list of questions.

Then if you are still available, I would love to jump on a Skype call to hear about how else you use it, talk about hurdles, and also the benefits of TopShelf & the future of Nimbus. ( I went to topshelf-project.com site today and their docs page was not available... Also many of the links on the homepage were dead. so they may be going through system update.)

Sound good?

johnknoop commented 8 years ago

@markalanevans

You should be aware of that the Website in which you host your WebJob needs to be "always on" in order for your solution to work. That means, your Website needs to be in the Standard tier.

An alternative would be to host your "subscriber services" in separate cloud services, giving you the freedom to scale them separately from your Azure Website.

markalanevans commented 8 years ago

Are you familiar w/ Logic Apps. We need to evaluate their use case, but conceptually they could be the right place for something like this.

Thoughts?

On Wed, Jan 13, 2016 at 9:58 AM, johnknoop notifications@github.com wrote:

@markalanevans https://github.com/markalanevans

You should be aware of that the Website in which you host your WebJob needs to be "always on" in order for your solution to work. That means, your Website needs to be in the Standard tier.

An alternative would be to host your "subscriber services" in separate cloud services, giving you the freedom to scale them separately from your Azure Website.

— Reply to this email directly or view it on GitHub https://github.com/NimbusAPI/Nimbus/issues/222#issuecomment-171380129.

Regards,

Mark Evans Cell: 805.340.7390

VP Engineering @ FieldLevel.com

johnknoop commented 8 years ago

I haven't played with those (yet), sorry.