Forem: Parveen Singh

Azure Cosmos DB Partitions & Partition Keys Simplified

Parveen Singh — Fri, 16 Jul 2021 17:00:00 +0000

Performance and speed are crucial to the processing of any application running heavier or light workloads. The most significant impact any service can make on the application is the database queries. The latency to read, write and update the data in real-time can affect how the application performs its operation and how quickly it does that.

While working on an application design, you often seek certain functionality in services to be used by the application, such as high availability, data consistency, strong throughput, scalability, and robust disaster recovery solution. The most important thing is that all of those benefits shouldn't come at the cost of the application's performance.

In this article, you'll understand the concept of partition keys and the key concept involved in choosing the right partition key for your dataset.

Table of Content

Cosmos DB Partition Keys Overview
What are Containers in Cosmos DB
Logical Partitions in Cosmos DB
Physical Partitions in Cosmos DB
Replica Sets in Cosmos DB
Choosing the Right Partition Keys for Cosmos DB Account
Creating Cosmos DB Container with Partition Key using Azure Portal
Creating Cosmos DB Container with Partition Key using Azure CLI
Creating Cosmos DB Container with Partition Key using Azure PowerShell
Conclusion

Cosmos DB Partition Keys Overview

Azure Cosmos DB is designed to be used and operate for any size of workloads without any special configuration required to adapt to workload changes. That's all possible due to its scalable nature, and most importantly, the scalability is all taken care of under the hood by the Azure team so that you can spend more time writing efficient code and queries to interact with your data.

In terms of writing efficient queries, Cosmos DB allows you to group a set of items or data in your collection by a similar property determined by the partition key. Partition keys are the core element to distributing your data efficiently into different logical and physical sets so that the queries performed against the database are completed as quickly as possible.

It is essential to choose the partition key during the design phase of the applications as you cannot change the partition key once the container is created.

What are Containers in Cosmos DB

Before starting to unwrap the partitions, it is essential to understand what containers are in CosmosDB. As of today, Cosmos DB offers three types of containers: collection, tables, and graphs. If you wish to learn more about these types, check out the first article in the series here.

The containers are logical resources that groups one or more physical partitions of the data and necessary building blocks of Cosmos DB structure.

Logical Partitions in Cosmos DB

Grouping of items or documents with the same partition key forms a logical partition. The partition design is dependent on the partition key as it groups similar items for even distribution. It's worth mentioning that the partition key is a JSON property within the document that Cosmos DB can leverage to distribute the data. The logical partition can only store up to 20 GB of data.

It's easier to understand it using an example of a dataset: students' exam results for different subjects in class. Each student has exam scores for one or more exams. One of the possible logic partitions for this kind of dataset could be the subject name.

[{
    "userId":"Singh",
    "subjectName":"Maths",
    "score":"80"
},
{
    "userId":"Singh",
    "subjectName":"Physics",
    "score":"70"
},
{
    "userId":"Max",
    "subjectName":"Maths",
    "score":"90"
},
{
    "userId":"Max",
    "subjectName":"Chemistry",
    "score":"80"
}]

All the data with exam scores for every subject will be stored in its own partitions. Hence, grouping the data for a particular subject for multiple students in the same partition. Since the partitions are logical, you don't need to worry about deleting them once the associated data is removed or creating new ones for similar data.

Physical Partitions in Cosmos DB

Physical partition in Cosmos DB is Azure managed containers that enabled the scalability and data distribution across the platform by mapping multiple logical partitions to a single physical partition. Unlike logical partitions, the storage space for physical partitions is up to 50 GB for each partition.

The distribution of data across the physical partition depends entirely on throughput provisioned on the Cosmos DB account. Each physical partition is limited to the throughput of up to 10,000 request units (RU) per second. Based on the throughput defined for the account, the Cosmos account will automatically determine the number of physical partitions. In addition to it, the overall size of the account is also considered due to the 50 GB limit on each physical partition.

Replica Sets in Cosmos DB

A replica set in Cosmos DB is referred to as a subset of data within a physical partition set. Each physical partition distributes the data into a set of replicas to make the data durable, highly available, and consistent. Since the replica sets are running on Azure-managed nodes, the replication and global distribution process are handled automatically without any specific configuration.

Read more about the concept of Consistency in Cosmos DB on the article below:

Consistency Levels in Azure Cosmos DB Explained

Choosing the Right Partition Keys for Cosmos DB Account

When considering the exact partition key for your containers, you need to evaluate the dataset you are working with, identify key metrics, and understand how the performance might be impacted based on how the data is accessed. Here are few considerations when planning the right partition keys for your dataset:

The partition key of your container should distribute the data evenly across the solution. Choose a key that has the possibility of growing and still not overload one set of partitions.
Designing a partition key with uneven partitions or storing one document on each partition can cause cross-partition transactions in triggers and stored procedures.
Avoid the keys that can potentially overload one particular partition with excess data on new writes, causing exceeded throughput and partition throttling.
If your queries are mostly targeting a particular attribute of data, choosing that as a partition key would be an ideal use case to reduce cross-partition queries.

Creating Cosmos DB Container with Partition Key using Azure Portal

Navigate to your Azure Portal and follow the instruction below to create a new Cosmos DB account resource.

Search cosmos in the Azure Portal search bar and select the Azure Cosmos DB option under Services :

Click +Create and choose Core(SQL) - Recommended API option:

Fill out the relevant information on the Create Azure Cosmos DB Account page: Be sure to use the Free Tier Discount if you currently don't use any Cosmos DB account.

Click Review+Create followed by Create to complete the resource deployment.
Once the resource is deployed, navigate to the CosmosDB resource and click Data Explorer from the left blade menu:

Click New Container on the top left and fill out the following information on the New Container popup window:

The partition key you will be using is subjectName to distribute the data into logical partitions.

Expand the Database ExamsData and the Container named ExamsResult and click Items :

Click New Item on the top menu and replace the content of the editor with the following JSON data:

{
    "userId":"Singh",
    "subjectName":"Maths",
    "score":"80"
}

Click Save to complete the document upload:

Repeat the last step for the following data, entering one JSON object at a time :

{
    "userId":"Singh",
    "subjectName":"Physics",
    "score":"70"
}

{
    "userId":"Max",
    "subjectName":"Maths",
    "score":"90"
}

{
    "userId":"Max",
    "subjectName":"Chemistry",
    "score":"80"
}

Once uploaded, you should start seeing the data listed in the items view distributed by the subject name:

Creating Cosmos DB Container with Partition Key using Azure CLI

If you prefer using Azure CLI to create the resources, follow the instructions below to create the Cosmos DB resource using Azure CLI.

Launch the CloudShell from the Azure Portal and choose Bash as the environment:

You will first create a new resource group and cosmos DB resource inside that resource group. If you already have a resource group, feel free to update the name of the resouceGroup variable and skip the resource group creation command. Be sure to update the cosmosDB variable to use a globally unique name for the Cosmos DB account.

resourceGroup="cosmostest"
cosmosDB="cosmosaccount2021"
az group create -n $resourceGroup --location westus
az cosmosdb create -n $cosmosDB -g $resourceGroup --locations regionName=westus

Create the Cosmos DB Database using the following commands:

dbName="ExamData"
az cosmosdb sql database create --account-name $cosmosDB --name $dbName --resource-group $resourceGroup

Finally, create the container with a partition key of subjectName:

containerName="ExamResults"
az cosmosdb sql container create --name $containerName --partition-key-path '/subjectName' --account-name $cosmosDB --data
base-name $dbName --resource-group $resourceGroup

At this point, the Cosmos DB account, database, and container are ready to use either in any application code or using Data Explorer in Azure Portal. You can follow the step in the previous section to upload the sample data if you wish to add documents to the container.

Creating Cosmos DB Container with Partition Key using Azure PowerShell

If you are familiar with Azure PowerShell and prefer to use it instead of CLI, follow the instructions below to create the CosmosDB resource using Azure PowerShell:

Launch the Azure Cloud Shell with a PowerShell environment.
Create the resource group and a Cosmos DB account using the following commands:

$resourceGroup="cosmostest"
$cosmosDB="cosmosaccount2021"
New-AzResourceGroup -Name $resourceGroup -Location WestUS
New-AzCosmosDBAccount -Name $cosmosDB -Location WestUS -ResourceGroupName $resourceGroup

Once the account is ready, create the database inside the Cosmos DB account using the following commands:

$dbName="ExamData"
New-AzCosmosDBSqlDatabase -AccountName $cosmosDB -Name $dbName -ResourceGroupName $resourceGroup

Finally, create the container to store documents with a partition key of subjectName using the following commands:

$containerName="ExamsResults"
New-AzCosmosDBSqlContainer -Name $containerName -AccountName $cosmosDB -DatabaseName $dbName -ResourceGroupName $resourceGroup -PartitionKeyPath '/subjectName' -PartitionKeyKind Hash

Follow the steps in the previous instructions to upload the data inside the container or use alternate methods via application code to add or remove the data.

Conclusion

I hope that helps you understand the concept of partition keys in Cosmos DB since they are crucial to the data queries and impact the performance of your application. In the meantime, check out the following articles if you are looking to read more about Cosmos DB:

Is Impostor Syndrome a Real Thing?

Parveen Singh — Sun, 03 Jan 2021 00:41:05 +0000

Many of you might have heard about the word ' Impostor Syndrome". If you haven't, that's even better! You don't need to know. In fact, you should try to avoid yourself being in that position by any means possible!

But, it's easier said than done. Right?

I've been going through something similar in recent times. Doubt, Lack of Motivation, Restlessness, all resulting in inconsistent and degrading lifestyle. Having a hard time finishing off the tasks and even procrastinating more than often.

I never took it seriously, the concept of imposture syndrome. I would simply ignore it as it's not something I'd come across. Little did I know.

Here's what was going inside my mind all the times:

I'm not good enough.
I've failed x number of times already
I don't know 'x', 'y' or 'z' and I need to know it.
Very common, comparing yourself to the success of others.
Setting unrealistic goals just to satisfy your ego.
Was it all luck for me?

Life is not always the way you want it to be. It is inevitably working on keeping itself together. You, rushing towards something is not always an option. Life will push you back to where you belong. Slow down, step back, and look around. There's a ray of hope pointing towards you. You just don't see it for yourself. You blindfold yourself in your own little world. You decide to look away. Away from the opportunity. Away from the motivation and enlightenment.

The more you get, the more you greed on it. There's no end to what you are capable of achieving. There's no end date of when should you have all of it. There's no deadline to be something or to achieve something. It is your own unique journey. Live it to the fullest and enjoy the process. The process is what matters the most. Stop being a perfectionist!

Rushing to achieve something is not always an option. Slow down. Think it through. Plan out your journey. Stick to the plan and convert it into your reality. The plan should be feasible enough to accomplish.

It's okay to fail. It's okay to feel like a failure! It's okay to feel like you know nothing. You can always learn, grow, and excel. Just like there's no deadline to achieve something, there's no start date as well to begin the journey. Start today! Take one step at a time and track your progress. Pen down your thoughts, process, plan, and progress. _ Visualizing the progress brings consistency _.

Don't get caught in the cycle of keeping track of your failures. Stop focusing on how many times it didn't work for you. Instead, focus on how many times it did. Remind yourself of all the risks you took, all the time you made an impact, all the times you did things the right way. Change the narrative.

Seeing other's progress and success is not demotivating or discouraging. It is in fact the most encouraging thing to push yourself. It only turns into demotivation when you start the _ comparison _. The moment you compare them with yourself is when you hit the plateau. It is so evil. You tend to oversee their effort and hard work, instead focus on their results with yours.

Takeaways

It's okay to start late.

It's okay to slow down. Move at your own pace!

It's okay to feel like a failure. Learn from it, don't get demotivated.

It's okay to fail over and over again. You at least learned 10 ways that didn't work for you. Discover the 11th that does.

It's okay to feel like this. The way I felt. We all are human beings in the end. Let your emotions out and face them. Burying down yourself and your emotion is not the solution to anything. Face it and come out even stronger.

Don't be afraid to show your scars. Stay true to who you are. You can beat it eventually!

What is Azure Cosmos DB?

Parveen Singh — Fri, 11 Dec 2020 08:26:04 +0000

The modern application today requires a robust database system that is highly available, responsive. It also needs to have the ability to adapt to the changes as the demand increases and the application needs to scale in real-time. To successfully deliver those functionalities, organizations tend to use the datacenter close to their region to host those applications. Luckily, there is an Azure resource that can help you achieve those goals with more than just the functionality you need.

In this article, I'll cover the high-level introduction of Cosmos DB and some of the features that it offers. I might do a series for this topic as I did for Azure App Service where I published new things about app service every week, now reduced to bi-weekly. If you here for the first time, be sure to check back next week for more exciting stuff.

Table Of Content

What is Cosmos DB?
Use Case
Design and Services
- Design
- Services
Capabilities and Features
- Multiple API Support
- Turnkey Global Data Distribution
- Highly Available
- Consistency Models
Conclusion

What is Cosmos DB?

Azure Cosmos DB is Microsoft's NoSQLmulti-model managed database as a service offering designed to be highly available and elastic. With the vast option of configuration like consistency level, language support, API support, and flexibility, it really shines when it comes to designing the data in a form other than a relational database. You get a really comprehensive SLA for some of its core features like latency, throughput, availability, and consistency. If you are not familiar with the term 'managed', Microsoft handles all the updates, patching, and management for you so that you can focus on the actual task of leveraging the features and getting the best out of them.

You can use Cosmos DB at no charge for your first 400 RU/s and 5 GB of storage free.

Use Case

Whenever it comes to planning a database solution for an application, organizations tend to look for features like responsiveness, availability, low latency, and response time to deliver an optimal experience for the end-users. If you are somewhat familiar with the Azure environment, you might be familiar with MSSQL as a managed database instance which in most cases works for the organization, but there are cases where you need to adjust the settings to your need and leverage some additional capabilities that are offered by CosmosDB.

Design and Services

As with any other Azure resource that needs an endpoint address, you get an azure assigned DNS name for your CosmosDB that you can use to communicate to the database. The Cosmos DB design is pretty self-explanatory once you play around with the resource and test it yourself. Let's take a look at what Cosmos DB database design looks like.

Design

Databases

Cosmos DB aka 'database account' is referred to as the Cosmos DB resource in Azure itself which holds one or more databases. The database is the unit of management for a set of a cosmos container. You can have multiple databases in an account based on your requirements. There are multiple options for API to choose from for your databases like SQL API, Cassandra, MongoDB, Table API, and Gremlin. CosmosDB handles the different translation and communication for you so that you have a similar experience while working with all types of databases.

Containers

CosmosDB containers are the units inside the database that govern scalability for both throughput and storage. Containers are horizontally partitioned and then replicated across multiple regions. The items inside a container are automatically distributed based on the partition key.

Items

Item is a unique entry inside a container that holds the data as a document, node, or row. Based on the API used, the items can represent either a document in a collection, a row in a table, or a node/edge in a graph.

Services

Let's look at some common terminology used in the Cosmos DB to get more familiar with the resource.

Request Units

The cost of database operation is expressed in Request Units (RU). RU is a performance currency for the operations utilizing CPU/ Memory or IOPS. E.g. the cost to read 1 KB file or fetching a single DB item is 1 RU. All operations are assigned cost in RUs. Some of the operations that are charged in RUs are Query, Read, Insert, Upsert, and Delete.

Partitions

Partition Keys determines the item's logical distribution. Each item in a container has a unique item ID with logical partitions. It's worth noting that you can't change the partition key once the container is created. You would have to delete and recreate the container to change it.

Cosmos DB support two types of partitions, Logical and Physical Partition.

Throughput

Throughput defines a number of requests that a cosmos account can support. Currently, Cosmos DB supports two types of throughput modes, manual and auto-scale. If your resource consumes more throughput than allocated, you might face rate limitations You can either increase the throughput manually or set it to autoscale to accommodate the changing demands of the application.

Capabilities and Features

Multiple API Support

CosmosDB supports a wide variety of API support with more coming soon. It's important to note here that you need to decide what kind of API you wish to use for your database model before you deploy the resource in Azure. Currently available options are Table, SQL, Cassandra, Gremlin, and MongoDB with more coming in the near future.

Turnkey Global Data Distribution

With the increasing demand for applications to be highly responsive and always online, the instances need to be accessible with low latency. Cosmos DB supports real-time read and writes from the local replicas of the instance.

Highly Available

Cosmos DB provides high availability in two ways. The cosmos instance is replicated in the regions of your choice with 4 additional replicas per region. You can update the replication at any time using Azure Portal. It's worth mentioning that each replica can accept read and write for data usage.

Consistency Models

Databases that use replicas for high-availability, low latency or both come with some considerations around consistency on how data is served and suffer minor tradeoff between read-consistency, latency, availability, and throughput. Most popular database service only offers strong and eventual consistency, however, Cosmos DB offers five (5) different consistency models ranging from strongest to weakest as listed below:

Strong
Bounded staleness
Session
Consistent prefix
Eventual

Each level provides availability and performance tradeoffs. The strong consistency may suffer from reduced availability whereas Eventual consistency offers high availability and better performance but the data may not be completely consistent across all regions at the same time.

Conclusion

I hope that gives you a high-level introduction to CosmosDB and what it entails and some terminology used in the resource. Use Cosmos DB if your application needs to be highly available, have fast response time anywhere in the world, be always online, and need unlimited and elastic scalability of throughput.

If you get some value out of this article, follow me on this Cloud Journey on Twitter.

Azure Policy - High-Level Overview

Parveen Singh — Thu, 26 Nov 2020 07:37:15 +0000

It's exciting to build a ton of workloads in Azure but oftentimes management and control of such an environment get challenging. Negligence to actively monitor the resources results in an unmanageable environment in the cloud which usually takes hours to streamline the workloads in the testing development and production stage.

Azure Policy helps to enforce organizational standards and assess the compliance at-scale in real-time. It provides single-dashboard management for compliance and remediation for non-compliant resources with a single click. For example, you can define the deployment region and be sure that nobody is able to deploy any outside the allowed region.

Overview
Policy Types
- Policy Definitions
- Initiative Definitions
- Assignments
Permissions
Policy Evaluation
Policy Evaluation Response
Remediating Non-Compliant Resource
Recommendation for Managing Policies
Maximum Count of Azure Policy Objects
Conclusion

Overview

Azure Policies evaluate the resources in Azure by comparing the properties of those resources against business rules (definitions) defined in JSON format. You can deploy a lot of individual policies however, policy initiative simplifies the management by grouping together a lot of definitions.

Once you define your policy definitions, they are then applied to resources using various scopes including management groups, subscriptions, resource groups, or individual resources. Policy definition applies to all the resources within the defined scope.

Policy Types

Policy Definitions

Each policy definition is a JSON object. The policy's core component is its condition which defines the effect and enforcement type on any resource that's targeted by the policy. There are quite a handful of Built-In policies that you should use. Find the list of Built-In below:

[List of built-in policy definitions - Azure Policy(https://docs.microsoft.com/en-us/azure/governance/policy/samples/built-in-policies)

Each policy definition has the following elements that define the structure of the policy.

Mode – This determines which resource type will be evaluated for a policy. Supported modes are: –
- all: evaluated resource groups and all resource types
- indexed: evaluate resource types that support tags and location
Parameters – If you are familiar with any programming language you will be familiar with parameters. These parameters can be used in the logical evaluation and in the effects.

For example, below is a policy that restricts the deployment region for resources.

{
    "properties": {
        "displayName": "Allowed locations",
        "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
        "mode": "Indexed",
        "metadata": {
            "version": "1.0.0",
            "category": "Locations"
        },
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": ["westus2"]
            }
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}

Initiative Definitions

An Initiative is a collection of policy definitions that are tailored towards a single objective. Initiative simplifies the management and evaluation of multiple policies.

Azure PowerShell and Azure CLI use properties and parameters names PolicySet to refer to initiatives.

If you wish to create a custom policy definition to use as an initiative, follow the steps on the Microsoft Docs site.

Tutorial: Build policies to enforce compliance - Azure Policy

Assignments

An assignment is a policy definition or an initiative that has been assigned to a specific scope. Assignments are inherited by the child resource when applied to top-level items such as management group and subscription.

Azure Policy is an explicit deny system. If a top-level policy on a management group or subscription is set to deny any action, you won't be able to allow it specifically using policy at a resource level(child level).

You can use any Built-in policy to create a policy assignment. Before running the assignment command, get the Policy Id for your policy using the Get-AzPolicyDefinition command as shown below:

#use PowerShell to get Policy
$Policy = Get-AzPolicyDefinition -Builtin | where {$_.Properties.DisplayName -like "PolicyName"}

#Output
Name : 0473574d-2d43-4217-aefe-941fcdf7e684
ResourceId : /providers/Microsoft.Authorization/policyDefinitions/0473574d-2d43-4217-aefe-941fcdf7e684
ResourceName : 0473574d-2d43-4217-aefe-941fcdf7e684
ResourceType : Microsoft.Authorization/policyDefinitions
SubscriptionId :
PolicyDefinitionId : /providers/Microsoft.Authorization/policyDefinitions/0473574d-2d43-4217-aefe-941fcdf7e684

Use the $Policy variable as policy reference and run the command New-AzPolicyAssignment to create policy based on Built-In definitions. Scope should be in format /subscriptions/subscriptionId

$Assignment = New-AzPolicyAssignment -Name '<name>' -Scope '<scope>' -PolicyDefinitions $Policy

Permissions

Azure Policy has several permissions, known as operations, in two Resource Providers:

Microsoft.Authorization
Microsoft.PolicyInsight

Make sure you have "Owner" permission on subscription to create definitions or assignments. "Contributor" role user can only trigger the resource remediation.

Make sure you enable Azure Policy Resource Provider for your subscriptions before deploying any policies using the command below:

Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'

Policy Evaluation

Azure Policy evaluates the in-scope resources during the following times or events

A resource is created, updated, or deleted in a scope with a policy assignment
A policy or initiative is newly assigned to a scope
A policy or initiative already assigned to a scope is updated
During the standard compliance evaluation cycle, which occurs once every 24 hours.

Policy Evaluation Response

Policy definition action varies for every organization. Azure Policy uses effect as a trigger to respond to certain policy's non-compliant state. Effects are set in the policy rule within the policy definition. For example, you can limit the deployment to specific virtual machine types and sizes, or block different Azure regions from being used. You can still give developers access to the Azure environment and subscriptions but always stay in control. Below are some of the action you can perform on resources once evaluated to be non-compliant by policy definition:

Deny the resource change
Log the change to the resource
Alter the resource before the change
Alter the resource after the change
Deploy related complaint resources

Learn more about Policy Effect here:

Understand how effects work - Azure Policy

Remediating Non-Compliant Resource

While the policy effect primarily affects the resource during the creation or any update, Azure Policy also supports dealing with existing non-compliant resources without needing to alter the resources.

When Azure Policy runs in deployIfNotExists policy effect, it does the deployment using a managed identity. Azure Policy creates a managed identity for each assignment when needed. While deploying the policy assignment using Azure Portal, the setup creates the managed identity with the necessary permission automatically for you.

Managed Identity for Azure Policy

Recommendation for Managing Policies

It's always good to start with an audit effect instead of a deny effect to track the impact of your policy definition on the resources in your environment. This ensures you get enough data to collect and make decisions on enforcing policies based on business needs.
Consider organizational hierarchies when creating definitions and assignments. It is recommended to create definitions at higher levels such as the management group or subscription level. Then, create the assignment at the next child level.
While you can create individual policies for each task, it's more effective to use initiative definitions even for a single policy definition.

Maximum Count of Azure Policy Objects

There's a limit on how many policies you can deploy in a certain scope, either subscription or management group. Use the following chart as a reference.

Where	What	Maximum count
Subscription/Management Group	Policy definitions	500
Subscription/Management Group	Initiative definitions	200
Tenant	Initiative definitions	2500
Subscription/Management Group	Policy or initiative assignments	200
Policy definition	Parameters	20
Initiative definition	Policies	1000
Initiative definition	Parameters	100
Policy or initiative assignments	Exclusions (notScopes)	400
Policy rule	Nested conditionals	512
Remediation	task	Resources

Conclusion

I hope this provides you a high-level overview of Azure Policies in Azure for managing and restricting the Azure environment.

How To Clone An Azure Web App

Parveen Singh — Wed, 18 Nov 2020 04:56:09 +0000

This is the ninth article in the " Getting Started with Azure App Service" Series where I publish in-depth tutorials and walkthroughs on using Azure App Service and best practices every week. In the last article, we discussed how you can set up Easy Auth for Azure App Service.

There might be a time when you'd be using Azure App Service and think if you could make an identical copy of a web application and test it externally without affecting any production workloads. App Service clone feature is here to rescue you.

This week, we are looking at how to clone Azure App Service that you can use either for testing something on identical environment if you have a production application already, or you are simply learning what the possibilities are while using App Service. Let's dive right in!

Table of Content

Prerequisites
Cloning Web App Using Azure Portal
Cloning Web App Between Regions using PowerShell
- Cloning a Standalone Web App to New Region
- Cloning a Web App With App Slots
- Cloning a Web App to Same Region
Cloning Existing App Slot Only
Restrictions
Reference

Prerequisites

If you decide to follow along, confirm the following pre-requisites before you begin.

Be sure that you have the latest version of PowerShell installed. You can use Cloud Shell if you prefer to stay within the Azure Portal.
Your app service plan should be running on at least Standard Tier to perform the clone on the application. This operation cannot be performed on the Basic/Free Tier applications.
You need a running Web App to perform the test. Follow alone once you have a POC web application to test the following steps.

Cloning Web App Using Azure Portal

Suppose you want to move your application from Canada Central to West US, it can be accomplished using Azure Portal or PowerShell command that will create a clone of your current application in the new region.

If you prefer to use Azure Portal instead of PowerShell for the clone, follow the steps below. It's fairly easy to perform the clone in a few clicks instead of going through PowerShell.

Navigate to Azure Portal and your Web App resource.
On the left side blade, choose " Clone" option.
Use the following screenshot and the steps below to follow

Clone-GuiTrigger

Fill out the name for new web application and pick a resource group where you'd like to deploy it.
You have the option to create a new App Service Plan in either the same or different region. Create one with a name of your choice.
Under Clone Setting, make sure you enable the feature that you'd like to clone with the application.
You can turn ON the " Application Insights" optionally.

The clone should take only a few minutes and you should see new resources in your destination resource group as shown in the screenshot below.

Clone-GuiConfirmation

Cloning Web App Between Regions using PowerShell

If you are PowerShell fan, follow the instructions below to achieve the same results as with Azure Portal.

Before you run the command, you would want to confirm your application name and the resource group it resides in. Use the following command to prepare your source information of the application and replace the value of resourcegroupname and name that matches your environment names.

$srcapp = Get-AzWebApp -ResourceGroupName "RGNAME" -Name "AppName"

Once you run this command, it will store the information about your application in a variable called srcapp that we can use later to use during the clone command.

Since your new app will sit in a different region, you'd need to create an App Service Plan that matches your destination region. You can use Azure Portal to do this or follow the command below to achieve the same results. I assume the destination location to be west us. Be sure to use Standard tier as it is the minimum plan required for cloning application..

New-AzAppServicePlan -Location "West US" -ResourceGroupName "DestRGName" -Name "DestAppPlanName" -Tier Standard

Cloning a Standalone Web App to New Region

Next up is the step to perform the clone on the new application. Use the following commands to create a new web app using an existing application as a source app. Pay attention to the flag SourceWebApp as we are using that to point to the already available application.

$destApp = New-AzWebApp -ResourceGroupName "DestRGName" -Name "dest-webapp" -Location "West US" -AppServicePlan "DestAppPlanName" -SourceWebApp $srcApp

The script output should be minimal as shown in the image below:

PowerShell Results for Standalone App Clone

You should see a similar view in your account with new resources in West US.

Portal View of Standalone App Clone

Cloning a Web App With App Slots

If you have any slots configure for your application and would like to clone them as well along with the source app, use the following commands to achieve the desired results. We are only introducing one new flag IncludeSourceWebAppSlots at the end.

$destApp = New-AzWebApp -ResourceGroupName "DestRGName" -Name "dest-webapp" -Location "West US" -AppServicePlan "DestAppPlanName" -SourceWebApp $srcApp -IncludeSourceWebAppSlots

PowerShell results from the script are below:

PowerShell Results for App Slot Clone

As you can also see from the screenshot below, all the slots from the source would be available in the new region once cloned.

Portal View of App Slot Clone

Cloning a Web App to Same Region

The same steps can be performed to clone an application in same region as well. You'd still need to create a new App Service Plan and use that to host the new applications. All the steps would be similar to perform the clone as it was a different region.

Cloning Existing App Slot Only

There can be a case where you would only want to clone an app slot to either a new application or to a new slot for many different regions. The new app can be either in same or different region than the original app.

Follow through the steps below to see how you can create a new application from an existing slot. The command below takes a snapshot variable that holds the information about an existing application.

$srcAppSlot= Get-AzWebAppSlot -ResourceGroupName "SourceRGName" -Name "SourceApp" -Slot "SourceAppSlot"

Once you have the source app information in a variable srcAppSlot, you can use that to create a new application using SourceWebApp flag in the New-AzWebApp command.

#Create a new App Service Plan
New-AzAppServicePlan -Location "West US" -ResourceGroupName "DestRGName" -Name "DestAppPlanName" -Tier Standard

#Create new Web App
$destApp = New-AzWebApp -ResourceGroupName "DestRGName" -Name "DestApp" -Location "West US" -AppServicePlan "DestAppPlanName" -SourceWebApp $srcAppSlot

Here are final PowerShell results:

PowerShell Results for Slot Only Clone

You should also notice some new resources in your destination resource group now.

Verification for Slot Only Clone

Restrictions

Autoscale settings are not cloned. You would have to migration your scale settings manually if you have any.
The backup setting is tied to Web App resource which you'd need to create once the application is up and running in the new region.
VNET settings are not cloned. However, the Outbound IP address of the application will change if application is clone to different scale unit.
App Insights would have to be configured with the new web app as they don't migrate with the clone.
Easy Auth settings and Kudu Extension are not cloned.
Database content is not cloned to new application.
Unfortunately, you can only clone Windows App as of now.

Reference

If it's your first time here, please check out other articles in the series:

Part 1: Up and Running with Azure App Service

Part 2: Continuous Deployment for Azure App Service

Part 3: Using Deployment Slots with Azure App Service

Part 4: Setup Custom Domain for Azure App Service

Part 5: Deploying Next.JS App on Azure App Service

Part 6: Next.JS App with Cosmos DB on Azure App Service

Part 7: Why Should You Use Azure App Service?

Part 8: Easy Auth for Azure App Service

Part 9: How To Clone An Azure Web App?

Easy Auth for Azure App Service

Parveen Singh — Fri, 13 Nov 2020 07:16:48 +0000

This is the eighth article in the " Getting Started with Azure App Service" Series where I publish in-depth tutorial and walkthrough on using Azure App Service and best practices every week. In the last article, we discussed why you should use Azure App Service.

Authentication and Authorization for Web Application have always been a big challenge for developers and administrators as it not only requires you to develop and support the authentication but also ensures that you keep it secure from any active threats. Building the service from scratch often requires a deep understanding of federation, encryption, JSON web tokens (JWT), permission handling, and so on. An insecure authentication mechanism can fall you prey to attacks like SQL Injection, Password Spraying, Lockout policy and the list goes on...

Fortunately, App Service is here to help simplify the authentication and authorization for your web application. App Service offers all the mentioned features so that you can spend more time and energy on providing business value to your customer and worry less about handling authentication. Sounds promising?

In this article, I'll be walking you through the process of enabling Authentication using Azure AD which will secure your web app and handle the authentication process with zero code update. Let's get right into it.

Table of Content

Prerequisite
Getting Up to Speed with App Service
How Does This Work?
Setting up Authentication for Application
Testing App Authentication
Managing Permission to the Application
Conclusion
Reference

Prerequisite

If you decide to follow along the article, make sure you have the following prerequisites in place already:

Azure Portal access with active subscription
Azure App Service running a web app.
Global Admin or necessary permission to create app registration in Azure AD Tenant.

Getting Up to Speed with App Service

If you are new to Azure App Service, I'd recommend going through the other series article to get familiar with the resource and learn how to deploy your first App Service resource. For this article, I'll assume that you are already familiar with app service and understand the basic usage of the resource. Use the article below to create your app service if you don't have one already.

Continuous Deployment for Azure App Service: GitHub and Azure Repos

Make sure your App Service is running at least B1 (Dev/Test) or higher in the Production plans to support HTTPS traffic and authentication redirects.

How Does This Work?

Sign In → As the user sign in to the application, app registration handles the incoming request and delegate the federated access to App Service. By default, the endpoint for the auth page is /.auth/login/<provider> which is visible under the app registration properties that handle the authentication.

Post-authentication → As the user authenticates to the login page, the provider redirects the client to a callback URL /.auth/login/<provider>/callback that confirms the access and allows or deny the user based on the rules set up in tenant.

Establish Session → As the user is authenticated, the app service adds the authenticated cookie to the response and grant the permission to use for the application access.

Serve authenticated content → Once the user is authenticated, the subsequent requests are handled by the browser for the authentication of the client.

Check out the overview of Authentication and Authorization for web app here:

Authentication and authorization - Azure App Service

Setting up Authentication for Application

The first or the only step toward setting up the authentication is to turn on the service from the app service menu. Azure allows you to use Google, Facebook, Twitter, and Personal Microsoft Account as an authentication server however, I'll be using Azure AD Authentication as an example for this article. Follow the steps below to set up the authentication for your application.

Navigate to your App Service resource and click " Authentication/ Authorization"
Turn the Authentication " ON" and use " Azure Active Directory" as the authentication provider.

Enabling Authentication - 01

Under the Management Mode use the " Express" setting as you can create a new app registration if it doesn't exist already.
Choose " Create New AD App" so that provider can create a new app for authentication.

Express Settings for Azure AD Authentication

Click " OK" when done.
Once on the Authentication page, makes sure you update the " Action to take when the request is not authenticated" to use Azure Active Directory and click " Save".

Saving the Authentication Setup Changes

Setting the Azure AD authentication here will require authentication to website as a whole.

Just like that, you configured the Azure AD Authentication for your application without making any changes to your application at all. Let's move to the next step and verify the change now.

If you are looking to handle the authentication for particular pages or sections of the website, make sure you update your codebase to use the authentication provider URL and redirect the traffic to the authentication server as mentioned below.

<a href="/.auth/login/<provider>?post_login_redirect_url=/Home/Index">Log in</a>

I'll cover the authentication server changes inside the codebase in future articles. We'll stick with default Azure AD access, for now, to simplify the process and understand the high-level picture of the authentication setup. In the meantime, you can check out this article for more information:

Advanced usage of AuthN/AuthZ - Azure App Service

Testing App Authentication

Once you turn on the authentication for your application, it's time to access the URL and confirm the prompt for the login. Follow the steps below to confirm the login process and also address the error related to users that don't have access to the application at this point.

Navigate to the overview page of your app service and access the URL in a new tab.
As you access the website, you should be prompted to log in to your Azure account. Once authenticated, you should be able to consent the permission for your organization if you are using a Global Admin account so that other users inside the tenant don't get any permission issue.

Consent Page for App Registration

It's worth taking note that if you use a different account to login, you won't be able to access the application. I'm using an external account from a different tenant and it presents me an error saying " user account does not exist in tenant". Let's handle that in the next steps.

Error on users with no access to the app service

To allow other users to log in to this application, you need to add those users to your app registration so that they can authenticate to the Active Directory and access the web app resource. Follow the steps in the next section to see how you can add users to access the application.

Managing Permission to the Application

Follow the steps below to resolve the permission issue for non-authenticated users who don't have access to the web app.

Navigate to your Azure Portal and search for " App Registration".
Click on the app registration that you create during authentication provider setup.

App Registration for Authentication

As you can see under the " Authentication" tab that app registration uses your web app name with some additional parameters to handle the authentication at the backend for you.

Authentication URL Configuration

Under the " Overview" tab, click on the " Managed Application in local directory" which takes you to the application that handles the permission for tenant users.

Navigate to Enterprise Application that handles the permissions

Navigate to " Users and Groups" once under the enterprise application that opens with the previous link.
Add new users or preferably a security group with member users that you'd like to grant permission for your web application.

Adding users/security groups for permission

Conclusion

I hope this article helped you set up authentication for your app service web app with these simple steps and no changes to your codebase. This feature definitely works like a charm if you want to take off the authentication piece from your codebase and let Azure handle that for you either with Azure AD or third-party authentication services like Twitter, Facebook, and Google.

As always, feel free to leave a comment below or react out to me on Twitter if you have any questions.

Reference

If it's your first time here, please check out other articles in the series:

Part 4: Setup Custom Domain for Azure App Service

Part 5: Deploying Next.JS App on Azure App Service

Part 6: Next.JS App with Cosmos DB on Azure App Service

Part 7: Why Should You Use Azure App Service?

Part 8: Easy Auth for Azure App Service

Why Should You Use Azure App Service?

Parveen Singh — Tue, 10 Nov 2020 01:56:07 +0000

This is the seventh article in the " Getting Started with Azure App Service" Series where I publish in-depth tutorial and walkthrough on using Azure App Service and best practices every week. In the last article, we talked about how you can use CosmosDB with NextJS on Azure App Service

Azure platforms offer multiple cloud services including support for different programming languages, tools, and structures to help enterprises in their cloud journey. Azure App Service is one of the offerings that allow organizations to host their web workloads in a scalable and reliable fashion.

Azure App Service is a fully managed Platform as a Service (PaaS) that provides you with the tools and services needed to create reliable and scalable mission-critical Web Apps, Mobile Apps, API Apps, and Logic Apps in a single instance. It takes away your management of the host and lets you focus entirely on building your application for performance.

With the ability to develop and deploy enterprise-ready web applications, it provides powerful DevOps capabilities such as continuous integration with Azure DevOps, GitHub and Docker Hub, stage management, custom domain, and TLS/SSL. You can always integrate the app service with your on-premises resources if ever needed.

Check out some of the key features of App Service:

Multiple languages and frameworks - App Service support ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. You can always run WebJobs on your web app using PowerShell or other scripting languages.
Managed production environment - App Service is fully managed resources that take away your effort to manage, patch, update, or upgrading any underlying OS. You can spend time writing great apps and let Azure worry about the platform.
Containerization and Docker - Does the code work on your machine only? Dockerize your application and publish it on App Service. You can run multi-container apps with Docker Compos.
DevOps optimization - You can set up continuous integration and deployment with Azure DevOps, GitHub, BitBucket, Docker Hub, or Azure Container Registry. This allows you to deploy your application directly using CI/CD.
Global scale with high availability - Being a managed resource, you get the ability to scale up or out the app service resource manually or automatically. App Service allows rules to trigger the scaling for your application based on its workload metrics.
Connections to SaaS platforms and on-premises data - App Service allows you to choose from more than 50 connectors for enterprise systems (such as SAP), SaaS services, and internet services (such as Facebook). You can also access your on-premises data using Hybrid Connections and Azure Virtual Networks right within the application settings.
Security and compliance - Authentication with Azure AD and other third party authentication service make it easier for you to leverage the feature with very little change in your application code.
Application templates - If you are getting started, choose from an extensive list of application templates in the Azure Marketplace, such as WordPress, Joomla, and Drupal with very little to zero experience of deploying web apps.
Visual Studio and Visual Studio Code integration - Do you love working with Visual Studio tools? You can use Visual Studio or VS Code to create, deploy, and debug your application in real time without any additional setup.
Serverless code - Serverless fan? App Service got you! You can run code snippets or script on-demand without having to explicitly provision or manage infrastructure and pay only for the compute time your code actually uses. Check out Azure Functions or Logic App for more information on how to achieve that.

Conclusion

Start using Azure App Service today and explore the feature to see what works best for you! If you are looking for more information, check out the other articles in the series and get started with App Service.

References

Overview - Azure App Service

If it's your first time here, please check out other articles in the series:

Part 1: Up and Running with Azure App Service

Part 2: Continuous Deployment for Azure App Service

Part 3: Using Deployment Slots with Azure App Service

Part 4: Setup Custom Domain for Azure App Service

Part 5: Deploying Next.JS App on Azure App Service

Part 6: Next.JS App with Cosmos DB on Azure App Service

Part 7: Why Should You Use Azure App Service?

Deploying Next.JS App on Azure App Service

Parveen Singh — Tue, 27 Oct 2020 07:22:09 +0000

This is the fifth article in the " Getting Started with Azure App Service" Series where I publish in-depth tutorial and walkthrough on using Azure App Service and best practices every week. Last week, we talked about how you can Setup Custom Domain for Azure App Service.

I've been playing with React and some of it's popular web frameworks for some time to understand the capabilities and features it provides to run modern web applications. I stumbled upon Next.JS after researching and testing a demo application for few days and decided to publish it on Azure App Service to test some of its functionality.

I am not a react developer as you can tell by now if you have read my other blogs, but it was super simple and quick to get started with Next.JS official learn module. It took me only 3-4 hours to create an application that communicates with Cosmos DB to pull data out and display it on the homepage. (More on this in upcoming blogs -Work in Progress 😉 )

Unfortunately, things didn't go as planned and I spent an entire day trying to figure out the issue with the application after it was deployed on App Service. I started receiving an error " You do not have permission to view this directory or page". It turned out to be a trivial yet complicated issue with some missing files and an undefined Node version on App Service resource. I decided to give an overview and share with you the solution on how you can run your Next.JS application in Azure.

Table of Content

What is Next.JS?
What is Azure App Service?
Let's Talk About the Real Issue!
Prepare Your Code for Azure App Service
- Installing NodeJS
- Setting up a Sample Repo
- Adding Web.config File
- Adding Server.js File
- Updating Node Version on App Service
- Building the Code Before Deployment
Publishing Code Directly to Azure App Service
- Creating App Service using VS Code
- Deploying Application using VS Code
- Deploying Application using Azure DevOps
Conclusion

What is Next.JS?

As per Next.js official website: Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed.

If you are here for a solution on the error, I'd assume you already know a little bit or something about Next.JS. If you want to learn Next.js from basics, use this link and get started:

Create Your First Next.JS Application

What is Azure App Service?

Azure App Service is a PaaS offering by Microsoft that hosts your web service for you in a dedicated and secure host with fully automated scaling and monitoring features.

If you need more insights or you are looking to learn more about App Service, please check out my App Service Series where I am covering App Service features and exploring new capabilities every week.

Getting Started With Azure App Service Series

Let's Talk About the Real Issue!

I tried to deploy Next.JS code on my Azure App Service which of course didn't go well in the first run. Apparently, everybody is talking about running Next.js as Static Web App using GitHub Repo. Where did Azure DevOps (ADO) go?

I store all my code in ADO, so I needed some way to deploy the code using the ADO Pipeline and release it instead of storing everything in GitHub now. Looking at some GitHub and TechNet blogs under the App Service tag, I couldn't find one single fix that would work all of it.

Here's the very first issue that I encountered once the deployment was completed with out-of-box source code. Expect to see a 5xx error depending on your code and the file setup.

Error while deploying Next.JS App on Azure

I checked my log streams on app service and saw the following detailed error.

Connecting... 2020-10-27T01:02:26 Welcome, you are now connected to
log-streaming service. The default timeout is 2 hours. Change the timeout with
the App Setting SCM_LOGSTREAM_TIMEOUT (in seconds).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "<http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>">
<html xmlns="<http://www.w3.org/1999/xhtml>">
  <head>
    <title>IIS Detailed Error - 403.14 - Forbidden</title>
  </head>
  <body>
    <div id="content">
      <div class="content-container">
        <h3>HTTP Error 403.14 - Forbidden</h3>
        <h4>
          The Web server is configured to not list the contents of this
          directory.
        </h4>
      </div>
      <div class="content-container">
        <fieldset>
          <h4>Most likely causes:</h4>
          <ul>
            <li>
              A default document is not configured for the requested URL, and
              directory browsing is not enabled on the server.
            </li>
          </ul>
        </fieldset>
      </div>
    </div>
  </body>
</html>

Server Error from App Diagnostic Logs

As you can tell this is trying to list the content of the web server but the server is not configured. Running NodeJS on IIS required you to have a web.config and server.js file that can tell the IIS server where to look for files and what port to listen on.

If you encounter any 5xx error, the issue is likely to be the same but your PORT defined in the server.js might be incorrect. Follow through the end to fix the issue and make sure you have all the necessary files in your code to deploy the app.

Prepare Your Code for Azure App Service

Before you start with the setup, make sure the following requirements are met in your environment.

All the deployments are done in Azure App Service - Windows OS Only.
I won't be covering how NextJS works, rather fix the error that you will face if you deploy the code without including the necessary set of files to Azure App Service.

Installing NodeJS

The first step toward creating a Next.JS app is to download and install Node.js. Navigate to the official Node website to grab the latest package and install it on your machine.

Node JS Installation Webpage

Setting up a Sample Repo

If you are setting up a new project, you can follow along in creating a brand new project using a starter template. Run the following command in terminal to create a new project from scratch using next.js template. Source Code is also available at This GitHub Repo.

PS> npx create-next-app nextjs-blog --use-npm --example "https://github.com/vercel/next-learn-starter/tree/master/learn-starter"
PS> cd nextjs-blog
PS> npm run dev

Creating Sample Next.JS Project

This sets up the sample code that you will be using to deploy a POC application to validate and fix the permission issue. If you were to deploy your code directly to App Service at this point, you'd get the same permission issue that I described in the previous section.

Adding Web.config File

As I mentioned earlier, IIS server needs a config file that can run other necessary files to kickstart the deployment for Node application. Make sure web.config and server.js files are in the root of the directory for the webserver to trigger them during the deployment.

GitHub: singhparveen/NextJS-AzureAppService

GitHub Repo with Working Next.JS App for Azure

I've uploaded the sample project that I'm using at my GitHub repo or alternatively you can copy the code below:

<?xml version="1.0" encoding="utf-8"?>
<!--
     This configuration file is required if iisnode is used to run node processes behind
     IIS or IIS Express. For more information, visit:

     <https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config>
-->

<configuration>
  <system.webServer>
    <!-- Visit <http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx> for more information on WebSocket support -->
    <webSocket enabled="false" />
    <handlers>
      <!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
      <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
    </handlers>
    <rewrite>
      <rules>
        <!-- Do not interfere with requests for node-inspector debugging -->
        <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
          <match url="^server.js\\/debug[\\/]?" />
        </rule>

        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>
        </rule>

        <!-- All other URLs are mapped to the node.js site entry point -->
        <rule name="DynamicContent">
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          </conditions>
          <action type="Rewrite" url="server.js"/>
        </rule>
      </rules>
    </rewrite>

    <!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
    <security>
      <requestFiltering>
        <hiddenSegments>
          <remove segment="bin"/>
        </hiddenSegments>
      </requestFiltering>
    </security>

    <!-- Make sure error responses are left untouched -->
    <httpErrors existingResponse="PassThrough" />

    <!--
      You can control how Node is hosted within IIS using the following options:
        * watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
        * node_env: will be propagated to node as NODE_ENV environment variable
        * debuggingEnabled - controls whether the built-in debugger is enabled

      See <https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config> for a full list of options
    -->
    <iisnode watchedFiles="web.config;*.js"/>
  </system.webServer>
</configuration>

Web.Config File Content

Adding Server.js File

Adding Server.js or App.js is a crucial step in case of an IIS server. This ensures that the server can handle the incoming requests and you don't end up seeing any 5xx error. Use the same GitHub repo mentioned above to grab the source code for server.js file or copy the same code below:

const { createServer } = require("http");
#const express = require('express') (Only if you app uses express)
const next = require("next");

const port = process.env.PORT || 3000;
const dev = process.env.NODE_ENV !== "production";
const app = next({ dev });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  createServer((req, res) => {
    handle(req, res);
  }).listen(port, (err) => {
    if (err) throw err;
    console.log(`> Ready on <http://localhost>:${port}`);
  });
});

Server.JS File Content

Updating Node Version on App Service

Check your Node version that's running on your local computer where you built the application. Use the following code snippet in your terminal window to confirm the node version installed on your local development environment.

PS> node -v
v12.19.0

Checking Local Node Version

Before setting a value for your node version on app service, check the supported version that your App Service Server is running by navigation to the following URL while logged in to Azure. Replace the webappname with your app service name. If your version isn't listed in the support version list, choose one that is close.

https://{ ***webappname*** }.scm.azurewebsites.net/api/diagnostics/runtime

Web Address to Check App Service Plan Supported Node Version

Next step is to confirm if your app service is running the same or close to what version you have in dev environment. You will need to navigate to Azure Portal and check " Configuration" under your app service overview.

Adding Default Node Version for App Service

If you don't see any entry for Node version, Create a new application string using the following name WEBSITE_NODE_DEFAULT_VERSION with the value of version supported by your app service plan that is close to your development version.

Building the Code Before Deployment

Before you push your code to the app service, Next.JS application needs to be build beforehand so that it can generate .next folder in the root directory after packaging the code.

Open your terminal and run the following command to build your application. This will take a few seconds and your code will be ready for production.

PS> npm run build

Building Code for Production

Results of build command should look something like this:

> learn-starter@0.1.0 build C:\\Users\\UserName\\Documents\\nextjs-sample
> next build

info - Creating an optimized production build  
info - Compiled successfully
info - Collecting page data  
info - Generating static pages (2/2)
info - Finalizing page optimization

Page Size First Load JS
┌ ○ / 7.26 kB 66.3 kB  
└ ○ /404 3.44 kB 62.5 kB  
+ First Load JS shared by all 59.1 kB
  ├ chunks/framework.cb05d5.js 39.9 kB
  ├ chunks/pages/_app.af1b8e.js 1.01 kB
  └ chunks/webpack.e06743.js 751 B

)
○ (Static) automatically rendered as static HTML (uses no initial props)
● (SSG) automatically generated as static HTML + JSON (uses getStaticProps)       
   (ISR) incremental static regeneration (uses revalidate in getStaticProps)

Sample Output of Build Process

Publishing Code Directly to Azure App Service

At this point, your code is ready to deploy in Azure. If you already have an app service plan and app service running in your environment, feel free to skip the first step.

If you don't have any app service resource already, You can either create one using Azure Portal or follow the steps on creating one right within the VS Code environment. Make sure you have "Azure App Service" extension installed already.

Creating App Service using VS Code

Open your VS Code session and click on the Azure icon from the left panel. Make sure you have opened your project folder in VS Code as shown on the left side of the image below.

Right-click on your target Subscription and choose "Create New Web App (Advanced)"

Creating New App Service using VS Code

Fill out the following information as you are prompted.

**App Name** : {suggest a globally unique}
**Resource Group** : {Choose or select first option to create a new one}
**OS: Windows**
 **ASP** : {Create new App Service Plan-feel free to choose existing one if you wish to}
**Application Insights:** {Skip for now-feel free to use if you are interested}

Information to Complete New App Service Resource Creation

Deploying Application using VS Code

As the app service creation is finished, you will see a prompt confirming the deployment.

Click Deploy to publish your code to Azure.

Popup to Deploy Code to Newly Created App Service

If you don't see any prompt, simply right click on the app service name and choose Deploy to Web App.

Manual Deployment to App Service

You will be prompted to choose a folder to deploy, use the folder that contains your source code.

It'll take a minute or two to publish your code and your website will be up and running now.

Deploying Application using Azure DevOps

If you are using Azure DevOps, I've added an azure-pipelines.yml file inside the same GitHub repo that you can use to create a Pipeline in Azure DevOps. You'll need to create a release for your code and target the release to your subscription for a particular app service resource.

Use the following YAML code for your ADO Pipeline or feel free to create a similar one using GUI in ADO.

# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# <https://docs.microsoft.com/azure/devops/pipelines/languages/javascript>

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'

- script: |
    npm install
    npm run build
  displayName: 'npm install and build'
- task: ArchiveFiles@1
  displayName: 'Archive files '
  inputs:
    rootFolder: '$(System.DefaultWorkingDirectory)'
    includeRootFolder: false

- task: CopyFiles@2
  displayName: 'Copy File to: $(TargetFolder)'
  inputs:
    SourceFolder: '$(Build.ArtifactStagingDirectory)'
    Contents: '$(Build.BuildId).zip'
    TargetFolder: '$(Build.ArtifactStagingDirectory)\\ArtifactsToBePublished'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: SampleApp'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)\\ArtifactsToBePublished'

azure-pipelines.yml file sample

Conclusion

I hope you learn something new and also gained exposure to a web framework that I'm in love with now even though I started using it only a few days ago. I'd suggest making sure you include web.config and server.js files with correct information so that the App Service Plan can interpret and execute the startup for your application.

Please leave a comment below or follow me on Twitter to stay abreast of the latest updates.

If it's your first time here, please check out other articles in the series:

Part 1: Up and Running with Azure App Service

Part 2: Continuous Deployment for Azure App Service

Part 3: Using Deployment Slots with Azure App Service

Part 4: Setup Custom Domain for Azure App Service

Part 5: Deploying Next.JS App on Azure App Service

Setup Custom Domain for Azure App Service

Parveen Singh — Tue, 20 Oct 2020 19:13:45 +0000

This is the fourth article in the "Getting Started with Azure App Service" Series where I publish in-depth tutorial and walkthrough on using Azure App Service and best practices every week. Last week, we talked about how you can use Using Deployment Slots for your web app services.

If it's your first time here, please check out other articles in the series:

Part 1: Up and Running With Azure App Service

Part 2: Continuous Deployment for Azure App Service: GitHub and Azure Repos

Part 3: Using Deployment Slots with Azure App Service
Part 4: Setup Custom Domain for Azure App Service

Azure App Service provides you with a globally unique subdomain ending with "azurewebsites.net" which serves as a default site if you don't choose to customize it. It is likely that you don't want to continue using that domain if you are running in dev or production to test your application code.

In this article, we'll set up a custom domain for your web app and walk through what configuration you need to perform to set up your new domain for app service. Stick with me to the end and warm up your app service for some action!

Table of Content

Prerequisite
Configuring Custom Domain
- Choosing a Right App Service Plan
- Adding Root Domain to App Service
- Adding Subdomain to App Service
Conclusion

Prerequisite

If you decide to follow along, I'd like to address some of the pre-requisites that will help you follow the steps in the article. Make sure you fulfill the requirements listed below:

You must have an active Azure Subscription with Azure App Service resource deployed.
You must have a custom domain purchased through a domain service provider. Use THIS URL to search available domains if you don't have one already.

Configuring Custom Domain

Adding a custom domain to Azure App Service requires you to have access to your domain provider service where you will need to update DNS records to confirm that you own the domain. You can choose to use a root domain or a subdomain to redirect to your application based on your requirement. I'll be following both approaches and showing you where you can configure your custom domain.

Choosing a Right App Service Plan

Custom Domain is supported only on Basic or higher-tier plans. F1:Free tier doesn't support the custom domain or SSL to secure your web service. If your app service plan doesn't support the custom domain, you'd get an error as shown in the image below:

Click on the highlighted text to choose the right service plan for your app service. I'll be selecting the cheapest option for demo purposes to give you a glance of what's required.

Choose any plan from the listed option as it'll show you only the supported plans that include the custom domain in its feature. Hit apply once your device the plan for your app service.

Adding Root Domain to App Service

If you wish to use your root domain for app service, follow the steps below to perform the setup.

Navigate to Azure Portal and locate your App Service resource.
Click on the "Custom Domains" option on the left blade and click "+ Add Custom Domain"
Enter the full path of your domain. i.e. "pvsingh.me" in this case and click Validate.

Upon clicking validate, a new window will popup with the hostname record that you need to set up in order to verify the domain ownership.
It's worth noting that, if you choose to use your root domain, you should always configure "A Record" for your DNS.
Follow the table under "Domain Ownership" and add the entries to your DNS Server on your domain provider portal.
DNS Entries should look like this. (referencing google domain portal)
Domain entries may take some time to propagate based on your domain provider. You can check the status by clicking validate to see if the entries are synced already. Once the changes are confirmed, validation will show success, and "Add Custom Domain" will become active.

After adding the custom domain, your web app service will be instantly available on the newly configured domain.
Navigate to the URL to confirm that your application is running on the newly configured domain.

Adding Subdomain to App Service

If you choose to use a subdomain for your app service, follow the steps below and it'll get you started with using a subdomain for your application.

Navigate to Azure Portal and locate your App Service resource.
Click on the "Custom Domains" option on the left blade and click "+ Add Custom Domain"
This time, enter the subdomain you want to use and click "Validate"

As you see, you'll be prompted to use CNAME now with some entries below as before.
Fill out the DNS records on your DNS provider portal which should look something like this:

Validate the change on the Azure portal after few minutes and Add the subdomain as your custom domain.

Just like before, use the subdomain URL to validate the changes.

Your domain URL will reflect on your app service overview. This URL point to the default endpoint for your web application.

Conclusion

I hope that helped you set up a custom domain for your app service resource. I'll be writing about more exciting topics on App Service in the coming weeks. Feel free to leave out a comment or suggestions if you gain any useful information from these articles.

Using Deployment Slots with Azure App Service

Parveen Singh — Tue, 13 Oct 2020 03:53:25 +0000

This is the third article in the "Getting Started with Azure App Service" Series where I publish in-depth tutorial and walkthrough on using Azure App Service and best practices every week. Last week, we talked about how you can use CI-CD in App Service to enable DevOps capabilities for your web services.

If it's your first time here, please check out other articles in the series:

Part 1: Up and Running with Azure App Service

Part 2: Continuous Deployment for Azure App Service

Deployment slots are live applications running with their unique hostname, however, connected to a particular app service plan. Slots can reduce the overall downtime of web services by auto-swap capabilities and full integration in pipeline workflow to test and validate code changes before pushing them to production.

Suppose you have a production application at prod.example.com and you wish to test some changes in the same environment as your production application but not actually deploy the site. That's where deployment slots come and make it a seamless experience to deploy your site to a slot, call it 'staging' and your application would be running on a similar environment at different URL, prod-staging.example.com. You can test your application thoroughly before pushing it to production.

In this article, I'll be covering the basics of deployment slots and a guide on how to use them for tests and validating the code before it goes live. I'll be using a sample node js webserver to demonstrate how you can configure the slots and use them in the real world in a few simple steps.

Table of Content

Overview of App Service Slots
- App Service Plan Consideration
- Why should you use Deployment Slots?
Prerequisite
Creating an App Service Resource
Creating an App Service Slot
Setting up Deployment Center for Staging Slot
Changing Code on Local Repo
Swapping Production Slot with Staging Slot
Conclusion

Overview of App Service Slots

Since the slot creates a new app service under the same app service plan, any settings that you modify for a particular slot won't migrate to the production slot on swaps. You need to consider the changes that might occur to your application after swapping the slots. For instance, if your application uses a sandbox version of database connection in staging, make sure your code handles that scenario using app service connection strings so that it updates as the code runs in the production environment.

Below are some of the settings that are swapped along with the codebase:

General settings, such as framework version, 32/64-bit, web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Public certificates
WebJobs content

You should also consider the settings that are dedicated to a particular app service instance and never transferred on a swap. Below is a list of settings from official Microsoft docs website:

Publishing endpoints
Custom domain names
Non-public certificates and TLS/SSL settings
Scale settings
WebJobs schedulers
IP restrictions
Always On
Diagnostic settings
Cross-origin resource sharing (CORS)

App Service Plan Consideration

Choosing the right app service plan is one of the key decisions while working with app service. You don't want to end up buying more capacity and resources than necessary. To use slots for your application, you can choose any of the following plans which include Custom Domain/SSL and Slots as well which should serve your purpose even if you are running any production workloads in real-world scenarios.

Plan S1: A Series compute with 1.75GB Memory, ~82.23 CAD/Month (Estimated)
Plan P1V2: Dv2 Series compute, 3.5 GB Memory, ~103.72 CAD/Month (Estimated)

You also have a lot more options in the app service plan if you need more memory or dedicated CPUs.

Why should you use Deployment Slots?

Deployment Slots is one of the robust features available in App Service resource that enables you to run production like workload and test your code on every change before pushing the code into production. It's even more powerful when combined with CI-CD Pipeline performing the deployment, approval workflow, and automated swaps for the application slot. Below are some of the key benefits of using deployment slots.

You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deployment slots eliminate the downtime caused by some IIS applications that need to warm up before it's fully functional. The auto-swap feature gives you the capability to swap the slots automatically if the validations aren't needed.
You can always revert your application to your "last known good site" in case of any issue after code changes.

Prerequisite

If you wish to test and follow the steps in this tutorial, make sure you fulfill the following requirements:

VS Code Editor (optional): You need access to an editor, VS Code or any other editor of your choice to add/modify code for slot swap testing. This can be performed directly from Azure Repo or GitHub portal as well.
Azure DevOps or GitHub Repo: You need to store a sample app code for your app service. Clone/Fork my GitHub repo if you wish to use this as an example to test.

https://github.com/singhparveen/nodejs-plainwebapp

I'll be referencing this new app service as "staging application" and the primary app service as "production application".

Creating an App Service Resource

The very first thing you would want to do is to set up the app service with a sample webserver to test changes and perform the swap. The process includes creating an app service slot with sample code, creating a deployment slot, connecting your slot with CI-CD to enable auto-sync, making changes to the codebase, and finally triggering the slots for the swap.

Use the following steps to create a new app service if you don't have one set up already.

Using Azure Portal for App Service Deployment

Once your app service is ready, you should see a similar webpage with some generic text confirming that your application is up and running.

Creating an App Service Slot

The next thing you need to do it to create a new slot for running a staging environment. This creates a new resource with the name specified in the steps that will run your staging application. This can be done with a few clicks from the Azure Portal. Follow the instructions below to create your first app service slot:

Navigate to your Azure App Service that you created in your environment.
Click on "Deployment Slots" in the left panel and click "Add Slot" to create a new slot.

Give it a name like "staging" so that you can identify it easily.

At this point, your deployment slot is ready and you should see a new app service (slot) in your resource group as a dedicated resource that will host your code as you push it from the repository. The staging app name is given a name as "staging/" in resource group for easy identification.

Setting up Deployment Center for Staging Slot

Once you configure your staging slot, it's time to connect that slot to a git repo, whether you are using GitHub or Azure DevOps, so that any code change is deployed to staging for testing before it goes live. This process ensures that you can validate any code changes in the staging environment and then swap when changes are validated. Follow the steps below to configure your deployment source for staging slot:

Navigate to the deployment slot and click on your newly created staging slot.
Navigate to "Deployment Center" for the slot. Make sure you are working with your slot named "staging (appname/staging)"
Choose the repo location of your choice and finish the repo integration.

Give it about 5-10 mins for the deployment to finish and code to update in the app service.

Now you should start seeing your staging application running on https://appname-staging.azurwebsites.net.

Changing Code on Local Repo

The next step is to make changes to your code and push it back to your repository so that the changes can be synced and visible on staging slot. You can use VS Code or any other editor of your choice. If you are using GitHub or Azure DevOps, you can make changes directly to the file by clicking "edit" for any particular file while logged in to GitHub or Azure DevOps portal.

Open "index.js" file, if you are using "nodejs-planwebapp" from my GitHub Repo.
Add the following text at line 167/168.

If you using VS Code, run the following commands in your terminal to save and commit your code back to the remote repository.
```
PS> git add .

PS> git commit -m "Adding line-3 for staging slot"

PS> git push
```

The changes should reflect on your staging environment. If you see the changes on your staging website, Good job! Keep going through the rest of the article to finish the swap process.

Swapping Production Slot with Staging Slot

If you made it to this point, you are almost done. The last steps in here it to press "swap" button to perform the swap and observe the magic app service does in the backend to replace the production app code with staging and vice-versa. Follow along the steps explained below to finish the swap:

Navigate back to your production app and click on "Deployment Slots".
Click "Swap" option to initiate the swap process.

Select the source and target repo to deploy to and proceed with the swap.
You should see a success message saying that the swap is complete now.

The swap should take only a few seconds and your code will reflect on the production slot. You should see that your production code is swapped with a staging app and the production application is running the latest changes made to the code earlier.

Conclusion

As you saw, swapping two slots only takes a few clicks. However, it's never that simple in production running applications. Is it? 😉 You should always test your application in non-production environment before using slots for your production application as there might be little nuances that can cause trouble during the swap.

Start using Deployment Slots and let me know what you think of them in the comments below!

Feel free to send me your feedback or ideas if you'd like me to write about any particular configuration in Azure App Service.

Continuous Deployment for Azure App Service: GitHub and Azure Repos

Parveen Singh — Thu, 08 Oct 2020 04:07:20 +0000

DevOps has become a hot topic in the IT industry due to the increased demand for reducing manual efforts and operationalize the workflow using automation tools and techniques. The idea of using the DevOps strategy is to reduce the overall efforts and errors, ultimately building more scalable and stable application environments.

Continuous Integration(CI) and Continuous Development(CD) strategy has become one of the core components and best practices of building agile workloads that can support frequent updates by multiple contributors and still be able to build, test and deploy robust infrastructure.

In the last article, I introduced you to Azure App Service and explained some high-level information about its capabilities and functionalities. I'll be continuing the series and giving you in-depth tutorials on how to leverage app services to get the maximum out of its capabilities. Check out my previous article below, in case you missed it.

In this article, I'll guide you through how to create Azure App Service resources and also enable continuous deployment to leverage DevOps capabilities for your application code. Stick with me to the end and you'll see how painless and straightforward it is to enable CI/CD capabilities for your application.

Table of Content

Assumptions
Creating a Resource Group for App Service
- Creating a Resource Group using PowerShell/CLI
- Creating Resource Group using Azure Portal
Creating Azure App Service Resource
- Using PowerShell for App Service Deployment
- Using Azure Portal for App Service Deployment
Setting up Continuous Integration and Continuous Deployment (CI/CD)
- Configuring CI/CD with Azure Repos
- Configuring CI/CD with GitHub Repos
Conclusion

Assumptions

Before I begin with the configuration and deployment, I'll make some assumptions so that you can catch and prepare yourself before we being.

You should be familiar with Azure Portal and navigating inside the portal.
You should have an active account on GitHub or Azure DevOps.
You should be able to access shell.azure.com using your Azure account or be able to use PowerShell or CLI on your local computer (optional).

Creating a Resource Group for App Service

First of all, you need a resource group that will host your App Service and other dependent resources like App Service Plan and App Insights. You can choose to leverage any existing resource group if you already have one. The creation of a resource group is pretty simple and you can use either PowerShell or Azure Portal for this task as described below.

Creating a Resource Group using PowerShell/CLI

Use the following PowerShell or CLI command based on your preference. Feel free to change the resource group name and location as needed.

New-AzResourceGroup -Name "RGName" -Location "Canada Central"

## OR

az group create --name "RGName" --location canadacentral

Creating Resource Group using Azure Portal

If you are comfortable using Azure Portal, follow the steps below to create a new resource group.

Login to Azure Portal (portal.azure.com)
In the top search bar, search for "Resource Group"

Click "Add" on the next screen.

Fill the information for your resource group name and click "Review and Create". This should give you an option to create the resource group once you review the final configuration.

Once you deploy the resource group, move to the next section for some more interesting work now.

Creating Azure App Service Resource

Before setting up the CI/CD Pipeline, a Web App resource is required that'd connect with your Repository of choice for the code integration. You can deploy the necessary resources using either PowerShell or Azure Portal. I've provided the steps for both options, feel free to choose one of them to deploy the app service resources.

Using PowerShell for App Service Deployment

Creating App Service using PowerShell or CLI involves deploying dependent resources like App Service Plan before the app service itself. App Service Plan is used to host the application and its runtime environment. Follow through the steps below and be sure to change the variable names based on your resource naming convention.

$Location = "East US"
$ResourceGroupName = "ps-webcicd-rg"
$PlanName = "AppServicePlan01"
$AppName = "CICDApp-$(Get-Random)"

$Plan = New-AzAppServicePlan -ResourceGroupName $ResourceGroupName -Name $PlanName -Location $Location -Tier "Free"

$App = New-AzWebApp -ResourceGroupName $ResourceGroupName -Name $AppName -Location $Location -AppServicePlan $PlanName

Using Azure Portal for App Service Deployment

Are you a fan of using Azure Portal instead? I've got you covered!

Follow the steps below to deploy your app service resource using the Azure Portal.

Navigate to the resource group that you wish to use for your App Service resource.
Click "Add" on the top left to see the list of resources to choose from.

Choose "Web App" from the list.

Fill out the details as per your application's usage. I'll be using NodeJS with "Node 12 LTS" Runtime. Be sure to use "F1" Free tier for your application to avoid any resource cost. It's FREE of cost 😉

Finish the next steps by clicking "Review and Create".

Now with that, you deployed your web app and an app service plan from a single panel. In the next step, you'll configure the continuous deployment for the newly created app service with GitHub and Azure DevOps.

Setting up Continuous Integration and Continuous Deployment (CI/CD)

At this point, you should have your application up and running with a generic web page that you get out-of-box. The next step is to configure the deployment repo for your application. To do this, you'll be connecting the app service with GitHub using an option in the app service called "deployment center".

Before you move forward with the configuration, use the link below to copy, clone or fork my Repository that contains a sample node web application so that you have a sample code to play with during the setup. Store the code in either GitHub or Azure DevOps Repo depending on which platform you choose for connection. I'll be using this repository as a CI/CD source for the demo of both Azure and GitHub Repos.

GitHub:singhparveen/nodejs-plainwebapp

The next final step to this configuration is to enable Repo access for continuous development. To do this, you need to navigate to the newly deployed app service resource and choose Deployment Center from the left panel.

Refer to this same page whether you want to connect Azure Repos or GitHub repo. I'll be explaining both approaches from here.

Configuring CI/CD with Azure Repos

If you are connecting your Azure Repos with Azure App, make sure you have already created an Azure DevOps Organization to store your project files. Once ready, continue with the steps below.

Click on "Azure Repos" and press Continue
Azure Repo supports Azure Pipeline build which creates a pipeline and release build for you in Azure DevOps that is automatically triggered on code updates.

If you see the image below when trying to connect, you probably haven't created the Azure DevOps Organization and Projects yet. Follow the steps here to configure your Project and store repos. Once the project is configured, refresh the Azure Portal and follow the steps again to add Azure Repo for deployment center integration.

Make sure that the Account used for Azure Portal Login has permissions to the DevOps Organization as well or it won't be able to access any projects and repos.

Once the Connection is successful with the Azure DevOps, you should start seeing the Organization that you have access to and the projects within each organization.
Choose the repo that you copied or cloned earlier. Since it's a Node project, make sure you set the startup command to npm start.

Click finish when done and your application should be up and running now without much effort.

Configuring CI/CD with GitHub Repos

If you wish to use GitHub Repos instead of Azure Repo, follow the same steps to choose Deployment Center from the application blade.

Unlike last time, choose "GitHub" instead and press Continue.
You might need to authorize and allow permission to your GitHub account. Use the sign-in form when prompted to authenticate to GitHub and connect your repos with App Service.
Choose the "App Service Build Service" for your build provider as it'll compile your code automatically during deployment.

Choose the repo that you copied earlier and finish the process.

Just within a few minutes, your application should be up and running on App Service.

At this point, your application is fully integrated with App Service and any changes that you make to your code repo will be synced and changes will reflect in real-time.

Conclusion

I hope that sets you up for success with deploying CI/CD Pipeline for your Azure App Service to sync code updates to your web application without any effort during the change process.

Leave a comment down below if you liked what you read, and I will see you in the next one.

Up and Running with Azure App Service

Parveen Singh — Tue, 06 Oct 2020 05:58:40 +0000

This article was originally published at:
https://parveensingh.com/up-and-running-with-azure-app-service/

Are you still running your web servers on Linux or Windows-based VMs in the cloud? When was the last time you checked how much resources your web app is using and whether you need to scale it up or down to improve performance or save cost? Probably, not so often!

The whole point of being in the cloud is leveraging the ability to run scalable and resilient infrastructure without compromising user experience. If you are using cloud services and still practicing the traditional route of using VMs instances for development, you clearly haven't migrated to the cloud yet! Start using the services that are built for the purpose so that you uncover all the possibilities of improvement and enhancement in your application that you would not think of otherwise.

In this article, I'll be providing a high-level overview of the exact tools that you need to build modern, scalable, resilient, and redundant applications all with cost-saving in mind so that you only pay for what you use.

What is Azure App Service?

Microsoft provides a solution to host web-based services in form of application, REST APIs, or mobile backend known as Azure App Service. It's similar to a web server, but here you only focus on your code instead of updating your host for patches every other week. With the wide range of support for the language, you can deploy your application in .NET, .NET Core, Java, Python, Ruby, PHP, or Node.js. App Service support running application at scale on either Windows or Linux based environment.

App Service is the easiest way of running your application in Azure as it lets you focus on creating the application code, not on running it. Let's see what App Service can do and how it can solve your application needs.

App Service Capabilities and Functionality

Azure App Service includes a wide variety of functionality including auto-scaling, load-balancing, automated deployment, and security integration with Azure AD. As the demand for CI/CD and automation increases, App Service lets you configure those DevOps capabilities and configure the deployments using GitHub, Azure DevOps, Docker Hub, and may other sources..

Let's explore some of the core features that App Service offers and how you can leverage them to solve your business needs.

App Service Plan

As with any traditional web service, you need a hosting server where the code will be published and hosted. Azure offers that with "App Service Plan" that provides you with a fully isolated and dedicated environment to securely run your applications at a high scale. Think of this as Azure VM running in a secure environment that is fully managed by Azure.

As of today, you can choose from the following pricing tier for using an app service plan.

Shared Compute: App Service Plan offers two-tier on shared compute, Free and Shared which runs your services on the same Azure VM, sharing the underlying host instance. The resources are allocated for each customer instance that runs on the shared resource based on the chosen tier.
Dedicated Compute: If you choose to run your service on a dedicated host, you get three tiers to choose from. The Basic, Standard, and Premium tier offers you a dedicated host that hosts only the services you choose to run on top of them.
Isolated Instance: If you ever need to run your service or application without any connection or exposure to other instances in the same Azure network, Isolated Instance provides you with a fully isolated compute option running on a dedicated Azure virtual network which can integrate with your local virtual network for network-level isolation.

Operating System Support

With the mixture of Linux and Windows-based web services in the cloud, App Services also allows you to choose the type of operating systems that you need so that your application architecture doesn't suffer and it provides the same runtime environment that your application needs for your code to function properly.

Since the App Service is a managed service, you don't get direct access to the host operating systems that the apps run on. Likewise, if you are hosting a container in App Service, you still get full access to your container instance through but not the host it runs on.

Deployment Slots

Deployment Slot is one of the features in App Service that provides more value than you'd expect. It lets you create a slot for your application and act as a fully-functional version of your production application. It gives you an opportunity to test your application in your App Service environment before pushing directly to production.

Let's suppose your application takes 2-5 minutes(may vary in your case) to warm up and perform initial tasks before it's functional, you would not want your customers to wait for that long whenever a new update is released. That's where you'd use Deployment Slot by creating a new slot and switch the slot with your production app when your application is ready and running as normal. It is as simple as clicking one button to switch your slots and push your code to production.

Check out more details at the link below:

https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots?WT.mc_id=parveensingh.com

Deployment Center

Are you already using GitHub or Azure DevOps as your code repository? If yes, Integrate it right within your application and get a seamless deployment experience without any complex setup.

Deployment Center enables you to connect your Application with any repository for continuous delivery and code change updates. App Service supports continuous deployment from Azure DevOps, GitHub, and Bitbucket where app services pull the latest changes seamlessly from the source control to keep your app code up to date.

Scale Up-Out

How would you scale your application if it's running on an Azure VM? Probably shut it down and resize, right? Hold right there!

The scale-out feature has just the right configuration that you need for your application to scale automatically without even touching it. Whether you want 1 or 10 instances of your application, the auto-scaling feature provides you just that with a simple rule setup defined with pre-configured conditions that will trigger resource creation and destruction based on the workload of your application.

See what else can you do with Scaling in Azure:

https://docs.microsoft.com/en-us/azure/app-service/manage-scale-up ?WT.mc_id=parveensingh.com

Authentication and Authorization

If you are building any production running application, chances are that you are either handling the Authentication and Authorization in your code or using a third-party module to support that feature. Luckily, Microsoft provides you with direct integration of application authorization and authentication without you worrying about all the maintenance and management.

Since App Service uses the Federated Identity, you can integrate any major identity provide in your codebase like Azure Active Directory, Microsoft Account, Facebook, Google, and Twitter along with support for other OpenID Connect providers as well.

Backups

Backups are a crucial part of running the application in production where you'd want to make sure you have a safe copy of your application in case you need to roll back to the previous date. App Service provides you with an in-built option to enable backups for your application with support for one-click restore to either a different application or overwriting existing app.

Check out more in-depth information on the article below:

https://docs.microsoft.com/en-us/azure/app-service/manage-backup?WT.mc_id=parveensingh.com

Custom Domains and SSL

If you are running your application in Azure, you should set up your own domain as an entry point instead of azurwebsites.com subdomain provided by Microsoft for free. App Service allows you to either purchase a domain directly from the app service options or connect your existing domain by verifying the domain membership.

Domain Verification usually involves adding a CNAME and A record for either root or subdomain based on what you are adding. Since Shared Infrastructure is intended to be used for development only, Custom Domain is not supported in "F1 Shared Infrastructure" as you'd need to be on at least "D1 Shared Infrastructure" plan to support the customer domain and B1 Plan, if you want to bind an SSL certificate to your application.

Refer to the article below for more information:

https://docs.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain ?WT.mc_id=parveensingh.com

Application Insights

Is your application performing the way you expect it to? Well, App Service got Application Insights that you tell you exactly what you need to know from the hardware level to application-level diagnostics of your application. All it takes is to add a simple piece of code to your application and let the data come through application insights where you can monitor the real-time performance of your application. How cool is that?

Conclusion

I hope you got at least a brief overview of what Azure App Service is. I'll be covering in-depth tutorials in the coming weeks on using CI/CD Pipelines with Azure App Service.

Looking for information or article on any particular Azure Service? Leave a comment down below or reach out to me on Twitter.

Forem: Parveen Singh

Azure Cosmos DB Partitions & Partition Keys Simplified

Table of Content

Cosmos DB Partition Keys Overview

What are Containers in Cosmos DB

Logical Partitions in Cosmos DB

Physical Partitions in Cosmos DB

Replica Sets in Cosmos DB

Choosing the Right Partition Keys for Cosmos DB Account

Creating Cosmos DB Container with Partition Key using Azure Portal

Creating Cosmos DB Container with Partition Key using Azure CLI

Creating Cosmos DB Container with Partition Key using Azure PowerShell

Conclusion

Is Impostor Syndrome a Real Thing?

Takeaways

What is Azure Cosmos DB?

Table Of Content

What is Cosmos DB?

Use Case

Design and Services

Design

Databases

Containers

Items

Services

Request Units

Partitions

Throughput

Capabilities and Features

Multiple API Support

Turnkey Global Data Distribution

Highly Available

Consistency Models

Conclusion

Azure Policy - High-Level Overview

Table of contents

Overview

Policy Types

Policy Definitions

Initiative Definitions

Assignments

Permissions

Policy Evaluation

Policy Evaluation Response

Remediating Non-Compliant Resource

Recommendation for Managing Policies

Maximum Count of Azure Policy Objects

Conclusion

How To Clone An Azure Web App

Table of Content

Prerequisites

Cloning Web App Using Azure Portal

Cloning Web App Between Regions using PowerShell

Cloning a Standalone Web App to New Region

Cloning a Web App With App Slots

Cloning a Web App to Same Region

Cloning Existing App Slot Only

Restrictions

Reference

Easy Auth for Azure App Service

Table of Content

Prerequisite

Getting Up to Speed with App Service

How Does This Work?

Setting up Authentication for Application

Testing App Authentication

Managing Permission to the Application

Conclusion

Reference

Why Should You Use Azure App Service?

Check out some of the key features of App Service:

Conclusion

References

Deploying Next.JS App on Azure App Service

Table of Content

What is Next.JS?

What is Azure App Service?

Let's Talk About the Real Issue!

Prepare Your Code for Azure App Service

Installing NodeJS