I came across your video as there are not a lot of web pages that talk about using Azure Functions to host microservices. You have mentioned that Azure Functions would be your first choice, and I can see why. However you didn't mention the potential high cost. Azure Functions go hand in hand with CosmosDB so that both the code and DB are serverless. CosmosDB can get very expensive if the service is hosting a lot of data.
Cost is shifted for other, services. If I have to pay someone to manage a Kubernetes cluster, the cost of that can significantly outweigh the cost of Functions. Still, Functions are no more expensive than a standard App Service, and Cosmos DB for a region-spanning HA storage system is still the best bang for the buck compared to other storage solutions like Azure SQL or Oracle on VMs. So I would definitely still prefer Functions over any other model hands down.
CQRS/DDD is a pattern. Funcitons provide the code and abstractions you need for your domain models. Use Service Bus with Functions to implement the CQRS Pattern.
@@Atmosera- Appreciate quick response. So, if we take your example of Add/Subtract/Multiply operation and apply CQRS + ES, does workflow be as below? Add Operation : ------------------------- UI --> AzureFunction(Add) --> OperationAddCommand --MediatR--> OperationAddCommandHandler --> Load Aggreate(Suppose its named as 'MathAggregate' and loaded from write DB by applying events) --> MathAggregate.Add(int, int) --> Dispatch Event(NumbersAdded) --> Push it to Azure Service Bus and Persist to write DB --> 1. Azure SignalR retrieves message from SB and in the EventHandler we Persist event information to materialized view for query in Read DB --> SignalR send it to connected cliens(Here UI) --> Display Result Query: Get result from Read DB I have used DDD/CQRS/ES in a containerized application using the above approach and it helped keeping the domain safe from external things. Can we apply same to Azure functions? Is it an overkill? If yes, what should be the best approach for keeping domain safe and loosely coupled from infrastructure.
@@praveenraghuvanshi6489 Probably overkill. Most of the integration and event handling is done declaratively, so it simplifies it. In that case, you get to focus more on the domain than wiring up the brokers. Containers are very manual unless you are using a framework (like Spring) to do some of that stuff for you. Look at these articles: docs.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd dev.to/mariomeyrelles/serverless-event-driven-architecture-on-azure-a-worked-example-part-1-481e