DEV Community: axurcio

Custom code components - go beyond power pages limitation

axurcio — Tue, 19 Jul 2022 00:00:00 +0000

Life without code components

Power Platform has been evolving quite rapidly as Microsoft continues to invest in the area. In this article the following will be discussed:

Power Apps Portal, recently renamed to Power Pages.
Power Apps component framework (PCF), or also known as custom code components.

More and more enterprise and government customers seek to modernise their legacy applications and aim to bring everything together into one platform. Websites and portals are no exception to this. Microsoft bought ADX portal studio in 2015 and rebranded it to become the portal capability tied to Dynamics 365.

JQuery / JavaScript has been the main tool of doing portal customisation. Microsoft also introduced liquid templates for server side processing to move away from developing any custom server side (MVC) code. However, with any low code platform, sometimes clients requirements demand more to what the platform is capable of.

PCF / Custom code components

Integration with other systems can quickly becomes a challenge and Microsoft acknowledged there needs to be a better tool to develop custom code especially across different Power Platform interfaces, not just the portal.


Power Apps Component Framework

Developers have been incorporating modern JavaScript frameworks manually into the Portal JavaScript section to workaround the challenges, but fortunately Microsoft introduced Power Apps Component Framework to address the situation better, and React has been chosen as the recommended framework moving forward.

Going forward: At GA, React and Fluent UI will be the recommended and default way to create all code components. We recommend starting to evaluating React + Fluent controls for building Power Apps code components.

PCF is designed to work across every Power Platform interfaces such as Model-driven apps, Canvas apps and Portal albeit there are still differences of what is supported for each interface.

PCF for Portal used to support only field-bound forms. With the new ability of rendering PCF via liquid template, this opens a lot of possibilities as it can live outside portal forms and be rendered anywhere on the site.

Use cases examples

Payment gateway integration

External users needs to be able to do payment via chosen payment gateway while maintaining PCI compliance.
Backend office staff needs to be able to make payment on user behalf in model-driven app.

Without PCF, custom JavaScript code needs to be developed and maintained twice in both interfaces.

Large file upload integration

SharePoint document integration has a limit of 25 MB size per attachment.
Azure Blob storage has a limit of 125 MB size per attachment.

When the requirements cannot be satisfied easily (e.g. larger size or more file security), developing PCF can help to meet these requirements.

Considerations

With great power comes great responsibility

Security must always be at the back of developer’s mind while building PCF. All code inside PCF is your own code, thus Microsoft is likely not be liable for any security issues that stem from the PCF component.
As PCF is just a wrapper around your client side code, anything is visible on the browser. Any sensitive information and processing should be protected (e.g. using API integration that hides the functionality from the browser).
PCF is meant to work across all Power Platform interfaces, so avoid any unsupported workarounds such as modifying things outside the component. Microsoft has produced best practices around PCF development.
As PCF is still evolving, expect there are some things that can still pose a challenge, mainly with the integration with Dataverse (e.g. fields such as lookup is not supported yet to bind). However, with custom code there is likely to be a workaround that can be thought of.

Conclusion

For developers that come from custom development background, this is a much needed and welcoming feature of Power Platform. Low code platforms are great for rapid development and business benefits realisations, but sometimes they are still not be able to cut complex requirements easily.

Fusion development would be the reality moving forward and as Power Platform becomes more mature, there is no doubt it will be Microsoft’s greatest investment to come.

Multi-environment Cloud Infrastructure with Terraform & Azure DevOps

axurcio — Wed, 13 Jul 2022 00:00:00 +0000

We worked on a recent project where Terraform was used to provision the Azure infrastructure and I will explain the process, and how we advance towards creating a ‘Multi-environment Cloud Infrastructure’.

Multi-environment

Working on large projects requires several environments, such as DEV, SIT, UAT, PROD, etc and it is always good to have non-prod and prod as like each other as possible. It will help us in identifying the failures early and reduces the blast radius. So, a single pipeline that manages these environments with dependencies is a good way to achieve that.

Terraform

Terraform is rapidly becoming a matter of fact for creating and managing cloud infrastructures by using declarative code. It has many ways for managing multiple environments, maintaining code re-usability, resource state management, etc.

Monolithic vs Modular Terraform Configurations

Monolithic story

We started initially with a single main.tf file creating all the resources inside the root directory, managed with a single state file. That worked well, as we were only concentrated on making the things work, like creating the workspace, pipelines, variables, Azure authentication, etc. All went great, our development & test environments are up and running, automated through azure pipelines.

If you look into the above source, you can see two files, dev.tfvars and test.tfvars responsible for providing separation between the environments. Simply, you will provide dev.tfvars for provisioning your development environment and test.tfvars for the test environment. They will fill the variables.tf file with environment-specific values like resource groups, environment tags, prefix, etc.

Your terraform plan and apply commands will look like the below for the development environment and have to configure the pipeline to pass the environment-specific .tfvars file.

terraform plan -var-file="./dev.tfvars"
terraform plan -var-file="./dev.tfvars"

Pros

You can just copy-paste the .tfvars file to create any number of environments, say, for uat you just need to create a uat.tfvars file.

Cons

Complex to handle if resources are different in each environment, like, you may create only a single app service plan in development, where you may need multiple in production, etc.

Note: You will have to keep separate remote states per environment, which can be pointed through pipelines.

Modular Terraform Configurations

So, that was our monolithic story, and we always kept in mind to restructure Terraform configurations to leverage the ‘Multi-environment Cloud Infrastructure’. There are various ways to split your main.tf as it may become hard to manage as you add more environments, and a few of them are

Workspaces - Terraform CLI way to toggle between multiple environments. We didn’t choose this method, as there were a few risks including, the chances of accidentally performing operations in the wrong environments, cannot handle if environments are not like each other, etc.
TerragruntTerragrunt is a popular terraform wrapper library that solves some of these issues, keeping IaC DRY and we kept it as our secondary option for this project.
Modules & Directories - We choose this method, creating separate directories for each environment, with re-usable modules, which gave us a lot of confidence in maintaining flexibility between the environments.

Modules & Directories

Modules are terraform ways to reuse your code, and keep it DRY, helping you to create multi-environment infrastructures where code is more clean, readable, and isolated. They are directories, a block of terraform that can source directory stored “.tf” configurations and can pass variables.

We combined the concept of directories and modules to create our multi-environment cloud infrastructure where ‘each environment is isolated by directory’ and the environments can access the modules to create the required infrastructure.

The below image will show how a main.tf looks inside your network module folder

Inside your development folder, you can see a main.tf file, where you will call the required modules and pass the variables to create those modules.

We kept a .tfvars file per environment, and the advantage was, that it looked cleaner than hardcoding the resources name in your main files and made it easy to replicate the environments (just a copy-paste of your main.tf file). The major advantage was, that if you have 2 or more similar environments, you can keep a single main.tf and with environment-specific tfvar files and can configure your pipeline to pass those variables to the main.tf file.

Pipelines

All the above, explains how terraform is structured to handle multiple environments, next comes the pipeline which plays the major role in handling build and deployments into these environments.

We have used Azure DevOps Yaml Pipeline to deploy the resources, and the basic steps required in your Terraform YAML CI/CD pipeline are below.

Init - terraform validate, init, lint, tfsec etc.
Build – terraform plan
Deploy – terraform apply

We have split our YAML files to make them more readable and reusable and combined them using Azure DevOps YAML Templates

The below shows a sample terraform plan & apply pipeline deploying into multiple environments. You can configure your stage dependencies, approvals, triggers, etc in your pipelines based on your requirements inside YAML scripts.

A Guide to Azure Site Recovery - Part 2

axurcio — Mon, 20 Jun 2022 00:00:00 +0000

In the previous blog post I have elaborated the significance of Azure Site Recovery and various under the hood components that make up an Azure Site Recovery. As a continuation to it, I will cover the Onboarding of Virtual Machines to ASR and usage of Recovery Plans along with the Infrastructure as a Code practices and challenges.

Onboarding Virtual Machines for ASR

In a typical migration journey, ASR onboarding can be performed once all the technical and business validations are performed and signed off and when there is no point of rollback involved. It is critical to understand and categorize the RTO and RPO levels of the Virtual machine and services in it before onboarding into ASR. The initial replication and following snapshots will begin according to your Replication policy as soon as you associate the VM to ASR.

Switching to a different Replication policy is only possible after turning off replication which will delete all the snapshots under previous policy. Hence, initial onboarding has to be performed with right rationale. On most occasions, the recovery configuration of the VM would be same as of that of its Primary configuration. However with ASR this is configurable too.

What is a Recovery Plan?

Recovery plans helps group the VMs into recovery groups through which you can plan and define your failover. Recovery plan groups helps define the order of failover and has capability to run tasks as a part of pre or post failover. This is similar to an Onpremises DR playbook maintained by Infrastructure and Product team. While migrating your workloads, it is essential to transform these runbooks and incorporate them into Recovery plans.

Automation using Recovery Plans

Group Actions in Recovery Plans helps us to automate tasks which can reduce the overall RTO. There are two type of Group Actions.

Manual actions can be list of steps that needs to be performed in Azure or elsewhere before or after a groups of VMs are failed over or failed back. When the step is reached, User prompt with preconfigured description if any will allow the administrator to complete any manual tasks and awaits acknowledgement.
Runbook Actions are tasks that can integrate with Runbooks of Automation account. These can be tasks executed before or after a groups of VMs are failed over or failed back such as scripts on the VMs specifically like Updating Config files, registry changes etc. Runbooks have visibility to the Recovery process through the Recovery Plan context passed through ASR processes.

{
    "RecoveryPlanName":"Test-RecoveryPlan",
    "FailoverType":"Test",
    "FailoverDirection":"PrimaryToSecondary",
    "GroupId":"Group2",
    "VmMap":{
        "d8daf0e6-34a7-4608-b09d-6a3251fe5ac5":{
            "SubscriptionId":"nnnnnn-nnnnn-nnnnn",
            "ResourceGroupName":"yyy-yyy-yyy-yy",
            "CloudServiceName":null,
            "RoleName":"VM-Name",
            "RecoveryPointId":"a53eea11-4e14-462a-b5ec-e18e455dada5",
            "RecoveryPointTime":"/Date(1636597591395)/"
        }
    }
}

ASR via Infrastructure as a Code

Recovery Services Vault can be a single pane of control for ASR however under the hood there are plenty of components to be configured if it is configured and maintained via code. Typically Recovery Service Vault configuration is part of Azure Foundations and is best placed to configure.

Resource	Provider	Significance
Replication Policy	Microsoft.RecoveryServices/vaults/replicationPolicies	Configuration that details the frequency of recovery snapshots and retention of those snapshots
Replication Fabric	Microsoft.RecoveryServices/vaults/replicationFabrics	Source and Target Regions are represented as Fabrics
Replication Protection Container	Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers	Logical containers underneath Fabric to group Virtual Machines for Source and Target regions
Replication Protection Container Mappings	Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicationProtectionContainerMappings	Associates the Protection Containers to Replication Policy Ideally this has to be performed for every replication policy which we are intending to use.
Replication Network Mappings	Microsoft.RecoveryServices/vaults/replicationFabrics/replicationNetworks/replicationNetworkMappings	Maps the Source and Target Networks and vice versa

ASR Onboarding

Some of common pain areas in ASR onboarding are,

Configuration such as Disks, Specification, Resource Groups can be varying for every virtual machine.
Complex Parameters files which is hard to maintain.
If extensive parameters are not supplied, building logic via ARM, Bicep or Terraform to fetch from VMs can be challenging and will be complex to write and maintain.
Maintaining the Source Repository. Most of the foundations code comprises Recovery Services vault and teams generally do not mix up Non foundations components in it. Recommendation is maintain the ASR components excluding the foundations in a separate repository.

In efforts to solve above pain points, I found that the approach of using an Azure Powershell script as a wrapper can be highly beneficial. This preprocessing logic dynamically fetches the VM details and enables replication for the VMs chosen.

a Simple CSV file comprising Virtual Machines can be used as an input this preprocessing logic.
CSVs are easily configurable and maintainable.
Powershell is highly compatible to integrate with Azure providers.
Logic can be developed to read the specifications, disk details and formulate the details required for enabling replication.
Finally this preprocessing logic can either produce a complex parameter JSON file that can be used to deploy via ARM templates, Bicep or can run Azure cmdlets to enable replication.

Virtual Machines CSV Layouts

Column Name	Description
vmName	Name of the Virtual Machine
replicationPolicy	Name of the Replication Policy - Platinum,Gold,Silver,Bronze, NonProd depending upon RTO and RPO
resourceGroup	Name of Resource Group

ASR Onboarding Snippet

  #import CSV from vmCsvPath
  $vmCsv = import-csv $vmCsvPath
  $enableReplicationJobs = New-Object System.Collections.ArrayList

  #Enable Replication for Each VM
  foreach ($vm in $vmCsv)
  { 
   Write-output ("Processing VM: "+$vm.vmName)
   $vmName = $vm.vmName
   $sourceResourceGroup = $vm.resourceGroup
   $replicationPolicy = $vm.replicationPolicy

   Enable-Replication -vmName $vmName -replicationPolicy $replicationPolicy -sourceRg $sourceResourceGroup -targetRg $asrResourceGroup -rsvVault $rsvVault
  } 

  #Adding Os Disk
  $osDisk = New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -DiskId $vmDetails.StorageProfile.OsDisk.ManagedDisk.Id `
            -LogStorageAccountId $primaryASRStorageAccountId -ManagedDisk -RecoveryReplicaDiskAccountType $vmDetails.StorageProfile.OsDisk.ManagedDisk.StorageAccountType `
            -RecoveryResourceGroupId $targetResourceGroupId -RecoveryTargetDiskAccountType $vmDetails.StorageProfile.OsDisk.ManagedDisk.StorageAccountType 

  #Adding Data Disk
  foreach($dataDisk in $vmDetails.StorageProfile.DataDisks)
  { 
    write-output "Adding Data disks for Replication"
    $disk = New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -DiskId $dataDisk.ManagedDisk.Id `
             -LogStorageAccountId $primaryASRStorageAccountId -ManagedDisk -RecoveryReplicaDiskAccountType $dataDisk.ManagedDisk.StorageAccountType `
             -RecoveryResourceGroupId $targetResourceGroupId -RecoveryTargetDiskAccountType $dataDisk.ManagedDisk.StorageAccountType
    $rc = $diskList.Add($disk)
  }

  #Enabling Replication
  $job = New-AzRecoveryServicesAsrReplicationProtectedItem -AzureToAzure -Name $vmName -RecoveryVmName $vmName -ProtectionContainerMapping $primaryProtectionContainerMapping ` 
         -AzureVmId $vmDetails.ID -AzureToAzureDiskReplicationConfiguration $diskList -RecoveryResourceGroupId $TargetResourceGroupId `
         -RecoveryAzureSubnetName $targetSubnetName -RecoveryAzureNetworkId $targetVirtualNetworkId

Recovery Plans

Recovery plans can be simple or complex according to your Virtual machines footprint and your appetite towards automation. A complex recovery plan can have multiple groups each groups comprising a set of Virtual machines. Each group can have pre and post actions that can be either manual or automated tasks with the help of runbooks.

Now all this can be overwhelming if the configuration is maintained as parameters in JSON files. Similar to pain points in ASR onboarding, achieving a right balance between logic and flexibility in parameters will be challenging.

A preprocessing logic using Azure Powershell can again be used which can consume simple parameters in form of CSV files and build the complex JSON required for ARM template deployment.

Script to iterate the VM and Recovery plan CSV files for the recovery plan to be processed.
Identifies the grouping of the VMs and build groups by referencing the Pre and Post actions in group actions CSV file.
A JSON parameter file is finally built through this preprocessing script and can then be used to deploy via ARM template/Bicep.

Recovery Plan CSV Layouts

Column Name	Description
vmName	Name of the Virtual Machine
recoveryPlan	Name of the Recovery Plan
group	Group in Recovery Plan - 1,2,3 etc

Group Action CSV Layouts

Column Name	Description
recoveryPlan	Name of the Recovery Plan
group	Group in Recovery Plan - 1,2,3 etc
startAction	Type of Start Action - Manual, Runbook
startActionName	Name of the Start Action
startActionDescription	Description of Start Action
endAction	Type of End Action - Manual, Runbook
endActionName	Name of the End Action
endActionDescription	Description of End Action
failoverType	Type of Failover - TestFailover, PlannedFailover
failoverDirections	Direction of Failover - PrimaryToRecovery, RecoveryToPrimary

Recovery Plan Snippet


        #Create Recovery Protected Items Array
        $replicationProtArray = $vmSubset | ForEach-Object {
            $primaryFabric = get-asrfabric | Where-object {$_.FabricSpecificDetails.Location -like $primaryRegion} 
            $primaryContainer = Get-ASRProtectionContainer -Name $PrimaryContainerName -Fabric $primaryFabric
            $protDetails = Get-AzRecoveryServicesAsrReplicationProtectedItem -Name $_.vmName -ProtectionContainer $primaryContainer
            $protId = $protDetails.Id
            $vmDetails = Get-AzVM -ResourceGroupName $_.resourceGroup -Name $_.vmName 
            $vmId = $vmDetails.Id 
            [PSCustomObject]@{
                id = $protId
                virtualMachineId = $vmId 
            }

        }

        ###Start Group Action
        #Logic to transform to Manual action
        if ($action.startAction -eq 'Manual')
        {
            $startCustomDetails= [PSCustomObject]@{
                instanceType = 'ManualActionDetails'
                description = $action.startActionDescription
            }
            $finalStartAction = [PSCustomObject]@{
                actionName = $action.startActionName
                failoverTypes = [string[]] (Split-StringObject $action.failoverType)  
                failoverDirections = [string[]] (Split-StringObject $action.failoverDirections)
                customDetails = $startCustomDetails 
            }         

        }
        #Logic to transform to Runbook action 
        elseif( $action.startAction -eq 'Runbook') {
            $runbookName = $action.startActionName
            $runbookId = ($automationAccountId+"/runbooks/"+$runbookName)
            $startCustomDetails = [PSCustomObject]@{
                instanceType = 'AutomationRunbookActionDetails'
                runbookId = $runbookId
                description = $action.startActionDescription
                fabricLocation = 'Primary'
            }
            $finalStartAction = [PSCustomObject]@{
                actionName = $action.startActionName
                failoverTypes = [string[]] (Split-StringObject $action.failoverType)  
                failoverDirections = [string[]] (Split-StringObject $action.failoverDirections)
                customDetails = $startCustomDetails 
            }    
        }
        elseif( !$action ) {
            $finalStartAction = @()            
        }

        #Create Recovery Group Array
        $recoveryGroups = [PSCustomObject]@{
                groupType = "Boot"
                replicationProtectedItems = [array] $replicationProtArray
                startGroupActions = [array] $finalStartAction
                endGroupActions = [array] $finalEndAction
        }

        #create Recovery Plan Finalized Param file with Array
        $recoveryPlanfile.parameters.recoveryVaultName.value = $rsvVault

        $recoveryPlanfile.parameters.recoveryPlanName.value = "RecoveryPlan-$recoveryPlan"

        $recoveryPlanfile.parameters.recoveryGroups.value = [array] $recoveryGroupsArray

        #Convert to Json Parameters
        $recoveryPlanJson = ConvertTo-Json -InputObject $recoveryPlanfile -Depth 10

        $recoveryPlanJson | Set-Content $baseTemplatePath\"RecoveryPlan-$recoveryPlan.parameters.json"

        $DeploymentInputs = @{
                     Name = "RecoveryPlan-$recoveryPlan-$(-join (Get-Date -Format yyyyMMdd))"
                     TemplateFile = $armTemplateFile
                     TemplateParameterFile = "$baseTemplatePath\RecoveryPlan-$recoveryPlan.parameters.json"
                     Verbose = $true
                     ErrorAction = "Stop"
                   }

        New-AzResourceGroupDeployment @DeploymentInputs -ResourceGroupName $rsvRg

This marks the completion of Onboarding of Virtual machines into ASR and Recovery plans and now ready for failover as a part of DR Drills or a real life disaster situation. In the next blog post in this series, I will explain the Failover scenarios and steps along with the day 2 day operations in Azure Site Recovery.

References

A Guide to Azure Site Recovery - Part 1

axurcio — Fri, 27 May 2022 00:00:00 +0000

What is Azure Site Recovery?

Azure Site Recovery is a Disaster Recovery as a Service offering from Azure which contributes the Business Continuity and DR strategy by replicating the IaaS workloads between regions in Azure, Onpremises physical servers and virtual machines to Azure.

In this blog post, I will selectively cover the Azure to Azure Site Recovery option and discuss the various under the hood components that make up an Azure Site recovery. I will also explain the different phases of setting up a Azure Site Recovery for Disaster Recovery.

Why Azure Site Recovery in a PaaS and Containers world?

In a world fast moving towards Containers and PaaS service if anyone can wonder why would we need Azure Site Recovery here is some supporting facts. Yes, many customers and product teams move away from IaaS style workloads to PaaS services and Containers in form of Azure Kubernetes. However we still have a lot of customers and businesses who are beginning their Cloud journey having a lot of applications and services running in Virtual machines in data centres.

Cloud Enablement for these Onpremises Virtual machines quite often starts with migrations i.e Lift and Shift. The percentage of these applications getting modernised are still in low numbers. Most organisations decide to migrate as their first phase and eventually modernise/decommision the workloads in subsequent phases. Until this happens, it is important that these services are provided with a Business Continuity and DR strategy. There is also another scenario where businesses chose IaaS workloads over PaaS and Containers because of security concerns and other requirements. Virtual machines are here to stay atleast for another 10 years in my humble opinion and definitely they need a DR strategy and Azure Site Recovery is a Cloud native offering which can meet up organisational DR needs.

Enabling Azure Site Recovery

Azure Site Recovery is offered through Recovery Services Vault. Depending on the governance model, Recovery Services vault can be provisioned in a Hub if businesses are looking to centrally manage or Spoke Subscription for a more distributed type of management. Site Recovery has to be enabled though and it needs several components to be configured to complete a Site Recovery Infrastructure. Lets discuss these in below sections.

Setting up the Foundations

As a part of broader Cloud Enablement and DR strategy, businesses widely choose their Primary and Secondary regions as a part of Cloud Foundations. It is vital to define the Source and Target networks in these regions for enabling ASR. Along with the networking, there are few other components required which are explained below.

Some of the key factors to consider:

Existing or Dedicated Target network/subnets for ASR workloads.
Reserving enough IP address spaces in Target Virtual network/Subnets to accomodate failed over workloads.
Ensure networking is consistent between regions such as NSGs, Firewall rules to always accomodate Primary and Secondary Networks and inter connectivity between tiers if any (eg: Web to Data Subnet in Primary and Secondary).
Firewall and NSG rules to enable access to several PaaS services such as Storage, Automation, KeyVault that supports ASR.
Resource Groups in Target Regions.

A dedicated Cache Storage account in Primary region will have to be created as well which will be used by Azure Site recovery in replication.

Define your Replication Policies

It is very vital to understand and frame the RTO and RPO of your existing workloads through detailed assessment as a part of your broader DR strategy.

What is RTO and RPO

Recovery Time Objective is the amount of time within which the system or service must be restored in case of disaster.

Recovery Point Objective is the amount of time for which data loss is acceptable through an outage of system or service before it can significantly impact business.

Understanding the existing RTO and RPO and translating to what ASR and Azure can offer is important in framing the replication policies.

Crash Consistency Vs App Consistency

Similar to other backup and recovery services, ASR offers two type of snapshots. Crash Consistent is default to every 5 minutes and cant be modified. This is a system state snapshot and captures the data in disks. Often, most of the applications are capable to recover with these snapshots.

Application Consistency snapshots offers data consistency by capturing in memory and transactions if any in progress in addition to what Crash Consistent offers.

Snapshot Retention

Snapshot retention is another important factor as there are costs in maintaining the snapshots in form of storage.

Tiered Replication Policy

Based on the above factors, it is essential to create the replication policies. Often the business fall into tiered model such as below and some approximate numbers as an example.

Replication Policy	Snapshot Frequency (in hours)	Snapshot Retention (in days)
Gold	1	2
Silver	2	3
Bronze	3	4

This marks the completion of Recovery Services Vault configuration and is now ready to onboard the Virtual machines for replication. In the upcoming blog posts in this series, I will explain the Onboarding of Virtual Machines into ASR, Failovers and Infrastructure as a Code practices/challenges for Azure Site Recovery.

References

How to align your azure environment using right tiering strategy

axurcio — Thu, 05 May 2022 00:00:00 +0000

Microsoft Azure is one of the major cloud providers in the technology space and many enterprise and small scale customers have migrated to the azure cloud as part of their digital transformation journeys. As Azure cloud provides a bundle of services aligning to the organisations existing principles and methodologies, it’s important to align these strategies during the foundation stage for each workload to better place them in the right tier.

Every workload hosting in an organisation has a story on how it should be provisioned on the basis of certain factors such as Availability, Resiliency, Fault tolerance and Disaster Recovery and additionally in terms of Recovery Point Objective(RPO) and Recovery Time Objective(RTO) and when deployed requires a certain criteria based on the criticality and impact without comprising the cost, though placing them in the right tier is equally important.

Most of the legacy and few of the latest workloads are dependent of running on virtual machines(VMs) due to factors such as supportability, frameworks and operating systems and many others. Hence, the majority of the workload ends up running as IaaS before organisations invest in modernising them.

This criteria focuses more on Infrastructure as a Service(IaaS) and to some extent can be applied to the Platform as a Service(PaaS) services too.

Microsoft Azure provides the following services to host these workloads based on the needs of the organisation/applications.

Virtual Machines(VMs)

Azure Virtual Machines (VM) is one of several types of on-demand, scalable computing resources that Azure offers. An Azure VM gives you the flexibility of virtualization without having to buy and maintain the physical hardware that runs it.
Single Instance Virtual Machine SLA varies based on the Managed disk SKU used for Operating System and Data Disk.

Managed Disks

Azure managed disks are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines. Managed disks are like a physical disk in an on-premises server but virtualized.
Azure managed disks offer two storage redundancy options, locally-redundant storage(LRS - do support all azure regions and disk types such as HDD, SSD and Ultra Drives) and zone-redundant storage (ZRS - which is limited to specific regions and do support only premium disks now).
Managed Disks does not have a financially backed SLA itself. The availability of Managed Disks is based on the SLA of the underlying storage used and virtual machine to which it is attached, but they are designed for 99.999% availability.

Disk SKU	Operating System	Data Disk	SLA
Premium SSD or Ultra Disk	Yes	Yes	99.9%
Standard SSD	Yes	Yes	99.5%
Standard HDD	Yes	Yes	95%

Azure Backup(AB)

The Azure Backup service provides simple, secure, and cost-effective solutions to back up your data and recover it from the Microsoft Azure cloud.
Azure Backup supports multiple services such as virtual machines, Managed Disks, Azure File Shares and many others.
It guarantees at least 99.9% availability of the backup and restore functionality of the Azure Backup service.
It does support multiple types of replication to keep your storage/data highly available such as Locally redundant storage (LRS - creates 3 copies of the data in a storage unit in a datacenter ), Geo-redundant storage (GRS - replicates your data to a secondary region) and Zone-redundant storage (ZRS - replicates your data in availability zones, guaranteeing data residency and resiliency in the same region).

Azure Site Recovery(ASR)

Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Site Recovery replicates workloads running on virtual machines (VMs) from a primary site to a secondary location or within a region between zones.
For each Protected Instance configured for Azure-to-Azure Failover, it guarantees a two-hour Recovery Time Objective.

Availability Sets

Spreading the virtual machines in the availability set provides redundancy from hardware, network and storage within the same datacenter. If a disaster occured at the datacenter level, service will not be available.
All azure regions do support availability sets unlike Availability Zones.
Availability set is meant for more than 2 virtual machines to avail the advantages and there may not be identical copies of the application.
Active Directory Domain Services(On-Premises AD) service is a good example when multiple instances are running in the same region.
For all Virtual Machines that have two or more instances deployed in the same Availability Set or in the same Dedicated Host Group, we guarantee you will have Virtual Machine Connectivity to at least one instance at least 99.95% of the time

Availability Zones

Spreading the virtual machines in availability zones provides redundancy from power, cooling, and networking infrastructure across datacenters(termed as zones made up of multiple datacenters). If there is a disaster occured at the zone level, service will be provided by other active zones.
Unlike availability sets, not all azure regions support zoning. It’s important to finalise a location before provisioning the applications.
Availability Zones are meant for applications which require disaster recovery capabilities within the region or running multiple instances across zones to provide high availability to your application.
Multiple instances of a web server running in each zone is a good example of providing availability to the application. For all Virtual Machines that have two or more instances deployed across two or more Availability Zones in the same Azure region, will have Virtual Machine Connectivity to at least one instance at least 99.99% of the time.

Tiering Categories

Below are the Tiering category definitions based on tags. This can be extended further based on the requirements and below categories can be used as a good starting point to tier your services based on organisation needs. It it recommended to tag the workloads and its dependencies for easier tracking.

Tier Category	Tag Name	Tag Value	Service Availability
High Availability + Backup	Tier	0	~ Zero RPO and RTO
Disaster Recovery + Backup	Tier	1	< 5mins of RPO and < 2hrs of RTO
Backup	Tier	2	< 24hrs of RPO and < 2days of RTO
No (Disaster Recovery + Backup)	Tier	3	Based on demand

Tier Category 0

This tier is meant for services which are critical and requires high-availability and provides foundation to the later tiered services. There are multiple ways to achieve this in azure such as using availability set or availability zones or hosting multiple instances of the service across regions.

Possibilities:
- Virtual Machines - can be hosted using Availability set or Availability zone for a Virtual machine or multiple in each region
- Managed Disks - recommended to use LRS or ZRS where possible within each region
- Azure Backup - recommended to use LRS storage or ZRS where possible, GRS is not required as secondary instance will be already running across region
- Azure Site Recovery - not recommended as the service itself is running multiple instances across regions or zones

Tier Category 1

This tier is meant for services which are critical or categorised under a production environment which has challenging RPO and RTO requirements. This would be a scenario where workloads don’t want to host in high-availability mode and use disaster recovery mechanisms to recover in case of the human or nature made disaster.

Possibilities:
- Virtual Machines - can be hosted using Availability set or Availability zone for a Single Virtual machine or multiple only in one region
- Managed Disks - recommended to use LRS and ZRS where possible within one region
- Azure Backup - recommended to LRS or ZRS where possible, if backup is not required in the secondary region or use GRS based storage for all the instances if backup data required
- Azure Site Recovery - recommended to enable for all the applicable instances and create a disaster recovery plan based on application criteria

Tier Category 2

This tier is meant for services which are categorised under staging, testing and development instances and considered as non-critical services. This would be a scenario where workloads don’t want to be hosted or replicated within same or other regions in case the disaster occurs.

Possibilities:
- Virtual Machines - can be hosted using Availability set or Availability zone for a Single Virtual machine or multiple only in one region
- Managed Disks - recommended to use LRS and ZRS where possible within one region
- Azure Backup - recommended to use LRS storage, or ZRS where possible
- Azure Site Recovery - not recommended to enable replication as these are non critical workloads

Tier Category 3

This tier is meant for services which are categorised under Proof of Concept(PoC), short term duration testing or development related workloads. This would be the scenario where workloads don’t want to be backed up or replicated expecting there is no impact with the availability and can be redeployed in case required.

Possibilities:
- Virtual Machines - can be hosted using Availability set or Availability zone for a Single Virtual machine or multiple only in one region
- Managed Disks - recommended to use LRS or ZRS where possible within one region
- Azure Backup - not recommended to use any replication type
- Azure Site Recovery - not recommended to enable replication as these are non critical workloads

Addendum

Availability %	Downtime per year	Downtime per quarter	Downtime per month	Downtime per week	Downtime per day (24 hours)
99% (“two nines”)	3.65 days	21.9 hours	7.31 hours	1.68 hours	14.40 minutes
99.5% (“two and a half nines”)	1.83 days	10.98 hours	3.65 hours	50.40 minutes	7.20 minutes
99.9% (“three nines”)	8.77 hours	2.19 hours	43.83 minutes	10.08 minutes	1.44 minutes
99.95% (“three and a half nines”)	4.38 hours	65.7 minutes	21.92 minutes	5.04 minutes	43.20 seconds
99.99% (“four nines”)	52.60 minutes	13.15 minutes	4.38 minutes	1.01 minutes	8.64 seconds
99.999% (“five nines”)	5.26 minutes	1.31 minutes	26.30 seconds	6.05 seconds	864.00 milliseconds

Conclusion

It is important to have tiering strategy prior to the migration/deploying an application. Tiering strategy doesn’t just help in aliging the services to the right tier but also plays vital role in delivering the service based on the criticality. Choosing the tier based on factors such as redundancy and replication options helps also in optimising the cost of the overall solution. Hope it helps!

The Cloud Doctor

axurcio — Tue, 05 Apr 2022 00:00:00 +0000

In the past 2 years, the pandemic has taught us that keeping our immunity and health at an all time high can avoid the risk of getting the virus. However we are humans and are not perfect at all times. And we fail to do the right thing to stay immune. And so whenever we feel sick we go to the doctor and get ourselves diagnosed. How good would it be if we knew how to fix our health before it becomes an issue?

It would be so nice to have to wake up one day and have Siri, or Apple watch or Alexa saying “You are recommended to drink 12 glasses of water today because you drank only 4 glasses yesterday”. Perhaps that sort of artificial intelligence is still in the making, where your apple watch could start making recommendations to you.

A few years ago, when things were mostly on premise, services such as Health checks of a database were a standard service offered by consultancies had to be performed by a consultant by going on to the actual premises accessing the server, running the scripts and then obtaining the results. This process was cumbersome, time consuming and required manual effort. If an organization is too busy to get someone to perform this health check, and meanwhile the health of the database deteriorates and the DB crashes, then well who is responsible for the loss of data, time to retrieve the DB state and cost?

During the pandemic, fortunately many organizations have chosen to migrate to the cloud and have removed the need to host physical servers. Whilst that is a brilliant choice, we can say that gone are the days when Health checks were performed manually on the database. Thankfully do have something that looks after our platform before it turns into a disaster!

In this article we will look at Azure offerings that would constitute a virtual cloud doctor. If we imagine visiting a doctor for a health check, reviewing our vital signs such as blood sugar levels, blood pressure and temperature, they can provide recommendations based on these health statistics. We can draw parallels with our Doctor to 3 Azure services: Azure Advisor, Azure Monitoring and Azure Health.

Leveraging these 3 services together within your Azure platform provides an unrivalled trio that can give you robust monitoring, alerting capabilities and customized capabilities based on best practices! And not just that, it puts you at the top of all that is happening in your platform so that you have adequate time required to respond to an issue rather than panic in haste. This trio monitors the health of your platform, diagnoses issues and makes recommendations based on the diagnosis. It monitors availability performance, security, pricing and, discovers risks so that you can pro-actively mitigate. The following sections look at each one in detail.

1. Azure Monitoring

While the Electrocardiogram or ECG as you know it monitors the heart rate, similarly Azure monitoring is a monitoring service that provides a single pipeline for monitoring across all Azure resource types, enabling you to easily monitor, diagnose, alert, and notify of problems in your cloud infrastructure. It provides platform metrics with one minute granularity by default. This tool monitors both applications and data. So this can be a DBAs or Azure admin’s best friend! Figure 1 shows how the Monitoring options shows up when you search for it in the left panel of Azure SQL resource page.

Figure 1

Azure monitoring produces metrics of all different kinds! Figure 2 shows that Azure Monitoring service monitors the CPU utilization, Input output and Logs of an Azure SQL Database. This gives an idea of what are the peak times when a database is queried upon and when the resource was paused , unavailable or unutilized which be further drilled down.

Figure 2

The “ Line chart ” option allows you to visualize this differently. It also allows you to create an alert rule to let you know if resources are overutilized or unavailable. Later in this article we will discuss some sophisticated visualization options. Azure Monitoring not just keeps a record of the metrics at a high level, but can also tell us which queries are the ones causing high CPU / IO utilization. This feature is really good to find out if a user has kept a query running on their machine and forgotten about it.

Figure 3

2. Azure Health

We fear from our health being compromised and so we take all the vitamins required to stay fit. Similarly when there are hundreds of pipelines in the Azure environment , processing terabytes worth of data and hundreds of reports rely on that data, then the health of each resource whether it is Azure Database or storage account carries paramount importance. It is the responsibility of the Azure Health to keep you informed about the health of the services and resources. Whether is maintenance, outages and different types of issues that may impact your organisation. Azure Health offers 2 types of sub-services such as Service Health and Resource Health. One is the Resource Health that monitors a specific resource and the other is the that monitors the Azure environment.

Resource Health

Provides details about the health of individual resources in your environment, such as a virtual machine. By setting up alerts on the Resource Health you can stay informed about the availability of your resources and quickly respond to a problem if any. Azure Resource Health helps you diagnose and get support for service problems that affect your Azure resources. It reports on the current and past health of your resources. The Resource Health executes some checks, minute-by-minute, across the resources and makes the information available to you. The Resource Health is available through the Support + troubleshooting blade in the Azure portal, for the specific resource types on Azure.

Service Health

This looks after the health of Azure services and regions currently in use by your workloads. To stay informed about your Azure services, you need to setup alerts to notify you via preferred communication channels. Azure Service Health should be looked upon as a set of services. Service Health is what you will be using to get information on outages, planned maintenance, health, and security advisories.

It allows you to create customized views, filtering among subscription, region, and services. The level of details will include:

Issue Name
Subscription, service, and region impacted
Start time
Summary and issue updates
Root cause analysis
Downloadable PDF with explanations

3. Azure Advisor

In real life doctors not only diagnose an issue but also perform medical consultation. For example your dentist would recommend a suitable toothbrush and toothpaste for you depending on the situation of your teeth. Similar for the Azure environment Azure Advisor provides a set of recommendations as your personalized cloud consultant. From cost to performance to security, Azure advisor provides a suite of different categories in which it can serve you. Azure recommendations is a pro-active way to prevent something that hasn’t happened yet. This service of Azure analyses your Azure configuration and matches them against the best practices to come up with a list of recommendations. Figure 4 shows the list of recommendations for the admin to be able to action them.

Figure 4

There are many more features of Azure Advisor, Azure Monitoring and Azure Health that require in a depth explanation and would be a bit of a stretch for this blog! However before ending this blog, let’s quickly see how best the recommendations can be viewed. Figure 5 shows how recommendations from Azure can be best viewed in Power BI. Power BI being one of the finest visualization tools which also works very well with Azure to serve data , you can view recommendations all in one place with all the filters, slicers and color codes. You can also get aggregates in terms of “Total Savings” if the recommendations were followed.

Figure 5

Hope this blog has given an idea about how the Cloud Doctor works and if you need advice or assistance with Azure please feel free to approach Insight Enterprises.

Getting started with Blazor

axurcio — Mon, 28 Mar 2022 00:00:00 +0000

Blazor is a Single Page Application development framework. The name Blazor comes from the words Browser and Razor.

Blazor either runs server-side or client-side. With the server-side model it executes on a server and sends the rendered HTML and CSS to the browser. In the Blazor Server Model UI events are sent back to the server using SignalR then the UI changes are sent to the client and merged into the DOM. Blazor client-side model runs in the browser by utilising WebAssembly. It does not require any plugin installed on the browser. Since WebAssembly is a web standard, it is supported on all major browsers and devices. Code running in the browser executes in the same security sandbox as JavaScript frameworks.

Why use Blazor

The first question you would ask straight away when you hear about Blazor is why Blazor? And why not use another JavaScript framework like React or Angular. This is not an easy question to answer. JavaScript frameworks have been there for a while and gained a lot of popularity and success. I’m not trying to convince you with Blazor over other UI frameworks here, but I’m going to list the features and capabilities that attract most people to Blazor and might be good reasons for you too to start using Blazor.

.NET Experience

This might be the primary selling point of Blazor. If you are a .NET developer with no or little JavaScript experience Blazor allow you to start developing web applications without having to learn a new technology. You can use libraries or frameworks that you already use with your .NET projects as long as they are compatible with .NET Standard.

WebAssembly

WebAssembly (abbreviated Wasm) is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. In November 2017, Mozilla declared support in all major browsers after WebAssembly was enabled by default in Edge 16. The support includes mobile web browsers for iOS and Android.

JavaScript is a high-level language, flexible and expressive enough to write web applications and has a huge ecosystem that provides powerful frameworks, libraries, and other tools, whereas WebAssembly is a low-level assembly-like language with a compact binary format that runs in the browser with near-native performance.

Blazor supports JavaScript interoperability. Using Blazor does not mean “No JavaScript”. You can still call JavaScript functions from .NET apps and vice versa.

Code Reusability

With Blazor you are using .NET throughout your different application layers. Developers in your team can easily work with backend or frontend. This means that you can reuse code between your backend and frontend, use your common libraries across application layers and share API models. Think about utilities like string formatters, DateTime helpers, cryptography and a lot more. You can now have one library that you can use across all different projects - backend or frontend.

Server-side Rendering

One of the primary requirements that you would frequently be asked for when developing SEO friendly websites is server-side rendering. Server-side rendering is important when you build applications intended to be crawled by search engines as it allows bots to crawl your website contents without having to execute JavaScript code. By using Blazor, server-side rendering is included as standard.

Blazor WebAssembly vs. Blazor Server

Blazor WebAssembly

In Blazor WebAssembly (or the client-side hosting model) the application runs directly in the browser on WebAssembly. So, the compiled application code itself, dependencies and the .NET runtime are downloaded to the browser. This means that the application will need some time to download and load the application and dependencies assemblies at start-up. However, this means the app remains functional if the server goes offline.

Reference: ASP.NET Core Blazor hosting models

Blazor Server

In Blazor Server (or the server hosting model) the application is executed on the server from within an ASP.NET Core application. Between the client and the server, a SignalR connection is established. When an event occurs on the client such as a button click the information about the event is sent to the server over the SignalR connection. The server handles the event and the generated HTML. The entire HTML is not sent back again to the client, it’s only the diff that is sent to the client over the established SignalR connection. The browser then updates the UI.

Because code run on the server, the initial load is much faster than Blazor WebAssembly. The application can take advantage of server capabilities such as .NET Core APIs which allows utilizing the existing tooling such as debugging. However, the main concern with using this model is the high latency as every user interaction will require a network hop and this means also that there is no offline support.

Reference: ASP.NET Core Blazor hosting models

Create your first app

In this article, we’ll go through the steps of how to create and deploy a Blazor WebAssembly app. There are two types of Blazor WebAssembly apps, stand-alone and hosted models.

Standalone is suitable when you intend to deploy your app without an ASP .NET Core app to serve it, for example hosting the app on IIS server or Azure App Service (windows).

Hosted the app uses an ASP.NET Core server to host the client App which gives you the flexibility to host it in Azure App Service (Windows or Linux) and allow you to share code between client and server apps.

In this article, we’ll be using hosted Blazor WebAssembly.

Create the project

Visual Studio Code

For the command line run the following:

dotnet new blazorwasm --hosted -o FirstBlazorApp

Visual Studio

From Visual Studio Choose Blazor WebAssembly App template and make sure ASP.NET Core hosted option is selected.

Now open the project in your favourite editor and you will get the following folder structure:

You will have three projects created in your solutions.

Shared a class library project referenced by both Client and Server and the purpose of this project is to include all the code shared between the client and server such as API models.
Client the Blazor WASM project. It has all the code required to run your Blazor client App.
Server an ASP.NET Core project. You can create your APIs in this project which will run in the same environment as your client app. This app also acts as a host server to run your client app. This is enabled in the Program.cs file by a simple line: app.UseBlazorFrameworkFiles();

Run the project

To run the project:

Go to Client folder (if you want to run the standalone client without the server) or Server folder (if you want to run both server and client).
Run this command to start the app dotnet run
From the browser navigate to http://localhost:5173/

Walkthrough

Under Client folder we have the following:

_imports.razor contains all the namespaces imported and used by the project.
App.razor is the main component of the app. It has the Router component which loads all the pages inside the RouteView component. If the URL was not found the app displays the template in NotFound component.

<Router AppAssembly="@typeof(App).Assembly">
  <Found Context="routeData">
    <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
    <FocusOnNavigate RouteData="@routeData" Selector="h1" />
  </Found>
  <NotFound>
    <PageTitle>Not found</PageTitle>
    <LayoutView Layout="@typeof(MainLayout)">
      <p role="alert">Sorry, there's nothing at this address.</p>
    </LayoutView>
  </NotFound>
</Router>

wwwroot has the client-side assets and styles. In Blazor WebAssembly index.html is the main entry point to the application. You can add any CSS or JavaScript references to this page. You can also redesign how the loading page should look during the initial load.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"
    />
    <title>FirstBlazorApp</title>
    <base href="/" />
    <link href="css/bootstrap/bootstrap.min.css" rel="stylesheet" />
    <link href="css/app.css" rel="stylesheet" />
    <link href="FirstBlazorApp.Client.styles.css" rel="stylesheet" />
  </head>

  <body>
    <div id="app">Loading...</div>

    <div id="blazor-error-ui">
      An unhandled error has occurred.
      <a href="" class="reload">Reload</a>
      <a class="dismiss">🗙</a>
    </div>
    <script src="_framework/blazor.webassembly.js"></script>
  </body>
</html>

Shared Under Shared folder, you will find the MainLayout.razor and all other shared components. MainLayout has been set as the DefaultLayout in the App.razor.
Pages Under pages, you will find the components which will be rendered inside the MainLayout. In the page component, there are three main pieces you need to understand:
- @page directive which defines the route Url for the current page
- PageTitle overrides the application page title.
- @code block allows you to write your code in the same file with the razor template.

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code { 
    private int currentCount = 0; 

    private void IncrementCount() 
    {
        currentCount++; 
    } 
}

Code-behind

As you can see in the previous example both the HTML markup and the C# code exist in the same file, which makes it easy and simple to build components in Blazor. However, as the business grows and requirements get bigger and more complex, splitting the code into a Code-behind file might be a good idea to keep the code clean and easy to maintain.

Splitting Blazor’s component code into a separate file is easy as all .razor files become classes when the project is compiled. For example, the code inside the Counter.razor file gets extracted into a class called Counter when compiled.

To move the code inside a component into a separate class there are two methods to achieve that:

Partial Class

To create a partial class for the Counter component, create a new class file and call it Counter.razor.cs then add the following code to it:

namespace FirstBlazorApp.Client.Pages;
public partial class CounterComponent
{
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Now, you can remove the code block from Counter.razor and build the project and you’ll find that it builds successfully with no errors.

Inheriting ComponentBase class

Instead of creating a partial class for your components, you can create a class that inherits from ComponentBase class. You can then remove the code block from the .razor file and use the @inherits directive to inherit from the class you have just created.

Note that in this method you need to modify access modifiers from private to protected to be able to access them from the .razor file.

Because the class inherits from ComponentBase, another benefit you get is that you have access to the component’s lifecycle methods such as OnInitializedAsync().

You can find more details about component lifecycle in the following article: ASP.NET Core Razor component lifecycle

Counter.razor.cs

using Microsoft.AspNetCore.Components;
namespace FirstBlazorApp.Client.Pages;
public class CounterComponent : ComponentBase
{
    protected int currentCount = 0;

    protected void IncrementCount()
    {
        currentCount++;
    }

    protected override Task OnInitializedAsync()
    {
        return base.OnInitializedAsync();
    }
}

Counter.razor

@page "/counter"
@inherits CounterComponent

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

Scoped styles

Blazor supports scoping CSS to Razor components, which can simplify CSS and avoid collisions with other components or libraries.

To enable CSS isolation is simple. Create a .razor.css file matching the name of the .razor component file in the same folder. For example, to create isolated CSS for the Counter component create a file called Counter.razor.css in the same folder as Counter.razor file.

The styles defined in Counter.razor.css are only applied to the rendered HTML of the Counter component.

For more details about Blazor CSS isolation see the following article:

ASP.NET Core Blazor CSS isolation

Writing unit tests

In unit tests, only the Razor component (Razor/C#) is involved. External dependencies, such as services and JS interop, must be mocked.

There’s no official Microsoft testing framework for Blazor, but Microsoft recommendsusing bUnit which provides a simple and easy way to unit test Razor components.

The good news is that bUnit works with common testing frameworks, such as MSTest, NUnit, and xUnit which makes bUnit tests feel like regular unit tests.

Let’s go through the steps of how to start writing unit tests with bUnit using xunit testing framework:

Create a xunit test project by running: dotnet new xunit -o FirstBlazorAppTests
Under FirstBlazorAppTests add reference to FirstBlazorApp project: dotnet add reference ../Client/FirstBlazorApp.Client.csproj
Add the following NuGet packages: dotnet add package bunit.web dotnet add package bunit.xunit
Now you can start writing unit tests as you would normally do with any .NET project

The following is an example of a test class for the Counter component:

using Bunit;
using Xunit;
using FirstBlazorApp.Client.Pages;

namespace FirstBlazorApp.Tests;

public class CounterComponentTests
{
    [Fact]
    public void CounterComponentTest()
    {
        // Arrange: Render the Counter component
        using var ctx = new TestContext();
        var cut = ctx.RenderComponent<Counter>();

        // Act: Find and click the <button> element
        cut.Find("button").Click();

        // Assert: Find the <p> element, then verify its content
        cut.Find("p").MarkupMatches(@"<p role=""status"">Current count: 1</p>");
    }
}

For more details about bUnit see the official bUnit documentation:

Testing Blazor components

Deploy the Blazor app

In Blazor Server model a web server capable of hosting an ASP.NET Core app is required in order to run your Blazor app. However, in Blazor WebAssembly there are two deployment strategies:

Standalone deployment The app is hosted on a static web server where .NET is not used to serve the app. Any static file server can host the Blazor app.
Hosted deployment The app is served by an ASP.NET Core app that runs on a web server. As you can see in the previous example, we have two main Projects (Client and Server). The Client project produces the static files required to run the app whereas the Server project contains the ASP.NET Core app that acts as a small server to host the client app.

Deploy to Azure App Service

You can publish and deploy the Blazor app directly from VS Code which is a convenient and efficient way to deploy Blazor apps during the development process. However, for production, you should always consider using Continuous Deployment to deploy your apps.

Deploy from VS Code

Let’s go through the steps for how to deploy FirstBlazorApp that we have just created to Azure App Service using VS Code.

Install Azure App Service extension and configure it: Azure App Service VS Code Extension.
Publish the app. When you deploy Blazor WASM to Azure App Service windows you can use both strategies (Standalone or Hosted), however, if you wish to host the app on Azure App Service Linux you won’t be able to use the Standalone strategy.
1. Standalone deployment (windows): Publish the Client app to generate the deployment package: dotnet publish Client -c Release -o ./publish
2. Hosted deployment (Windows or Linux): dotnet publish Server -c Release -r linux-x64 -o ./publish
Now right click on the publish folder that has been just created and select Deploy to Web App…

Deploy from Azure DevOps

Finally, we’ll go through the steps of how to configure Azure DevOps pipelines to build, test and deploy our FirstBlazorApp to Azure App Service. To do so:

First, push your code to a new repository.
From the Azure Portal create an Azure App Service and set the runtime stack to .NET 6.
Go to Azure DevOps and create a new pipeline.
Select your code repo and proceed to the Review step.
Go to Project Settings > Service connections and create a new service connection then select Azure Resource Manager type then choose Service Principal (automatic) and set scope level to subscription.
Click Variables and add the required variables
- AzureServiceConnection The name of the Service connection created in the previous step.
- ResourceGroup The name of the resource group where your app service is created.
- WebAppName The name of the App Service to deploy the app to.
Paste the following YAML then click Save and Run

trigger:
  - main

pool:
  vmImage: ubuntu-20.04

variables:
  buildConfiguration: "Release"
  dotNetVersion: "6.0.x"
  location: "australiaeast"
  dotNetFramework: "net6.0"
  webAppDir: "$(Build.SourcesDirectory)/Server"
  webAppTestDir: "$(Build.SourcesDirectory)/Tests"

steps:
  - task: UseDotNet@2
    displayName: Use .NET 6.0
    inputs:
      packageType: "sdk"
      version: "6.0.x"

  - script: dotnet build --runtime linux-x64 --configuration $(buildConfiguration)
    workingDirectory: "$(webAppDir)"
    displayName: "Building App..."

  - task: DotNetCoreCLI@2
    displayName: "Testing App..."
    inputs:
      command: test
      projects: "$(webAppTestDir)/*.csproj"
      arguments: "--configuration $(buildConfiguration)"
      publishTestResults: true

  - task: DotNetCoreCLI@2
    displayName: "Publishing App..."
    inputs:
      command: publish
      workingDirectory: "$(webAppDir)"
      publishWebProjects: false
      zipAfterPublish: True
      arguments: "--runtime linux-x64 --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)"

  - task: AzureRmWebAppDeployment@4
    displayName: "Azure App Service Deploy"
    inputs:
      azureSubscription: "$(AzureServiceConnection)"
      ResourceGroupName: "$(ResourceGroup)"
      appType: webAppLinux
      WebAppName: "$(WebAppName)"
      Package: "$(Build.ArtifactStagingDirectory)/**/*.zip"

References

Managing the Azure Virtual Desktop Gold Image - Virtual Desktop Series Post 1

axurcio — Mon, 28 Mar 2022 00:00:00 +0000

Azure Virtual Desktop is a Desktop-as-a-Service solution provided by Microsoft running on Azure. The Azure Virtual Desktop (AVD) session management control plane is entirely managed by Microsoft. As this is often the most complex aspect of implementing a Virtual Desktop Infrastructure (VDI) solution, AVD dramatically lowers the technical and financial barriers to entry for those who are on the fence about investing in a VDI solution.

Typically, solution architects and IT administrators begin planning a VDI deployment working out how they will network, configure and deploy all of the infrastructure and services in order to implement a functional solution. AVD enables IT administrators to create a functional host pool from a Virtual Machine (VM) image from a single wizard. This is a huge time and cost saving, however there is still one technical aspect of an AVD deployment that needs to be considered prior to deploying a host pool: the Gold Image.

What is a Gold Image?

A VDI Gold Image contains all software and profile management pre-configuration to deploy several identical VMs for users to log into. In this article I will describe the process for creating a VM to be used as a Gold Image, Capturing a VM to an image stored in a Compute Gallery, and finally, referencing a new Gold Image from the Host Pool configuration wizard.

Azure Compute Gallery

The first step is to create the Azure object that can hold VM Images. While these can be stored in a Storage Account, it is highly recommended to make use of the Azure Compute Gallery. The Azure Compute Gallery lets you share custom VM images and application packages with others in an organization, within or across regions, or within an AAD tenant. Images in the Compute Gallery are version controlled. Image replicas (single or cross-region) reduce throttling during VM creation where multiple simultaneous deployments or cross-region deployments would overload a single replica. The Compute Gallery is free to create, however storage costs of each image replica, and for network egress to replicate the image to other regions are chargeable. Source: Store and share images in an Azure Compute Gallery

There are limits, per subscription, for deploying resources using Azure Compute Galleries:

100 galleries , per subscription, per region
1,000 image definitions , per subscription, per region
10,000 image versions , per subscription, per region
10 image version replicas , per subscription, per region
Any disk attached to the image must be less than or equal to 1TB in size

Source: Store and share images in an Azure Compute Gallery - Limits

Create the Gold Image VM

Secondly, a VM will need to be created in an Azure Resource Group that will be converted into the Gold Image. The type of AVD deployment that is being considered will determine which Azure Marketplace image is used to create the Gold Image VM.

The key consideration is the difference between Personal and Pooled Desktops

Personal Desktops - A VM allocated per user

Ideal for single-session users with heavy performance requirements
Choose the right VM to run robust apps like CAD, SAP and others
Always-on experience and single state retention

Pooled Desktops - Multiple users allocated to the same VM

Ideal for users with light to medium workloads with basic business requirements
Choose the right VM to run most business apps

Pooled Desktops allow multiple users to share a single VM’s resources. A Pooled Desktop Gold Image will need to user Multi-Session Windows 10 Marketplace image. For high performance users using Personal Desktops with dedicated VM resources, the standard Windows 10 Marketplace image can be used.

See below for an ARM Template excerpt when creating a Multi-Session Windows 10 VM to use as your Gold Image. Note the imageReference SKU below “win10-21h2-avd-g2”. For personal desktops, use the “21h1-ent-g2” SKU instead. Ensure that if you use the Generation 2 VM images or Accelerated Networking that these parameters need to be reflected across all script blocks from this post.

{
    "name": "[parameters('virtualMachineName')]",
    "type": "Microsoft.Compute/virtualMachines",
    "apiVersion": "2021-07-01",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Network/networkInterfaces/', parameters('networkInterfaceName'))]"
    ],
    "properties": {
        "hardwareProfile": {
            "vmSize": "[parameters('virtualMachineSize')]"
        },
        "storageProfile": {
            "osDisk": {
                "createOption": "fromImage",
                "managedDisk": {
                    "storageAccountType": "[parameters('osDiskType')]"
                },
                "deleteOption": "[parameters('osDiskDeleteOption')]"
            },
            "imageReference": {
                "publisher": "MicrosoftWindowsDesktop",
                "offer": "Windows-10",
                "sku": "win10-21h2-avd-g2",
                "version": "latest"
            }
        }
    }
}

The next step is to log into the VM and run updates, install corporate software, configure licensing, and set up your profile management solution (FSLogix configuration for AppMasking and Profile Management will be covered in a future post). Tools such as SCCM and Azure Automation can used to deploy software to the VM in an automated fashion. Azure DevOps Pipelines be used to trigger an Automation runbook for automated software deployment. Once ready, shut down and deallocate the VM.

Prepare the Gold Image VM

When an image is created using PowerShell, the Operating system state can be set to either Generalized or Specialized. Generalized images clear configuration for hostname, users and osProfile on the VM. These means that when multiple VMs are created from the one image, their admin user and hostname are configured during deployment which is what we need for an AVD Gold Image. After generalizing a VM, the VM becomes unusable. Before generalizing, you can take a Snapshot of the VM or take a backup using a Recovery Services Vault. You can then restore the VM from the Snapshot or backup to make edits to your Gold Image for a future image version. If you joined your Gold Image VM to a domain, you should remove it from the domain before Generalizing. Create a PowerShell .ps1 with the following code:

If (Test-Path -Path C:\Windows\Panther) {
  Remove-Item C:\Windows\Panther -Recurse -Force
}
cmd.exe /c "start /b %WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe"

These Azure CLI scripts will take a Snapshot of and Generalize the VM. The script you have just created will be referenced by the parameter –scripts below.

#Set the subscription Id
az account set --subscription $subscriptionId

#Get the disk Id
$diskId=$(az disk show --name "AVD_GOLD_IMAGE_0_0_1" --resource-group "AVD-DEMO" --query [id] -o tsv)

#Create the VM Snapshot
az snapshot create -g "AVD-DEMO" -n "AVD_GOLD_IMAGE_0_0_1" --source $diskId --hyper-v-generation "v2" --sku "Premium_LRS"

#Generalize the VM before creating an Image
az vm run-command invoke --command-id "RunPowerShellScript" --name "AVD_GOLD_IMAGE" -g "AVD-DEMO" --scripts "@C:\path\to\script.ps1"

#Deallocate VM
az vm deallocate -g "AVD-DEMO" -n "AVD_GOLD_IMAGE"

#Mark VM as Generalized
az vm generalize -g "AVD-DEMO" -n "AVD_GOLD_IMAGE"

Restore the Gold Image VM for image versioning

Use the following Azure CLI script to create a new Gold Image VM from the snapshot when you need to update your Gold Image. Ensure that the –size-gb parameter is the same size or greater than your Gold Image disk.

#Set the subscription Id
az account set --subscription $subscriptionId

#Get the snapshot Id
$snapshotId=$(az snapshot show --name "AVD_GOLD_IMAGE_0_0_1" --resource-group "AVD-DEMO" --query [id] -o tsv)

#Create a new Managed Disks using the snapshot Id - MAKE SURE SIZE MATCHES SNAPSHOT
az disk create --resource-group "AVD-DEMO" --name "AVD_GOLD_IMAGE_OsDisk_1" --sku "Premium_LRS" --size-gb 128 --hyper-v-generation "v2" --source $snapshotId 

#Create VM by attaching created managed disks as OS
az vm create --name "AVD_GOLD_IMAGE" --resource-group "AVD-DEMO" --attach-os-disk "AVD_GOLD_IMAGE_OsDisk_2" --os-type "Windows"

Capture the Gold Image VM to Compute Gallery

The final step is create a Shared Image to be stored in the Compute Gallery. The information required for creating an image is:

The name of the Image
The name of the Compute Gallery
The name of the Resource Group the Compute Gallery resides in
The resource ID being used to create the image
The OS Type (Windows or Linux)
The OS State for the image (Specialized or Generalized)
The user-defined version number for the image

The best practice version number convention for images is MajorVersion.MinorVersion.Patch. A VM image can also be replicated to multiple regions for redundancy and faster provisioning of desktops in that region.

See below for an AzureCLI sample for creating a Compute Gallery image from a VM. Be sure to set –hyper-v-generation to v2 for Generation 2 VMs.

az sig image-definition create --resource-group "AVD-DEMO" \
--gallery-name "AVD_GALLERY" --gallery-image-definition "AVD_GOLD_IMAGE" \
--publisher "MicrosoftWindowsDesktop" --offer "Windows-10" --sku "win10-21h2-avd-g2" \
--os-type "Windows" --os-state "Generalized" --hyper-v-generation V2

az sig image-version create --resource-group "AVD-DEMO" \
--gallery-name "AVD_GALLERY" --gallery-image-definition "AVD_GOLD_IMAGE" \
--gallery-image-version 0.0.1 \
--managed-image "/subscriptions/xxx/resourceGroups/AVD-DEMO/providers/Microsoft.Compute/virtualMachines/AVD_GOLD_IMAGE" \
--target-regions "australiaeast=premium_lrs australiasoutheast=premium_lrs" --storage-account-type "Premium_LRS"

See below for a Terraform sample for creating a Compute Gallery image from a VM. Use terraform import to import the Resource Group, Virtual Network, Subnet, Network Interface and Virtual Machine if already created.

resource "azurerm_shared_image_gallery" "example" {
  name = "AVD_GALLERY"
  resource_group_name = azurerm_shared_image_gallery.example.name
  location = azurerm_resource_group.example.location
}

resource "azurerm_shared_image" "example" {
  name = "AVD-GOLD-IMAGE"
  gallery_name = azurerm_shared_image_gallery.example.name
  resource_group_name = azurerm_resource_group.example.name
  location = azurerm_resource_group.example.location
  specialized = false
  os_type = "Windows"
  hyper_v_generation = "V2"

  identifier {
    publisher = "MicrosoftWindowsDesktop"
    offer = "Windows-10"
    sku = "win10-21h2-avd-g2"
  }
}

resource "azurerm_shared_image_version" "example" {
  name = "0.0.1"
  gallery_name = azurerm_shared_image_gallery.example.name
  image_name = azurerm_shared_image.example.name
  resource_group_name = azurerm_resource_group.example.name
  location = azurerm_resource_group.example.location
  managed_image_id = azurerm_virtual_machine.example.id

  target_region {
    name = azurerm_resource_group.example.location
    regional_replica_count = 1
    storage_account_type = "Standard_LRS"
  }
}

Now for the final step. You can now incorporate the Compute Gallery image into the Host Pool ARM template. See below for the relevant configuration changes to the sessionHostConfigurationImageCustomInfoProps section and the imageInfo section within the sessionHostConfigurations section of the Host Pool ARM Template.

"sessionHostConfigurationImageCustomInfoProps": {
    "resourceId": "/subscriptions/xxx/resourceGroups/AVD-DEMO/providers/Microsoft.Compute/galleries/AVD_GALLERY/images/AVD-GOLD-IMAGE/versions/0.0.1"
}


{
    "name": "default",
    "apiVersion": "[parameters('apiVersion')]",
    "type": "sessionHostConfigurations",
    "dependsOn": [
        "[resourceId('Microsoft.DesktopVirtualization/hostpools/', parameters('hostpoolName'))]"
    ],
    "properties": {
        "vmSizeId": "[parameters('vmSize')]",
        "diskInfo": {
            "type": "[parameters('vmDiskType')]"
        },
        "customConfigurationTemplateUrl": "",
        "customConfigurationParameterUrl": "",
        "imageInfo": {
            "type": "CustomImage",
            "marketPlaceInfo": "",
            "customInfo": "variables('sessionHostConfigurationImageCustomInfoProps')"}
        }
    }
}

The Gold Image, with all preconfigured software, will now be used to create the session hosts! Gold Images created in this way can also be used for Windows 365 Enterprise Cloud PC.

In future posts, I will cover FsLogix Profile Management and creating Host Pools and Application Groups using Azure DevOps.

How to enable sensitivity labels for containers

axurcio — Mon, 07 Feb 2022 00:00:00 +0000

In this day and age, users have to collaborate with others both inside and outside the organization to achieve their daily tasks. This can present challenges around privacy, access and external sharing as the content no longer stays on the local network, and is likely being shared with guests. When this happens, you want it to do so in a secure, protected way that is within your organization’s risk appetite.

Microsoft Information Protection (MIP) framework let you discover, classify, protect and monitor your organization’s data across all endpoints, applications and services using predefined sensitivity labels, while making sure that user productivity and their ability to collaborate isn’t hindered.

Most organisations are familiarized with sensitivity labels being applied across documents and emails, however their functionality can also be extended for container-level classification and protection. A container is your typical Microsoft Teams site, Microsoft 365 group or SharePoint site.

By enabling this feature in your Azure AD organization, the following label configuration will be available to you:

Privacy (public or private) of teams sites and Microsoft 365 groups
External user access
External sharing from SharePoint sites
Access from unmanaged devices
Authentication contexts (in preview)
Default sharing link for a SharePoint site (PowerShell-only configuration)

This will not only enrich the MIP reporting capability, but more importantly adjust the relevant tenant setting, allowing for more granular control. The content in these containers however, won’t inherit the labels for the classification or settings for emails and documents, such as visual markings and encryption.

To configure the sensitivity labelling for containers, the following prerequisites must be met:

Active Azure Active Directory Premium P1 licensing
Global administrator role to run the below PowerShell

#Enable sensitivity label support
Install-Module AzureADPreview
Import-Module AzureADPreview
Connect-AzureAD
#Fetch the current group settings for the Azure AD organization
$setting = (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ)
$template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b
$setting = $template.CreateDirectorySetting()
#Enable the feature
$Setting["EnableMIPLabels"] = "True"
#Check the new applied value
$Setting.Values
![Check values](/assets/images/sensitivity-labels-for-containers/ps-values.png "Check values")
#Create settings at the directory level
New-AzureADDirectorySetting -DirectorySetting $Setting
$Setting.Values
$Setting = Get-AzureADDirectorySetting | ? { $_.DisplayName -eq "Group.Unified"}
Set-AzureADDirectorySetting -Id $Setting.Id -DirectorySetting $Setting
#Enable sensitivity labels for containers and synchronize labels
Install-Module ExchangeOnlineManagement
Connect-IPPSSession -UserPrincipalName
Execute-AzureAdLabelSync

Conclusion

Microsoft Information Protection is a powerful framework that is always evolving to reflect your organization’s needs around classification and protection of sensitive data, created and shared by your users daily. To help with the underlying privacy, external user access and sharing challenges, one can enable sensitivity labelling for containers (Groups & sites). When such label is applied to a supported container, the label automatically applies the classification and protection settings to the site or group and adjusts the relevant tenant setting, allowing for more granular control. Microsoft provide a large amount of detailed information on how to enable sensitivity labels for containers via PowerShell which I have used to help guide this article.

Taking Azure AD B2C ‘Seamless Migration’ for a spin

axurcio — Mon, 07 Feb 2022 00:00:00 +0000

For many organisations, cloud is not simply heading off to fresh pastures, but instead entails complex migrations out of ‘on-prem’ data centres.

A core part of this migration, especially for customer-facing organisations, is moving users. Good customer experience demands a frictionless approach, a-la ‘Seamless Migration’, but migrating user passwords that you (hopefully!) do not have in plain text, or do not know the hashing algorithm for, presents a challenge.

Azure AD B2C

Azure AD B2C is Azure’s Identity as a Service (IDaaS) customer identity access management service.

AD B2C uses standards-based authentication protocols including OpenID Connect and OAuth 2.0. By serving as the central authentication authority for your web applications, mobile apps, and APIs, Azure AD B2C enables you to build a single sign-on (SSO) solution for them all.

Its competitors in the IDaaS space are Okta, probably the leader in the space (at least according to Gartner), but more expensive, and Ping. This Okta blog post, comparing themselves to Azure AD B2C is insightful, but should of course be read with a grain of salt.

There are a variety of open-source options in the self-hosted space, including Duende IdentityServer which is popular in the .NET ecosystem.

Importantly however, a lot of cloud migrations have core principles of utilising managed services, and of leveraging as much of their chosen cloud vendor as possible, so for anyone leaning towards Azure it makes sense to start by evaluating AD B2C.

Seamless Migration

The AD B2C docs does have a page on migrating users to AD B2C which discusses Seamless Migration.

There are two main components - first, an initial ‘pre-migration’ of all user accounts into AD B2C is performed. This is followed by creating a callback to your existing identity solution to validate a user’s password.

Then, using an AD B2C ‘custom policy’, each time a user logs in a call is triggered to the legacy system. If it returns that the password is correct then AD B2C stores the password, marks the user as migrated, and no longer needs to callback for that user.

If your legacy solution is not accessible via an API call then you are out of luck.

For me, the existence of this page in the offical documentation initially implied that Seamless Migration was ‘built-in’ functionality. However the docs eventually link you to a GitHub repo which has the rather ominous disclaimer.

“The migration application is developed and managed by the open-source community in GitHub. The application is not part of Azure AD B2C product and it’s not supported under any Microsoft standard support program or service. This migration app is provided AS IS without warranty of any kind.”

Let’s try it out

With the exception of being slightly out of date, the repository readme does an excellent job of guiding you through what you need to do to perform Seamless Migration.

In order to track whether a user has been migrated, a custom attribute is created in Azure AD B2C. It is great that there exists the ability to create custom attributes, however it would be really helpful to be able to see the value of a custom attribute for a user from within the portal, and to be able to sort/filter all users on a custom attribute. I ended up creating my own management web app to display this value.

The pre-migration step was relatively straightforward, utilising the user-friendly Microsoft Graph APIs to create a bunch of users. The name of the custom attribute used when accessing it programatically is a bit odd, but not a big deal.

The biggest challenge came with Azure AD B2C Custom Policies. I understand that adding extensibility points within products is hard, but this felt like customising a service that was not designed for customisation.

B2C is explicit that you are entering ‘identity pro’ land, but I am not convinced that slapping a warning on something gets you out of delivering a good product experience! This admission is tellingly called out in the above-mentioned Okta blog post.

There is a large amount of boilerplate point-and-click to enable custom policies in B2C, outside of authoring the policies themselves. There is a community app to automate this process, but it would be great to see this process automated within B2C itself.

Likewise, there is a (somewhat out of date) community repo full of custom policy samples, but no canonical ‘starting point’, which I believe would be useful. Taking the sample policies and updating them according to the readme results in policies that fail validation, which is not great.

Authoring the policies was challenging. The policies are written in xml, and while there are fairly strong docs, a lot of the terms used are not particularly user-friendly. Being honest, I would say I more cut-and-pasted sections from blogs/tutorials/samples than actually wrote much policy.

Lastly, uploading policies triggers a validation process, that in the case of failure (i.e. quite often) resulted in strangely formatted error messages.

Combining determination and my knowledge of the domain eventually resulted in policies that both passed validation and worked as desired! I wouldn’t say I deeply understand how they are working - I may return and figure it out, I may not.

In summary, I achieved what I was looking to achieve, but spent a little longer to do so than I would have liked. I don’t particularly value time spent learning how to configure SaaS tools, and feel Azure AD B2C would benefit from a little more investment in the customer experience for some of these more advanced scenarios.

Interactive rebase

axurcio — Thu, 21 Oct 2021 00:00:00 +0000

The purpose of this article is to document the steps involved in performing an interactive rebase as an easy reference for clients without paid tools to simplify the process. By the end a git novice should be able to follow along unassisted.

Pre-requisites

Rebase can be executed from Visual Studio Code, many IDEs or the command line. The following tools can be used to simplify the process:

Git graph viewer: VS Code with mhutchie.git-graph extention
Some means of doing git commands from the CLI from here

What is Rebase

A rebase is a way of integrating work to branches as an alternative to using a standard merge. The difference between the two is as time goes on normal merges can lead to a very messy git graph and make it difficult or impossible to find how work was merged. The way that rebase simplifies this issue is by actually re-writing the history so that it is as though the changes were made right on top of some later commit.

Unfortunately rebases can be more complicated making many people scared of them despite the advantages. But a rebase can be as simple as a couple of commands which I’ll put below before I get into the more complicated topic of the interactive rebase. To do a standard rebase:

Checkout the branch to be rebased
Run git rebase origin/target-branch
If there are no conflicts and the process completes run git push origin --force

A lot of the time those two commands are all that is required. However many commits you have made are replayed on top of the target branch. When complete it will look like you have made your changes starting from the last commit of your target branch rather than some earlier point in the history.

Guide to interactive rebase

Chances are that you will always try to do it the easy way first as above. The first thing is to cancel the rebase using git rebase --abort.

The next thing you should do is check the graph to see what work is actually yours. It may take time to learn this part but eventually you should be able to quickly glance through the nodes of your branch and determine what is your work vs. stuff that you have merged in.

Now comes the fun bit. You run git rebase --interactive origin/target-branch while on your branch. This will open a vim editor in your terminal. To make life easier here are some commands that will help make use of it.

Vim commands	Description
i	Press the i key when not in interactive mode to enter interactive mode and edit the commits list.
Esc	Press the Esc key when in interactive mode to exit and use other key commands.
:wq	While NOT in interactive mode press this key sequence to save changes and close the vim editor.
:q!	While NOT in interactive mode press this key sequence to close vim without saving changes. This is useful in case the edits do not look correct.

So in the vim editor that opens you will see something that looks like the following example. It is already telling you how to do a few interesting things, but your changes will ultimately come down to putting a d or drop next to the commits that you don’t want to be rebased. NOTE When you run the rebase there will be instructions as well which I’ve omitted for brevity, but read it through for a full understanding of what can be done in an interactive rebase.

pick 442a48288 Adding publication form
pick 9e4588745 Publication date component
pick b503173d8 Test updates for form
pick 460c79b2f Portal settings integration with publication dates service

# Rebase e7403349a..460c79b2f onto e7403349a (4 commands)

In the example above the branch that is being rebased consists of 4 different commits and will default to rebasing all commits. But if the target branch already had the final commit I could do the following:

Start the interactive rebase from the branch to rebase. This will open a vim session in the CLI
You will see something resembling the example above. Press i to enter interactive mode
Update the commits that are no longer required with drop e.g. drop 460c79b2f Portal settings integration with publication dates service
Press Esc to return to command mode
Press :wq to close the editor and save the changes
The rebase will now continue automatically
If there are conflicts you will need to resolve them

As many commits as are necessary can be dropped from the rebase. Identifying those that are already committed in the target should be fairly trivial in a lot of cases. To help use a git graph tool to look at the commits and identify commits that can be dropped without issue.

What about conflicts

If you have conflicts then they will need to be resolved. To do this you need some tool to compare the changes in your branch and the target and decide how to resolve it. Broadly there are 4 options to resolve it:

When you have a conflict in a file you should be able to see it in the git tab of VS Code. If you click on the file there you will see a diff of the file with the conflicts highlighted in blocks like this:

The current commit of the rebased branch’s changes will be here.

The current state of the target branch’s changes including previous rebased commits.

Command option	Description
Accept Current Change	Take just the change in the target branches changes. Remember that this will include any rebased commits that are already done
Accept Incoming Change	Take just the change from the current commit being rebased
Accept Both Changes	Take both of the above changes. NOTE this will often require additional editing

You can also use git commands to progress the rebase. Typically you will run the continue command after selecting one of the options above but other commands are listed below. It will then open a vim editor with that commit’s message. If you aren’t changing it just use the vim close command.

Below are commands that can be typed in the git rebase terminal to continue actions.

Command	Description
git rebase --continue	Continue to the next commit of the branch to be rebased. All conflicts must be resolved for this to succeed
git rebase --skip	Skips the current commit from the branch being rebased
git rebase --abort	Abort the rebase and return the branch to its pre rebased state

When not to Rebase

Just because you can do something doesn’t mean that you should. 99% of the time you should NOT rebase a branch that is used by multiple people. The reason for this is that the re-write in the history will make it as though the branches diverged and make the other developers lives more difficult as a result. If you only rebase your own branches then you should never run into issues.

How can it go wrong?

Occasionally you will have to take a change from another branch such as some API updates possibly before they are completed to the target branch. When you eventually go to PR your changes if those changes are already merged before that you will get conflicts. But this can be avoided using the interactive rebase.

Even if you haven’t merged from another branch sometimes someone will happen to alter code in the same area as you.

So you do a rebase and you get conflicts. If you know that you have merged other changes into your branch that have already made their way into your target then you would be better doing an interactive rebase to at least avoid those conflicts. Otherwise you can resolve the conflicts as normal.

References

If you would like to read further on the above topics you can find further info at:

git rebase

Azure Maps

axurcio — Wed, 28 Jul 2021 00:00:00 +0000

As the topic suggests, Azure Maps is the geospatial Platform-as-a-Service (PaaS) service provided by Microsoft.

It is part of their cloud computing offering, Azure.

Pricing

With Microsoft cloud offering, the OPEX model applies. More on their pricing model here. The article also describe Azure Map functionality enabled for each pricing tiers.

Technical offering

The Azure Maps product team at Microsoft has extensive code samples available.

The following are nifty information that are worth knowing when working with Azure Maps.

Out of the box, pin aggregation aka clustering only happens when there are 2 or more pins.

In order to have a single pin show up as a cluster, use the Bubble Layer and apply data-driven layer styling.

The samples do not provide the solution, so after some reading of the documentation, here is how.

In order to enable aggregation, set the cluster property of the atlas.source.DataSource object to true.

The data source must contain a property that you want to use to aggregate with. I have used the isCheapest property from my data item in the example below.

Incrementing the Cheapest property within the clusterProperties of the DataSource object accounts for the scenario when 2 or more pins have the cheapest and are within close proximity.


cluster: true,
clusterProperties: {
    Cheapest: ['+', ['case', ['==', ['get', 'isCheapest'], true], 1, 0]]
}

You will then create a Bubble Layer object and alter its properties.

The example below shows the colour property of the Bubble Layer being set to red when there is a cluster of 1 or more cheapest pins or when there is only 1 pin and the isCheapest property of the data item is true. Otherwise, the bubble shown will be black in colour.


color: [
        'case',
        ['all', ['has', 'Cheapest'], ['>', ['get', 'Cheapest'], 0]],
        '#ff0000',
        ['all', ['has', 'myDataItem'], ['==', ['get', 'isCheapest'], true]],
        '#ff0000',
        '#000000'
    ]

Another nifty information to keep an eye out for is the disabling of pan, rotate and tilt in Azure Maps. By default, the map allows pan, rotate and tilting. Thus to disable them, you will have to set the following map properties.

dragRotate : this is for drag event as well as right-click. The _pitchWithRotate property will disable pitch when rotating. There is also a disabled function to prevent dragging and rotating.
touchZoomRotate : this is for touch enabled devices. There is a disableRotation function that you can invoke.
touchPitch : this is also for touch enabled devices. Use the disabled function to prevent pitch.

The map also has a setMaxPitch function that you can invoke to set the maximum desired pitch. If you pass in 0, that means the map has no pitch. However, I still encountered undesired map rendering. In order to completely nullify pitch, you can invoke the preventDefault function on pitch events of the map. A full list of map events can be found here.

Considerations also has to be taken when rendering pins. There will be a performance hit with a liberal use of the addPins function of the map. The recommended approach is to have 1 atlas.source.DataSource object and adding items to it by invoking the add function or removing items from it by invoking the remove function.

Happy Azure Mapping!