Serverless Category

Now that the template of the bot is pretty stable and is modular in nature the next step is to develop a Continuous Integration / Continuous Deployment pipeline. To achieve this we are going to use GitHub Actions and Azure Resource Manager Templates to package our infrastructure, configuration and code and deploy it to Azure. If you don’t want to read through the process I used, you can go straight to the new Bot Template on GitHub

So far with our Discord bot we have our main parts together and running pretty simply. Any messages that come through will save to a table storage account where we can do some extra processing or keeping a log of what is going on. This runs pretty well but lets clean up our architecture and pipelines and make something a little be more scalable and interesting. First, let’s revisit what our architecture looks like:

After being busy with a lot of other side work, and the whole craziness going on with the current pandemic, I have finally gotten some time to work on my Discord Bot. The whole point of this bot is to use an Event based architecture to build out a workable, usable bot. And if I can sneak a bit of machine learning, cloud monitoring, ARM templates, session management and any other interesting thing I can justify playing with :-).

As I mentioned in my previous post on Azure Function basics, Functions are self contained code that are initiated with a trigger. This makes Functions extremely useful when working with Event driven architectures where your application is responding to discrete events. This week I spent a bit of time away from playing with the technology I’m using to build a Discord Bot and really started to plan out how to build the features.

When you create an Azure Function in Visual Studio you will have a ILogger injected into your method that provides logging services for you. When you run your Azure Functions locally this logger will display messages in the console, but for deployments you can connect Azure Application Insights to your Function to capture these logs, as well as provide a heap of monitoring information. Let’s check out how this works and what you can do with it.

One of the first things you want to do when you start out developing an Azure Function is to run it and potentially debug issues. You want to see what is going on with your Function before deployment to make sure it is working as intended. Let’s take a look at how to set up Visual Studio (2019 Community Edition) to run Functions locally, see what is going on and debug them.

The Basics of Azure Functions I started getting back into writing a Discord Bot using a Micro-services architecture. I’m using Azure Functions to do a lot of the heavy lifting when it comes to writing my bot and I thought it might be useful to do a deep dive into why I chose them. In this post I’m going to go through what Azure Functions are, when to use them and some application structures that best leverage this technology.

In my previous post we modified our Discord bot to take messages generated in chat, put them on a queue and processed them using an Azure Function. In this post we are going to modify the function that reads the message to place the message in an additional storage queue. An additional Azure Function will monitor this queue and write the message to table storage. Thankfully we have our core worker in place, this post, and future posts, should be a little bit shorter as we are now making incremental changes and improvements.

In my previous post we created a basic Discord bot that could listen to events from a Discord server. Up next we are going to start taking those events and moving them into a Storage Queue so they can be processed by an Azure Function. We are also going to get the bot to listen to a Service Bus Queue so it can pick up a message and deliver it back to the Discord Server.

Building services using a microservices architecture offers a number of benefits, especially when combined with the serverless options cloud providers can offer. This combination allows you to build a variety of small services, that cost very little, but can scale up with minimal to no additional effort and handle burst scaling really well. Over the next few posts I am going to go through designing and building a microservices application using a variety of services within Azure.