Azure Category

Azure Cache for Redis is a cache layer, built on Redis, for better performance for consuming data, particularly reads. But, like most things, I like to develop locally and unpack they way something works without having to consume cloud services. So recently I looked at how I can run Redis locally for the Discord Bot and move it into Azure when done. By adding a cache service like this inbetween the Discord Bot proxy service (a traditional .

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:

Azure EventGrid is a messaging pipeline that allows you to easily build event based applications that allow you to wire your application components to both publish and subscribe to events. EventGrid also has a number of built in Azure connectors out of the box, including Azure numerous Azure service publishers, as well as Functions, Service Bus, Logic Apps and general web hooks. Setting Up If you have a more traditional ASP.

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.