I've recently started experimenting with Azure functions and I'd like to get some info on whether the following makes sense and is possible..
How feasible is it to build a normal .NET Core Web API following DDD patterns but replacing the API endpoints with durable azure functions? Is this a possible use case for Azure Functions, to make the web API "serverless"?
And how would the whole thing be structured? Does each Azure function need its own project or can they all be placed in one project?
Thanks
As I wrote in comments why not?
You can define bounded context and deploy to one azure function as microservice for instance service which will be responsible for orders, other azure function of delivery and so on.
Use durable function when you need to orchestrate actions, for instance you have buy flow when in first action you lock products, take payments and unlock so you have kind of dependency on each other.
You can use azure functions with service bus or azure queue storage for event processing.
One thing keep in mind that when you design function you have time limitations is up to 5 minutes on provisioning plan. So when you design newsletter for instance keep in mind that you would need to send email in batches.
Related
I have multiple WebApi that are hosted in Azure but some of the API taking a long time to process.
Instead of a calling from the scheduler function in Azure, I was advised to use the Messaging Queue.
Is this a good approach?
Also, let say my API URL.. https://testwebapi.net/api1 and https://testwebapi.net/api2, how can we communicate these API using Message queue and also how to call the WebAPI individually from Messaging Queue?
Is this Azure Bus service is the same as Messaging Queue for Azure.
I would strongly recommend you look at the respective docs on Azure, and start doing some quick tutorials and post more specific questions.
Now, to answer, what I believe is your main question, Azure Bus Service and Messaging Queue.
The thing is, there is no one Messaging Queue, rather three options for Azure messaging - Service Bus, Event Grid, and Event Hubs. Also, there is something called 'Azure Queue Storage', but I dont think you are thinking of that, considering your context.
There is a very cool comparison chart available here - https://learn.microsoft.com/en-us/azure/event-grid/compare-messaging-services
But, I think, my guess, is you are looking for ultimately looking to use Azure Service Bus.
Also, please understand that one does not invalidate the other. As your project develops, you may end up using Azure Service Bus with other options like Event Hubs or Grids or all of them in different places.
Also, you keep using the incorrect terms. for example, you say 'Azure Bus service' but its really 'Azure Service Bus'. Also, there is no thing called 'Messaging Queue for Azure.' as there are so many different messaging services for Azure. This is what I want to add here. Spent some time with the docs and post more specific questions as you continue your project.
I'm migrating extensive SharePoint application to Azure and I'm looking for a recommendation in terms of replacing Timer Jobs with some Azure service. Which one would be most suitable? Azure Functions, Azure Logic Apps? The timer job needs to connect to a web service and make some GET / POST calls. Maybe sending e-mails.
What would you recommend? Any pros / cons?
Thanks,
George
With that additional context, but without a full understanding of the logic you need to implement around the calls, I'd suggest you look into a combination of a Logic App and a Function. The Logic App will make the time trigger and any email jobs more configurable, but the Function will give you more control of your web requests and logic, especially if those are more complex than simply making a request and ensuring it succeeded.
Set up the Logic App on a time trigger, and use it to orchestrate the Function and any email jobs. You can use the Logic App HTTP connector to trigger an HTTP-based Function, or you can look at the Function App connector.
For the Function, write it in C# and reuse your code there. Add any other calls and handling logic you require, then return a response for the Logic App to consume.
Add Control and Email (there are several of these for different email providers) connectors to the Logic App to send out relevant emails per the Function app result.
How does a Azure function differ from a ASP.NET Core Worker Service?
Does both of these cover the same use cases?
How do I decide which one to use?
Update:
Azure function is designed for azure. So when you use azure, or other azure services which are integrated with azure function, you should consider azure function, which could simplify your code and logic by the built-in features of azure function. But it will also have charges for azure function. And yes, if you don't use azure, just use asp.net core worker services.
Azure function are totally different from ASP.NET Core Worker Service.
The benefit of Azure function is that it supports a lot of triggers like azure blob trigger / azure event hub trigger, and is integrated with other azure services.
With these built-in features, it's easy to create a proper azure function to complete a proper task. For example, if you upload an image to azure blob storage, and then want to resize the image, you can easily create a blob trigger azure function with less code.
Worker services are the perfect use case for any background processing. And if you want to operation some azure services like azure blob / azure event hub etc. you may achieve this but need to do a lot of work.
At last, it depends on your use case to choose which one should be used, and select the simple / efficient one.
I think the answer Fred was looking for is, why would someone use Azure functions over Asp.net Core hosted service? And the answer isn't only because you have Azure account so everything is easy and integrated. It depends. I.e Traffic, cost, expertise, etc.
Actually, there are guidelines set by Microsoft when to use an Azure Functions versus let's say over a IHosted service running in a linux container hosted in AKS for example. and I'll post the link, but it's basically if your workload is mission critical or not. If you want the best performance, lowest cost, reliability a hosted dotnet core service running in Linux container would be an excellent alternative.
Here is the mission critical guidelines from Microsoft, hope this helps!
Design recommendations
Azure Functions:
Consider Azure Functions for simple business process scenarios which don't have the same stringent business requirements as business-critical system flows.
Low-critical scenarios can also be hosted as separate containers within AKS to drive consistency, provided affinity and anti-affinity requirements are fully considered when collocating containers on nodes.
Excerpt taken from here:
https://learn.microsoft.com/en-us/azure/architecture/framework/mission-critical/mission-critical-application-platform
Can I achieve Azure function chaining with Durable Functions located in different resource groups & consumption plans?
OR do the functions have to exist in the same resource group/service plan?
If this is not possible, then apart from using service bus, how can functions communicate with each other across different services?
We only support chaining durable functions from within a single function app. This is a technical limitation imposed by the current design of the underlying Azure Storage provider.
However, you could work around this in various ways depending on your needs. For example an orchestration in function app A could send a queue message that triggers a queue-trigger function in function app B which internally starts another orchestration or raises an event to an existing orchestration using the Instance Management APIs.
Durable Function orchestrations also support the async HTTP model, which means that an orchestration in function app A could use HTTP to start an orchestration in function app B, then poll the status endpoint it gets back to get the response when it's available (more info in the HTTP API topic).
But can you comment on why you want to have communication across different function apps? We've received this request before and having more data might help us implement a solution sooner. :)
I just came across a new Azure feature - Azure Scheduler:
http://gauravmantri.com/2013/11/10/windows-azure-scheduler-service-part-i-introduction/
I was wondering - from an architectural perspective - how is this any better or different from using an online CRON service to send a predefined request to a WebAPI endpoint? I'll need a WebAPI endpoint in both cases - with the Azure offering, I have the ability to Enqueue into an Azure Queue, but otherwise it's the same thing, right (maybe with the former being cheaper)?
Two big differences with the scheduler service
Managed and paid for within the same Azure subscription. This does make ops a little easier.
The RESTful API for the service.
As good as it may be, it is expensive compared to other offerings in the market (I use setcronjob). As you point out, you still need to write your job endpoint anyway.