If you want to decouple your application from your logic, it’s always useful to separate events happening and actual actions.
This technique is also known as Command Query Responsibility Segregation or CQRS for short. The main principle is to allow events to be queued in a messaging service and have a separate mechanism to unload them.
Traditionally, we would do something like this with Rabbit MQ and maybe a command line application that would run on your machine. With modern cloud based applications, we would create an App Service under Azure and have a WebJob handle all those messages.
The main problem with this approach is that your WebJobs scales with your application. If you want to process messages faster, you have to scale up. How unwieldy!
That’s it! Here’s an example.
public static class MoveQueueMessagesToTableStorage
First, what’s a poison message? A poison message is a message that fails to be processed correctly by your logic. Either the message was malformed, or your code threw an exception. Whatever the reason, we need to take care of that!
Let’s add another function to handle those extraordinary cases.
Waaaaaait a minute… what’s this
incoming-animals-poison you tell me? That, my friend, is automatically created when queue trigger fails five times in a row.
Did we just handle poison messages by just creating a single function? Yes.
So by now, you’re probably asking me:
Well, how much is this serverless goodness going to cost me?
That’s the beauty of it. On a consumption plan? Zero. You only pay for what you use and if you use nothing or below the free quota? 0$
Creating a decoupled architecture is easier with a serverless architecture. Cost is also way easier to manage when you don’t need to pre-provision resources and are only paying for what you are executing.