First thing, how many instances of a serverless function do you want? However many Azure wants to create to get the job done? I think this is the default. It's not unlike please Red Alert and having 5000 soldiers - you just send them all in. Screw it. But that's not always realistic, depending on what you're doing. There are constraints on other systems.
Yay for the website_max_dynamic_application_scale_out host.json setting, we can say how many we want. Just two please. No more than six will be fine. Again, it depends on what you're doing. That's step 1.
If you're workign with queues (which are a fantastic way to work with things, really. They're brilliant and I love them. So, if you are, how many do you want to be worked on at once? What do I mean. Yeah. Let's walk through this.
When your queue gets an item, your serverless function says, "About time, I was getting bored. Let me get 16 of them there items.
Yeah. 16 of them and then what does it do? It processes them in the goodness of parellelism! Cause that's the best thing ever. It really is. Until you realize you're hitting something with 16 simultaneous punches!
Which, if your instances ar enot controlled and you're volume of work dictates and calls for it, you can literally be running hundredes or thousands of hits against a database or an API or whatever else.
That's brutal.
But we can tell serverless function: "yo, my brotha, let's take it easy, take our time and only do 8 at a time."
2 instances, 8 queued items - up to 16 at any given time, again, depending on your work load. Azure decides if you need another instance or if you're OK.
This is really noice. And I like it much more than trying to do that fan-out/fan-in thing with the orchestrator. I'm sure someone has it working great and it solves a real issue. But the two scenarios I have for it continue to give headaches. Serious PITA.
This works out real nice if you don't require a fixed end point. In otherwords, you have 1000 items that need to be done indepedent of each other. Great, get it done. See you tomorrow. But if you need to know when the last one has finished to do something else, that's a bit trickier and where Function orchestration helps out.
A couple things come to mind. If you know that you only use this queue for this one thing, a peek of items in it or in a poison queue can tell you if you're done. I'm not sure how that would work.
Perhaps, you can check way later, when you now you should be done. If it's not time sensitive.
Azure queues does not guarantee FIFO, LIFO or any other ordering, so you can't just drop an item in and wait to see it at the end. But you can add an item and change it's visibility time. Again, you'd run into that whole timing thing, errors that add items back in, so on and so forth.