DEV Community: Sameer Jejurkar

Generative AI: A glossary of terms

Sameer Jejurkar — Sat, 09 Dec 2023 13:28:32 +0000

ChatGPT captured the world's imagination as soon as it was launched on Nov 30, 2022. Within a couple of months, it became the fastest-growing application ever, hitting over 100 million users. With ChatGPT, previously little-known terms like Generative AI, GPT, LLM etc. came to the fore. In this article, we will try to understand what these mean in relatively simple language. Please note that this is in no way meant to be exhaustive.

Generative AI

Generative AI refers to machine learning algorithms (ML models) that can create (hence generative) content such as text, images and even music like a real person. These are a major advancement over traditional ML models. Until recently, ML models were limited in what they could do. Traditional models are focused on specific areas such as data analysis, forecasting, image recognition, voice-to-text conversion etc. These models are trained using a structured and labeled data set. In contrast, GenAI models are trained using massive amounts of unstructured data and they are not trained with any specific focus.

Foundation Models

A foundation model is a large-scale model that serves as a base for various applications. These models are trained on diverse and extensive datasets, enabling them to acquire a wide range of skills and knowledge. These models are foundation in the sense that they provide a broad capability base on which specialized functionalities can be built. They can be adapted or "fine-tuned" for specific tasks, making them incredibly efficient for various uses. Foundation Models excel in understanding complex patterns and making predictions, which can be applied in fields like natural language processing, image recognition, and beyond. GPT-4 and DALL-E from OpenAI, Claude from Anthropic, and Llama from Meta are some examples of foundation models.

Large Language Models

Large Language Models (LLMs) are a type of Foundation Model specifically designed for understanding and generating human language. They are trained on vast quantities of text data and can generate coherent, contextually relevant text based on input prompts. These models can do things like answer questions, write stories, or even translate languages. GPT-4 from OpenAI, Claude from Anthropic, and Llama from Meta are some examples of LLMs.

GPT: Generative Pre-trained Transformers

The "GPT" in ChatGPT stands for Generative Pre-Trained Transformers. GPT is a specific series of Large Language Models (LLMs) developed by OpenAI, known for its advanced text generation capabilities. All GPT models are LLMs but not all LLMs are GPT models. ChatGPT is an interactive chat application built on top of a GPT model (currently GPT 3.5 and GPT 4).

Prompt Engineering

Prompt Engineering is the process of composing specific instructions for (i.e. prompting) Generative AI tools to produce the desired output. It involves using precise and clear language to guide the AI tool in producing the desired output. This is often an iterative process involving refining the instructions (prompt) until you get the expected output. Good prompts can significantly improve the possibility of getting the most accurate and relevant responses.

Training and Fine-Tuning

Training refers to the process of feeding a model large amounts of data so it can learn to perform a task. This is the initial training of the model and is very resource-intensive. Fine-tuning, on the other hand, involves adjusting a pre-trained model on a smaller, task-specific dataset to enhance its performance in that specific area.

Neural Networks

While the term "Neural Networks" doesn't come up as often as some of the other terms, no discussion about Generative AI can be complete without it. Neural Networks are at the core of Generative AI. They are algorithms modeled after the human brain, designed to recognize patterns and make decisions based on the data they've been trained on. Neural Networks have been around for decades. The advent of the internet and increasing computational power in the 21st century led to the rise of deep learning, where networks with many layers ('deep' networks) could learn from vast amounts of data. This progress has led to the evolution of Generative AI.

Hosting a Serverless Web Application in AWS - Part II

Sameer Jejurkar — Sun, 05 Nov 2023 05:38:19 +0000

This is the second article in this series about hosting a serverless web application in AWS.

In the previous article, we set up a static website using AWS S3. However, there are some problems with this - we had to enable public access on our bucket and the website does not use SSL/TLS. In this article, we will enable CloudFront distribution for this website and avoid these problems.

Amazon CloudFront

Amazon CloudFront is a Content Delivery Network (CDN) that distributes our content globally to various edge locations. When a user requests our content, they are served from the edge location nearest to them, reducing latency. CloudFront caches our files at edge locations. This means that repeated requests for the same content are served from the cache, which is much faster. Also, serving content from the cache reduces the number of requests to our S3 bucket, which can reduce our S3 costs.

Create a CloudFront Distribution

Navigate to the CloudFront page from the AWS console.

Click Create a CloudFront distribution .

We will choose our S3 bucket in the Origin domain dropdown list. For Origin access, lets' select the Origin access control settings option as we do not want our bucket to be publicly accessible.

Next, we will create a new control settings.

We'll keep the default values in the Create control setting windows that pop-ups. Click the Create button to create the control setting.

Note that we will need to manually update the bucket policy to grant permissions to our CloudFront distribution.

As this is just a sample application, choose Do not enable security protections in the Web Application Firewall section. For production applications, we should consider enabling security protections.

Let's assume that a majority of our users will be from North America and Europe and choose the appropriate Price class. This means that our website content will only be served by edge locations in these regions. This also means that users in other regions may see higher latency.

Since index.html is the home page of our website, we will set that as the Default root object. This is the content that will be returned when the user requests the root URL.

We will keep the remaining options as default and click Create distribution button at the bottom to create our distribution. We should see a confirmation that the new distribution was created successfully.

Make a note of the Distribution domain name as we will use it to access our website. There should be a Copy policy button on the top left corner. Click the copy icon to copy the S3 bucket policy. Now, let's navigate to the S3 bucket and update the bucket policy.

Replace the policy we created earlier with the policy that was copied above. Since we have created a CloudFront distribution to serve our website, we no longer require our bucket to be publicly accessible.

We will navigate back to Edit Block public access for our bucket and check Block all public access box and save changes. Checking this box will result in a confirmation pop-up.

Type confirm in the field to confirm the settings and click Confirm.

Accessing our website

Our website will now be accessible using the Distribution domain name.

This is great but there is still one issue. The link for our website is cryptic and not ideal. So, now let us associate our domain with this CloudFront distribution so we can use a friendlier URL for our website.

Use our domain for our website

Note: If you don't have a domain, you can register one for a reasonably economical price or even free (with some restrictions). You can do a web search for this.

We already have a domain, cloudbuff.in , registered, so we will use tic-tac-toe.cloudbuff.in for our website.

Request a certificate

Since we want our website to be secure and support SSL/TLS, we will request a new certificate for this domain from AWS Certificate Manager.

On AWS Certificate Manager screen, click the Request button to request this new certificate.

We will request a public certificate.

We will put in the desired domain for our website as the Fully qualified domain name and choose DNS validation as the method to validate domain ownership. Click the Request button at the bottom of the page to continue.

We should see a message that the certificate has been successfully requested. the status is Pending validation. We need to take some additional steps before the certificate is approved.

Click on the Certificate ID link and navigate to the Domains section.

The status is Pending validation and there are two columns of interest CNAME name and CNAME value. We need to add a DNS record of type CNAME through the domain registration website. Our domain is registered with GoDaddy, so we will go that site and add a DNS record there.

Make sure that the type is CNAME and copy the Name and Value from the AWS Certificate Manager screen. Save your changes. This will allow AWS Certificate Manager to confirm that we own this domain.

Note: DNS validation can sometimes take hours depending how DNS changes are propagated and become visible to AWS Certificate Manager.

Update DNS

Once the validation is complete, we can add a new CNAME record to our DNS. This is to point subdomain tic-tac-toe to our CloudFront distribution domain.

Update domain for distribution

Now, we will associate this domain with our CloudFront distribution. For this, we need to edit the distribution settings.

We need to specify our custom domain in the Alternate domain name (CNAME) field. We also need to select the certificate we created earlier in the Custom SSL certificate dropdown.

Click the Save changes button at the bottom to save. Now we should see our changes being deployed. This can take some time.

Once the changes are successfully deployed, we should see the date and time in the Last modified column.

Now we should be able to access our website using our custom domain https://tic-tac-toe.cloudbuff.in/. Note that the website is secure and uses SSL/TLS.

Conclusion

In this article, we saw how we can use CloudFront as the CDN for our website. We also associated our custom domain with our static website hosted using S3. In subsequent articles, we will build further on this and see how we can deploy a dynamic web application in AWS without setting up any servers.

Hosting a Serverless Web Application in AWS - Part I

Sameer Jejurkar — Sun, 05 Nov 2023 05:37:52 +0000

This is the first article in this series about hosting a serverless web application in AWS. We will start with hosting a static website and then move towards deploying a dynamic web application.

In this article, we will set up a static website using Amazon Simple Storage Service (S3). With this approach, we can easily set up a scalable website without requiring any servers.

Before we jump in, let's clarify what we mean by a static website. A static website consists of fixed content: HTML, CSS, and JavaScript files. A dynamic website, on the other hand, depends on backend or server-side processing.

We will set up a simple Tic-Tac-Toe game using HTML, CSS and JavaScript using AWS. We will use the source code available at https://www.geeksforgeeks.org/simple-tic-tac-toe-game-using-javascript/. You can download the files from here.

Why use S3

Amazon Simple Storage Service (S3) is a scalable object storage solution provided by AWS. It is highly durable, so you don't need to worry about losing your code or files. It offers high availability, so it greatly reduces the chances of our website being inaccessible. It is highly scalable - it can handle massive traffic spikes, making it an ideal choice for websites that demand high availability. We do not need to set up or manage any servers, so it eliminates the overhead of managing servers.

Create an S3 bucket

First, let's create a new bucket that we want to use to store the files for our website. We will create a new S3 bucket with the name tic-tac-toe-site-123. Note that the bucket names should be globally unique, so your bucket name should be different. For instance, replace the 123 with some other number to make it unique. I am using the region US East (N. Virginia) for this bucket.

Our website will be publicly accessible. Hence our bucket will need public access. Uncheck the Block all public access box. This will uncheck all boxes underneath. Check the box in the warning section acknowledging that the bucket and objects in it will be publicly accessible.

Leave default values for the remaining options and click Create bucket to create the bucket.

The bucket should now appear in the list of all buckets.

Upload website files

Click on the bucket name and go to Objects tab. Click the Upload button.

On the Upload page, click the Add files button to choose the files to be uploaded or simply drag and drop the website files.

Go to the folder/directory containing the website files. Select all of them to upload.

Once the files are listed, click the Upload button to upload the files.

Add permissions policy

The uploaded files need to be made publicly accessible. Navigate to the Permissions tab and click the Edit button in Bucket Policy section.

Copy and Paste the following policy to make the bucket content publicly readable. Note that you will need to replace tic-tac-toe-site-123 with the name of your bucket.

{
    "Version": "2012-10-17",
    "Statement":
    [
        {
            "Sid": "PublicRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": ["s3:GetObject"],
            "Resource": ["arn:aws:s3:::tic-tac-toe-site-123/*"]
        }
    ]
}

Enable static website hosting

We need to let AWS know that this bucket is going to be used to host a static website. Navigate to the Properties tab, scroll down to the Static website hosting section and click the Edit button.

On the Edit static website hosting page, select the Enable radio button under Static website hosting and Hosting a static website radio button under Hosting type. In the Index document text field, put index.html as this is the home page on our website.

Click Save changes to save these changes. The link to access will now appear at the bottom of Static website hosting section.

Accessing our website

Click the link in Bucket website endpoint to open our website. We are now ready to play Tic Tac Toe game!!

Conclusion

It's great that our website is up and running but there are some problems with this. First, the website is not secure - it does not use HTTPS. Also, we had to make our bucket publicly accessible, which is not a good practice. In the next article in this series, we will see how we can avoid these problems by using CloudFront.

Part II: Automate invoice processing using AWS Textract

Sameer Jejurkar — Sat, 02 Sep 2023 12:10:01 +0000

In the previous article, we saw a quick demo showcasing how Textract can be used to extract relevant information from a scanned invoice. We took a sample invoice file, uploaded it through the AWS console and reviewed the information extracted by Textract. In this article, we will use a Python script to programmatically extract data from the same invoice using Textract SDK.

We will run our code as a Jupyter Notebook. This can be done in several different ways. For this demo, we will run the Notebook using Visual Studio Code IDE.

Let's get started by cloning the repository https://github.com/sjejurkar/aws-textract-demo.

Before running the code, we need to do a couple of things. First, we will install the required Python packages using the following command:

pip install -r requirements.txt

Second, this code makes calls to Amazon Textract, so our AWS credentials need to be configured. On Linux and MacOS these are usually located in the file ~/.aws/credentials. On Windows, these are usually located in the file %USERPROFILE%\.aws\credentials. Check this link for details.

As part of the AWS Free Tier, you can get started with Amazon
Textract for free. The Free Tier lasts for three months, and new > AWS customers can analyze up to 100 invoice pages per month.
Beyond this, there are charges for using Textract.

Once the packages are installed and AWS credentials properly configured, we are ready to run the code in Notebook invoice_demo.ipynb. The Notebook is in invoice_demo directory.

In the first cell of the Notebook, we will load the image of our invoice and display it. Running this cell should display the invoice image as the cell output. The image sample-invoice-1.jpg is located in documents directory.

Next, we will call the Textract SDK to upload and analyze the invoice. Note that method extractor.analyze_expense has been called so that Textract knows that the document we want to process is an invoice. The cell output should show that this document has only 1 page.

All the details extracted by Textract are available in the document object. Property document.response has JSON that contains all the details. We will use these details to draw boxes around the text that has been extracted. For this, we will take the existing image and based on the geometrical data extracted by Textract, draw boxes around various extracted text items. Boxes around labels will be red and those around values will be blue.

The cell output should show the image with boxes drawn around the extracted text.

Next, let's save this image as file sample-invoice-1-boxed.png in the documents directory for future reference.

Textract SDK allows for the extracted data to be output in various ways. Let's print the summary data and line items in a readable, tabular format.

We can also output this data in CSV format as key-value pairs if required.

The tabular and CSV outputs are easy to look at or download for further inspection but they may not be the best formats if we want to do further processing. Hence, we will create dictionaries for summary and line items to ease downstream processing.

The cell output shows the various items being added to these dictionaries.

Let's print some relevant information from these dictionaries. Data from these dictionaries can used in downstream operations such as saving to a database, or passing to another system for further processing, etc.

That's it. This article is meant to be an introduction to how Textract SDK can be used to get started with document processing. Play around with the code, try out different things and feel free to share your comments.

Automate invoice processing using AWS Textract

Sameer Jejurkar — Sat, 26 Aug 2023 14:58:44 +0000

A routine task that every business must perform is to process invoices. Often, these invoices are received in paper form or as email attachments. Processing these invoices can - a) be tedious, b) consume a lot of time and c) be error-prone. This makes invoice processing a good use case for automation.

Overview of Textract

The primary challenge in processing invoices is extracting the relevant data. This is where Amazon Textract can help. It is a service provided by Amazon Web Services (AWS) that uses advanced Machine Learning (ML) algorithms to automatically extract structured and unstructured data from scanned documents, images, and PDF files. It can detect typed and handwritten text in different types of documents including invoices, financial reports, medical records, tax forms etc. Under the hood, it uses Optical Character Recognition (OCR) technology and pre-trained ML models to understand and interpret the content of documents.

Textract Demo

Here is a quick demo to showcase how Textract can be used to extract relevant information from a scanned invoice.

As part of the AWS Free Tier, you can get started with Amazon
Textract for free. The Free Tier lasts for three months, and new > AWS customers can analyze up to 100 invoice pages per month.
Beyond this, there are charges for using Textract.

Let's jump to the AWS console and see how it works. Log into your AWS account and search for Textract in AWS console. Click Amazon Textract in the search results.

This brings us to the Textract page. For this demo, we will use the US East N. Virginia region.

Click on Try Amazon Textract button. This navigates to the Analyze Document screen. Since we want to analyze an invoice, click on the Analyze Expense option in the menu on the left.

By default, this screen shows a sample document and the relevant information extracted by Textract. We can see the image of a Whole Foods receipt on the left and the extracted raw text on the right.

Scroll down and pick the Invoice option. Selecting this option updates the sample to an invoice document and the text extracted from it. We want to use Textract for our sample invoice, so click Choose document to upload it.

We will upload an image from the local drive (download this invoice image).

Textract will take a few seconds to process the invoice once it is uploaded. Soon, we will see our invoice with the extracted text outlined.

On the right, we can see important summary fields like Vendor Name, Vendor Address, Reciever Name, Receiver Address, Invoice #, Invoice Date etc. Clicking on Line item fields shows the invoice line items.

The right panel shows that all the line item details have been correctly extracted. As you can see, Textract can detect and extract tables quite nicely. Another interesting feature is that if you click on any of the text items in Results, it will highlight the portion of the invoice from where the text item was extracted.

Click Download results button to download the information extracted from the invoice as a zip file.

The downloaded zip file has three files- two CSV and one JSON file.

File summaryFields-1.csv contains the extracted summary information such as the Vendor name, address, phone etc.

File lineItemFields-1 contains the line item details extracted.

Note that it also shows the confidence scores for extract labels, column titles and values.

File analyzeExpenseResponse.json contains a lot more additional details including geometric information (position and size of extracted text) etc.

Conclusion

We saw in this demo that Amazon Textract goes beyond simple OCR to identify, understand, and extract data from forms and tables. The only information we provided was that the document is an invoice. We did not specify any labels, text or positions to extract. The use of pre-trained ML models makes Textract smart enough to automatically identify the appropriate labels and text relevant to an invoice.

In this article, we saw a quick demo of Textract using the AWS console. Textract provides a wide range of CLI and SDKs for Python, Java, NodeJS etc. In the next article, we will use a Python script to programmatically extract data from the same invoice using Textract SDK.

Azure Functions: Hosting Plans

Sameer Jejurkar — Sat, 11 Mar 2023 16:49:38 +0000

In the previous articles in this series, we created a few functions and deployed them to Azure. In this article, we will review various options available for hosting our Function App in Azure.

When we create a Function App in Azure, we must specify where our functions are hosted and where they will run. This is done by selecting a hosting plan. Azure offers three basic hosting plans:

Consumption
Premium
Dedicated

Consumption plan

This is the default hosting plan and is truly serverless. The cost will depend on the amount of memory used and the number of executions of our functions. Resources used by all functions in a Function App are combined to calculate the cost.

Advantages

We pay only when our functions are running.
Azure will automatically scale our functions based on the load.
This plan offers a free monthly grant.

Note : Pricing calculation for this plan is somewhat complicated. Hence it is difficult to generalize free usage, but if we have a few hundred thousand function executions per month across all functions in our subscription, those will likely get covered under the free monthly grant.

Drawbacks

Cold starts - functions may scale down to zero and when the next invocation occurs, it will require some time to start up leading to a higher response time.
Maximum memory available per instance is 1.5 GB RAM

Premium plan

With the Premium plan, specific resource capacity (vCPU and memory) is reserved to run our functions. We can choose one of the available resource configurations. If autoscaling is enabled, Azure will spin up additional instances of the Function host based on load.

Advantages

Pre-warmed instances to avoid cold starts and provide consistent response times.
Predictable pricing as allocation of resources is determined upfront.

Drawbacks

This plan can be expensive as you are paying for pre-allocated resources and also for additional instances for scaling.

Dedicated plan

If we have an existing App Service plan, we can use the Dedicated plan to run our functions. Our functions will run on our App Service. If the server hosting our App Service is underutilized, this plan can help us use the remaining resources well.

Advantages

Functions run on an existing App Service
No additional costs

Drawbacks

Auto-scaling is not supported

In this article, we saw a quick overview of options available to host our Azure Functions. Note that this article covers only the basics. Pricing calculations and some finer details are beyond the scope of this article.

Azure Functions: Output Bindings

Sameer Jejurkar — Sun, 30 Oct 2022 12:25:51 +0000

This is the seventh article in this series on Azure Functions. In this article we will take a look at output bindings.

The general pattern of a function is: receive data from some source, process it in some way and send it to some destination. Bindings are a way for Azure Functions to connect to data sources and destinations. They allow our code to receive data from some source (HTTP request, Storage Queue, etc.) and optionally send data to some destination (Storage Queue, Storage Blob, etc.).

There are two types of bindings:

input binding - connection to input data source
output binding - connection to output data destination

Output binding

Let's consider an example. We have an HTTP endpoint and the data posted to this endpoint must be put into a Storage Queue. Here the trigger is HTTP request and output binding is Storage Queue. HTTP is the implicit input binding in this case.

First, let's go to Visual Studio code and start Azurite from the Command Palette.

Then start Azure Storage Explorer and create a new queue called binding-queue.

Let's add a new function called BindingDemoFunction as shown below (source code is available on GitHub).

This function is similar to the SimpleHttpFunction we had created in a previous article but there are some important differences.

Under FunctionName declaration, we have line [return: Queue("binding-queue")]. This declares an output binding of type Queue and queue name binding-queue.

Return type for Run method is Task<string> instead of Task<IActionResult>.

And the function returns a string instead of OkObjectResult object.

The method returns an string, the output binding takes the string, creates a message and puts it into binding-queue Storage Queue. Simple and straight forward.

Test the function

Now, let's run the function. We should see the function URL in the logs displayed in VS Code terminal.

We will use the popular Postman tool to test our function. Create a POST request with http://localhost:7071/api/BindingDemoFunction as URL and a simple JSON as the body. We should get back 200 status when the function runs successfully.

Let's go over to Storage Explorer and verify that the message has been put into the queue. We may have to click the Refresh button for the message to be visible.

Note: We have previously set AzureWebJobsStorage property as UseDevelopmentStorage=true in local.settings.json file. Hence the message is created correctly in the queue.

Conclusion

In this article, we saw how to create an output binding for a Storage Queue and send a message to the queue from our Function. In the next article, we will see how to use Azure Key Vault to protect sensitive information such as connection strings, so our Function does not have direct access to it.

Up and running with Azure Functions

Sameer Jejurkar — Sat, 15 Oct 2022 15:58:01 +0000

This is a series of articles to help get started with Azure Functions.

Sending Function logs to Log Analytics

Sameer Jejurkar — Sat, 15 Oct 2022 15:55:53 +0000

In the previous article, we deployed our simple function with Storage Queue trigger to Azure cloud. We saw how to view the log stream of our Function App. While reviewing logs this way is fine for testing, it is not a practical solution once the function is deployed and running. We simply cannot watch log stream all the time. Besides, it also means that we have to leave the browser tab open for the log stream to continue. In this article, we will configure our Function App to send logs to a centralized location using Azure Log Analytics.

Create Log Analytics Workspace

First, we will create a Log Analytics Workspace for collecting our function logs. Let's go to Azure Portal and search for log analytics resource. Click on Log Analytics workspaces in the search results.

Click on + Create to specify the details of the workspace.

We will create this new workspace in our existing blog-functions-rg resource group. We will name this workspace blog-functions-log-analytics-ws and specify region East US that we have used so far. Click on Review + Create to continue.

We should see a Validation passed message. Click on Create to create the workspace.

Configure Function App Diagnostics Settings

After the workspace is created, it needs to associated with our Function App so the logs can be routed to this workspace. To do this, we will navigate to our Function App and click on Diagnostic settings item in the left menu. In the panel that opens on the right, we will click + Add diagnostic setting.

We will name this setting blog-function-app-log-diag-settings. Since we want to send function logs to the workspace we created, check the Function Application Logs and the Send to Log Analytics workspace boxes. Choose the workspace we just created in the Log Analytics workspace list. Click Save at the top to save this setting.

We should now see the setting in the list of Diagnostic settings of our Function App.

Invoke HTTP Function

We need to generate some logs before we can view them. For this, let's invoke our HTTP function. Open a new browser or tab, put URL https://blog-function-app.azurewebsites.net/api/SimpleHttpFunction into the address bar and press enter.

Note: Each function logs a single message. We will look for these messages in the log workspace.

View Logs

Now let's see if the logs show in the Log Analytics workspace. We will navigate to our workspace and click on Logs item in the left menu. We can close the pop-up that appears on the right as we won't be using any of these queries. Instead, we will write our own query.

Azure Log Analytics uses Kusto Query Language (KQL) to help query and filter logs. After closing the pop-up, note that the scope is our workspace name. Select Last 30 minutes as the Time range, specify FunctionAppLogs as the query text and click Run button. We will see logs appearing under the Results tab.

Note: There can be a delay of a few minutes for the logs to make it to the workspace.

There will be a lot of messages. Azure itself writes a lot of information to the workspace. Scroll down and look for message with Category as Function.SimpleHttpFunction.User and you should see the log message written by the function.

Next, let's get our SimpleQueueFunction to run. Go to the blog-queue and add a new message { "msg": "Write to log analytics" } to the queue (see previous article for details).

When we run the query again in Log Analytics workspace, we should see the message logged by SimpleQueueFunction. Clicking the > sign will expand the details.

Advanced Log Analytics Queries

As mentioned earlier, we can use Kusto Query Language (KQL) to query logs. When we invoked our HTTP function, a lot of messages were generated. This is going to happen every time a function is executed. If there are many function executions, there will be a large number of messages and these could be from different functions. This makes it very difficult to get to the messages that we actually need to review. KQL is quite powerful and we can use its filtering capabilities to narrow down the messages we are interested in. For e.g., to look for messages generated by a specific function, we can use a query like this:

FunctionAppLogs
| where Category startswith "Function."
| where FunctionName == "SimpleQueueFunction"
| project TimeGenerated, FunctionName, Level, FunctionInvocationId, Message
| order by TimeGenerated desc

The above query will retrieve messages generated by our code as well as those generated by Azure. To see messages from only our code, we can add a where Category endswith ".User" filter.

FunctionAppLogs
| where Category startswith "Function." 
| where Category endswith ".User"
| where FunctionName == "SimpleQueueFunction"
| project TimeGenerated, FunctionName, Level, FunctionInvocationId, Message
| order by TimeGenerated desc

Notice that KQL appears to be similar to SQL. Here FunctionAppLogs is the table. Data from this table can be filtered using where clauses and project clause can be used to include only the fields that we are interested in (like select clause in SQL). Ordering of results is also supported.

Checkout a few advanced KQL query examples in my Github repo.

Conclusion

In this article, we set up a Log Analytics workspace and configured our Function App to send logs to it. This workspace acts as centralized location for retrieval and analysis of logs. We also saw how we can query and filter logs using KQL.

Note: It is possible to use the same Log Analytics workspace to collect all your logs - such as those from other Function Apps, App Services, Virtual Machines etc.

In the next article, we will take a look at Function App bindings.

Deploying Storage Queue Trigger Function

Sameer Jejurkar — Sat, 08 Oct 2022 12:35:18 +0000

In the previous article, we created a function that gets triggered when a message arrives in a Azure Storage Queue. Using a storage emulator, we tested our function locally. Let's deploy it to Azure and test it in the cloud now.

Create Storage Queue

When we set up Azure Function App, we created a Storage Account and linked it to our Function App. We will use the same account to create a Storage Queue. In Azure Portal, let's go to our storage account.

Click on the Storage Account name and then on Queues item in the left menu. List of queues is displayed on the right. There are no queues since we haven't created any yet. Click on + Queue icon to create a new queue.

Let's create a queue with name blog-queue. This is the name that we specified when we created SimpleQueueFunction.

We should see a message indicating that the queue was created successfully. Next, let's deploy our function to Azure.

Deploy function

Let's go to Visual Studio Code and open the project that we worked with in our last article.

If you haven't signed in to Azure from VS Code, checkout this previous article to see the steps for signing in.

Open the Command Palette using keyboard shortcut Ctrl + Shift + P (use Cmd + Shift + P on Mac) or View > Command Palette... menu option. Type Azure Functions: Deploy into text box and select Azure Functions: Deploy to Function App... option.

You may get a pop-up message in VS Code asking you to set up your Azure account. If you had signed into Azure previously and get this message, open the command palette, type Azure: Sign and click the Sign Out task. It will then allow you to sign in again.

A list of Function Apps defined in Azure will be displayed. As we have created only one Function App blog-function-app, we should see just that in the list.

When we select blog-function-app for deployment, there will be a warning saying the previous deployment will be overwritten. We will click Deploy to proceed.

A Terminal window should open in VS Code and we should soon see Deployment to "blog-function-app" completed. message pop-up.

Our code has been deployed successfully. If we go back to Function App in Azure Portal and click on Functions menu item, we should see both SimpleHttpFunction and SimpleQueueFunction in the list.

Let's test our function by putting a message into the Storage Queue. First, let's enable the log stream so we can verify that our function is indeed getting triggered when a message is received in the queue. We will go to our Function App in Azure and click on Log stream item in the left menu. A terminal will open to the right and in a few moments we should see that it is connected to our Function App.

Let's keep this browser tab open so we can come back to check log messages. We will duplicate this browser tab (hover over the current tab, do a right-click and click Duplicate option from the pop-up menu) and go to the Storage Queue that we created earlier. Clicking on + Add message icon will open a pop-up window. Note that this window is similar to the window that we saw in Azure Storage Explorer tool. Let's use a simple JSON message { "msg": "Message from Azure Portal" }. Add the message text and click OK to add it to the queue.

Now let's go back to the browser tab for log stream. We should see that the SimpleQueueFunction function was executed and the message from the queue is displayed in the logs.

Now let's verify that the logging also works the same way for SimpleHttpFunction. Open a new browser or tab, put URL https://blog-function-app.azurewebsites.net/api/SimpleHttpFunction?name=Jack into the address bar and press enter. If a message like the one below is displayed, it means our function was executed successfully.

In the browser tab for log stream, we should see that the SimpleHttpFunction function was executed successfully and the log message was written to the log stream.

Stopping and starting Function App

If we are still in test mode, we should consider stopping our Function App when it is not being used. We can go to our Function App and stop it.

When we are ready to use it again, we can start our Function App back up.

Conclusion

In this article we deployed our simple function with Storage Queue trigger to Azure cloud.

We saw how to view the log stream of our Function App. While looking at logs this way is fine for testing, it is not a practical solution once the function is deployed and running. We simply cannot watch log stream all the time. Besides, it also means that we have to leave the browser tab open for the log stream to continue. In the next article, we will take a look at a much better solution for this. We will configure our Function App to send logs to a centralized location using Azure Log Analytics.

Azure Function with Storage Queue Trigger

Sameer Jejurkar — Mon, 03 Oct 2022 11:29:39 +0000

In the 4th article of this series, we will create a function that gets triggered when a message arrives in a Storage Queue. We will run a storage emulator and test our function locally.

Previous articles in this series: Azure Functions: overview of concepts, Creating our first Azure Function, and Deploying our first function to Azure

Before we can create and test our function locally, we need to specify the queue that will be used to trigger our function. Since we don't have any queues currently, we need to create one. We want to run and test our function locally without connecting to Azure cloud, so our queue must exist locally.

Install Azurite extension for VS Code

To create a Storage account locally on our machine, we will use Azurite, a free, open-source emulator that provides local environment for testing Azure Blob, Queue Storage, and Table Storage applications. The emulator provides cross-platform support on Windows, Linux, and macOS. There are number of ways to install Azurite. Since we are using VS Code as our IDE, we will install it as a VS Code extension.

Click the Extensions icon on the vertical left menu. Type azurite in the search field, click on Azurite in the search results. Click on Install button to install this extension.

Start Azurite

After the extension is installed, we will start up Azurite so we can create a storage queue. Open the Command Palette using keyboard shortcut Ctrl + Shift + P (use Cmd + Shift + P on Mac) or View > Command Palette... menu option. Type command Azurite: Start and click on Azurite: Start option.

Once the Azurite service starts, we should see it's status in the bottom toolbar of VS Code saying that it is running on http://127.0.0.1:10000.

Azure Storage Explorer

Now that we have the Storage emulator running, we need to create our queue. For this, let's download and install Azure Storage Explorer. Azure Storage Explorer is a desktop application to conveniently manage Azure cloud storage resources. It can also connect to Azurite and help us manage local storage.

Let's start Azure Storage Explorer and click on the Explorer icon on the menu on the left. We will then navigate to Emulator & Attached > LocalStorage (Key) and Queues. Right click on the Queues menu and click on Create Queue from the pop-up menu to create a new queue.

Let's name the new queue blog-queue. We will use this queue as the trigger for our function.

Create a function with Storage Queue trigger

Our environment is now set up, so it is time to create our function. Let's go back to VS Code, open the Command Palette and type Azure Functions: Create into text box and select Azure Functions: Create Function... option.

Next, we need to choose the function trigger. We want this function to be triggered when a message is received in a Storage Queue, so type Queue in the text box and choose Azure Queue Storage trigger.

We will name this function SimpleQueueFunction.

We will continue to use CloudBuff.Function as the namespace.

In the next step, we will choose AzureWebJobsStorage.

Next, we will provide name of the queue we created blog-queue since we want the function to run when a message arrives in this queue.

We will then be asked to select a Storage account for internal use by the Azure Functions runtime. We will go with Use local emulator option.

Our function will be created as SimpleQueueFunction.cs. Note that Run function has binding for blog-queue and AzureWebJobsStorage as the connection string.

As we will be using Azurite emulator for local testing, we need to verify that it is associated with our function. To do that, we can check the AzureWebJobsStorage property in file local.settings.json. It should be set to UseDevelopmentStorage=true as we chose the Use local emulator option earlier.

Test the function

To run the function, click the option Run Without Debugging under the Run menu. VS Code will build the project and run it. Since we have two functions - SimpleHttpFunction that we created previously and SimpleQueueFunction that we just created - we should see both come up.

Now, lets add a message to blog-queue. Go to Azure Storage Explorer, click on blog-queue and click Add Message button on the tab that opens.

The Add Message window will pop up. Let's use a simple text message Blog Message #1. Add the message text and click OK to add it to the queue

Adding the message to the queue should trigger our function and we should see the message content being logged in the VS Code terminal window.

Now, let's add another message to the queue. This one is a JSON message { "message": "This is a JSON blog message" }. We should also see the message being logged in the terminal window.

And that's it!! We have successfully created and tested our second function.

Conclusion

In this article, we created a function that gets triggered when a message arrives in a Storage Queue and tested it locally. We saw how Azurite can be used to emulate a Storage account locally. We used Azure Storage Explorer tool to create a storage queue and add test messages to it.

In the next article, we will deploy this function to Azure cloud and use an actual Azure Storage queue to test it.

Deploying our first function to Azure

Sameer Jejurkar — Sat, 01 Oct 2022 08:17:40 +0000

In the previous article, we created a simple function with HTTP trigger and tested it locally. Now it's time to deploy it to Azure cloud platform.

Create an Azure account

Before we can deploy our first function to Azure, we will need an Azure account. For this, we will go the to Azure website and sign up for a free account. Note that you will have to provide credit card information and some additional information depending on your location. Usually, Microsoft provides up to US$ 200 worth of Azure credit when you sign up.

Create a Resource Group

Once you are logged into Azure, the first step is to create a Resource Group. This is simply a logical container for keeping related cloud resources together. Go to the search bar at the top and type resource groups. Click on Resource groups in the Services section of the results.

Our subscription should automatically be selected on the creation form. Let's specify blog-functions-rg as the name of the resource group and select a region. You can select any region you like. For e.g., you can choose the region your located in or a region close to you. We will go with East US.

Click on Review + create to proceed. If everything is good, a "Validation Passed" message will be displayed.

Clicking on Create will create the Resource Group.

Create a Function App

Now, let's create a Function App. Type Function App in the search field at the top and click onFunction App in the Services section of the results.

Again, our subscription will be automatically selected. We will use the blog-functions-rg Resource Group we just created and name our Function App blog-function-app. Note that this name must be globally unique because Azure uses <function-name>.azurewebsites.net as the base URL for the Function App. So, you will have to choose a different name. We are going to deploy the function we created using Visual Studio Code, so we will choose Code as the Publish option. We will pick .NET as the Runtime stack and 6 as the version since that is what we used to create our function. We will select the same region as the Resource Group, East US, to deploy the Function App.

We will use Linux as the Operating System (Windows will work too, but we will go with Linux as it appears to be the more popular choice for deploying code in the cloud). There are several pricing plans available and we will look at all the available plans in more detail in a future article. For now, we will go with the Consumption plan as this is a true serverless plan. You are charged based on how many times the function is executed. Another nice thing with this plan is that first 1,000,000 executions are free.

Click on Review + create to proceed. A confirmation screen will be displayed. Click Create to create the Function App.

It may take some time for the deployment to be completed. Once it is complete, we will see a confirmation. Click on Go to resource to view details.

Click on the Functions menu on the left. Currently, there are no functions under this Function App.

Create a Storage account

We must link a general purpose Azure Storage account to the Function App we just created because it relies on Azure Storage for operations like managing triggers and logging function executions. Since we don't have a Storage account, we will create one. In Azure Portal, type storage in the search bar and click on Storage accounts in the Service section of the search results.

We will choose the same blog-functions-rg Resource Group. We will use blogfunctionstorage as the name (note that we cannot use hyphen, underscore or any other special characters in the name). We will select the same region as the Resource Group, East US. We will go with Standard option for Performance, since it will work for most scenarios and low latency is not really a requirement for us. For Redundancy we will opt for Locally-redundant storage (LRS) as it is the lowest cost option and recommended for non-critical scenarios. For production environments, it is advisable to use Zone-redundant, Geo-redundant or Geo-zone-redundant option depending on your requirements and budget. Click Review button to proceed.

Click Create to create the Storage Account.

Once the Storage account is created, we should see the details in the Portal.

Link the Storage account to Function App

Now let's link this Storage account to our Function App. For this, we first need to get the connection string for our Storage account. Click on Access keys item in the left menu. That will display Access keys for the account. Click on the copy icon at the end of Connection string field.

Go to the Function App by searching for Function App in the menu. Click on the name of the Function App.

Select the Configuration item from left menu. Under the Application Settings tab, click on + New application setting link.

On Add/Edit application setting pop-up form enter AzureWebJobsStorage as the name and paste the Storage account connection string that we copied earlier. Click OK.

After the pop-up form closes, click on Save icon to save the new setting. We have now linked our Storage account with our Function App.

Deploy function

Now, we will switch over to Visual Studio Code, open the project that we created previously and deploy our function. Click on the Azure icon in the left menu.

Click on Sign in to Azure... option. This will open a browser window. Login with your Azure credentials.

Upon successful login, we should see Select Subscriptions... option in VS Code. Let's select our subscription from the drop list.

A list of Function Apps defined in Azure will be displayed. As we have created only one Function App blog-function-app, we should see just that in the list.

When we select blog-function-app for deployment, there will be a warning saying the previous deployment will be overwritten. We will click Deploy to proceed.

A Terminal window should open in VS Code and we should soon see Deployment to "blog-function-app" completed. message pop-up.

Our function code has been deployed successfully. If we go back to Function App in Azure Portal and click on Functions menu item, we should see SimpleHttpFunction in the list.

Now that our function is deployed, let make sure it works. Open a new browser or tab, put URL https://blog-function-app.azurewebsites.net/api/SimpleHttpFunction into the address bar and press enter. If a message like the one below is displayed, it means our function was executed successfully.

Now let's modify the URL. Add a name query parameter with Jack as the value:https://blog-function-app.azurewebsites.net/api/SimpleHttpFunction?name=JackWe will get a different response now. As you can see that both responses match what we saw when we tested the function locally.

And that's it!! We have successfully deployed our function to Azure.

Conclusion

In this article, we deployed a simple function with HTTP trigger to Azure cloud. In the next article, we will create a function that gets triggered when a message arrives in a Storage Queue.