Azure Storage

As we know, storage is one of the important features of a cloud service provider. Azure provides various options for storage.

The following data services are provided by Azure

Blob Storage: It is a scalable data store for text and binary data.

Blob storage provides for the storage of 3 types of Blobs. Page, Block, and Append. Page blobs are a collection of 512-byte pages that are optimized for read and write operations. A common use for page blobs is for virtual hard disks used by Azure virtual machines. Block Blobs are for the efficient storage of large Blobs up to 4.57 terabytes. The blocks within a Blob can be updated or deleted as needed. Append Blobs are a form of blob storage that is optimized for appending operations. Modified append Blobs write data blocks only to the end of the blob. Existing blocks cannot be deleted or updated. 

File Storage: As the name suggests, this storage is optimized for storing files.

Queue Storage: Datastore for reliable messaging between application components.

Table Storage: This is a NoSQL Datastore by Azure. It does not enforce schema but stores data in form of name-value pairs. As it is nonrelational data, no complex joins are supported.
The hierarchy is Storage Account>> Tables >> Entities
For example, Kamal’s Account >> Customers >> {Key Values, name: Kamal, Address: }. As this is a NoSQL datastore, different entities can have a different set of properties, one customer has an address another does not.

Disk Storage: Azure Managed Disks that are associated with VMs. The following type of disks are supported-
Ultra Disks
Premium SSD
Standard SSD
Standard HDD

Type of Storage Account

  • General purpose V2 (Recommended)
  • General purpose V1 (Legacy- use V2)
  • Block Bob Storage account (premium – faster access)
  • Files (Premium- For files)
  • Blob Storage (Legacy- use V2)

Storage Sync Service is the top-level resource for Azure File Sync. It manages the relationships between Azure Files file shares and Windows Server endpoints.
A sync group is a grouping of a file share and servers that keep a set of files in sync.

Cloud Basics: Azure

Cloud is a set of services that helps you with your software development lifecycle, from development to build to deploy to secure to monitor. Any cloud service provider will provide multiple services, basic ones would be Compute, Storage, and Networking.

Azure Provides the following set of services.

Compute

  • VMs (IaaS)
  • Azure App Service (PaaS)
  • Containers
  • AKS (Azure Kubernetes Service)
  • Azure Functions (Serverless, Pay as you use)

Storage

  • Blob storage (Object Storage) – Hot Tier/ Archive Tier
  • File Storage
  • Data Lake Storage – Hadoop Compatible
  • SQL Database
  • Azure DB for open source
  • Azure Cosmos DB (No-SQL)
  • Azure Cache for Redis

Networking

  • VNet
  • Subnets
  • VNet Peering
  • Azure VPN
  • Azure Expres Route

There are three popular ways provided by Azure to interact with and manage services

The Azure portal: the portal is a Graphical User Interface (GUI) that makes it convenient to locate the resource you need and execute any required changes.

The Azure CLI: The Azure CLI is a cross-platform command-line program to connect to Azure and execute administrative commands on Azure resources.

az vm create \
--resource-group CrmTestingResourceGroup \
--name CrmUnitTests \
--image UbuntuLTS
…

Azure PowerShell: Azure PowerShell is a module you add to PowerShell to let you connect to your Azure subscription and manage resources.

New-AzVm -ResourceGroupName "CrmTestingResourceGroup"
-Name "CrmUnitTests" `
-Image "UbuntuLTS"
…

Further Reading: https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/cloud-native-apps

Azure Subscription and Resource Groups

When onboarding to the cloud, the first thing you will create is a subscription. Under a Subscription, you will create one or more resource groups. Resource groups are logical containers. This is used to group a collection of resources such as VMs, VNets, storage accounts, etc. This logical grouping helps in provisioning, monitoring, and access control.

Resources in a Resource Group can span across multiple regions. One way to create Resource Groups is thinking of the deployment stage, for example, dev resources, test resources, and production resources. This will help group and manage resources based on criticality.

Another important aspect one needs to be aware of Role Based Access Controls (RBAC). There are four key roles.

  • Contributor: Manage resources but not user accounts
  • Owner: Manage Resources and can assign user roles/ access
  • Reader: View only access
  • User access Administrator: Can manage access for users but cannot manage resources

Azure Security Center: Creates a default security policy automatically for each azure subscription.

Example Policies

  • System Updates (any updates missing for a system e.g. a VM)
  • Security Configurations
  • Endpoint Protection
  • Disk Encryption
  • Network Security Groups
  • Web Application Firewall
  • Next-Generation Firewall
  • SQL auditing and Threat Detection
  • SQL Encryption
  • Vulnerability assessment
  • Storage Encryption
  • JIT Network Access

Resource Policies: Resource policies can be set for a subscription, for example. only a certain size of VMs are allowed or resources can be created in a specific location.

Resource Locks: Two type of locks can be applied to resources, CannotDelete and ReadOnly.

Tagging: Another powerful mechanism to logically group and organize the resources. This helps in billing and management, for example, you can create a billing report based on the tag “XYZ” as Project Name.

Note that one can also move resources between Resource Groups. During the movement, both target and source groups will be locked. While the movement of resources, the location of the resource is not changed, only the Resource Group is updated.

Azure Network Watcher

Network watcher provides a set of tools to help monitor various aspects of the network.

IP Flow Verify: It is a tool under network watcher, that helps check if access is allowed from a source to the destination address. It also highlights the rule responsible for allowing or blocking access.

Next Hop: shows which will be the next hop when the source device will connect to the destination device.

Connection Troubleshoot: One can deploy a “network watcher agent” on the VM, this helps to check the connection between the VM and destination. It shows the complete route with the time taken at each hop, hence helping debug performance or rule blocking the connection.

VPN troubleshoot tool: As the name suggests, helps troubleshoot connection problems between two VPNs.

Connection Monitor: between a VM and endpoint, monitors the connectivity, e.g. between two VMs, shows a report with round trip latency based on the time period selected. You can further set alerts for example alert if the latency goes beyond 200ms.

Traffic Analytics: gives a report on a high level, for virtual networks or subnetworks, it shows traffic flow details. If there are malicious flows, they will be highlighted in the report. shows complete traffic details, sources, and destinations, and also highlights data on the port level, so you can figure out which ports are getting the most malicious traffic.

Network performance monitor: As the name suggests, helps monitor performance for the network, i.e. time taken in terms of latency.

Azure Network Security

Security is one of the critical areas when you are deploying applications on the cloud. Cloud providers have a set of best practices and tools available to make sure you secure your applications.

Virtual Network: helps create virtual boundaries and isolate resources from unwanted access. Setting up subnets further help sub-boundaries within a virtual network. Secured practices like Site-to-Site connectivity, and point-to-site connectivity using Express routes or Virtual Network gateways help connect between on-prem and on-cloud networks securely.

Network Security Groups (NSG): NSG helps create security rules which will ensure only desired traffic can be received or sent from virtual networks or subnets.

A security rule contains the following aspects

  • name (unique)
  • priority (lower the priority number, the more importance is given)
  • source/ destination
  • protocol
  • direction (inbound/ outbound)
  • port range
  • action (allow/ deny)

You can associate an NSG to a virtual network, subnet, or Application Security Group.

Azure Firewall: One can set FQDN traffic rules, Network traffic rules using Azure Firewall. Network Security Group is more targeted towards Virtual Network or Subnets, whereas Firewall monitors traffic more broadly.

There are three kinds of rules that you can configure in the Azure Firewall. Remember, by default, Azure Firewall blocks all traffic, unless you enable it.

NAT rules: You can configure Azure Firewall Destination Network Address Translation (DNAT) to translate and filter inbound traffic to your subnets. Each rule in the NAT rule collection is used to translate your firewall public IP and port to a private IP and port. Scenarios, where NAT rules might be helpful, are publishing SSH, RDP, or non-HTTP/S applications to the Internet. A NAT rule that routes traffic must be accompanied by a matching network rule to allow the traffic.

Network rules: Any non-HTTP/S traffic that will be allowed to flow through the firewall must have a network rule. For example, if resources in one subnet must communicate with resources in another subnet, then you would configure a network rule from the source to the destination

Application rules: Application rules define fully qualified domain names (FQDNs) that can be accessed from a subnet. For example, specify the Windows Update network traffic through the firewall

Application Security Group: ASGs enable you to configure network security as a natural extension of an application’s structure. That means, you can create a NSG and apply it to an ASG. The ASG can be applied to a VM or set of VMs (forming an application including web servers, application servers, and database servers).

Azure Virtual Network Connectivity

There are two major ways to connect virtual Networks, i.e. VNet peering and Virtual Network Gateway.

VNet Peering: If both the virtual networks that you are trying to connect are on Azure, the best and simplest approach to create a connection is using Virtual Network Peering. One can create local VNet peering for connecting virtual networks in the same region, or Global VNet peering for VNets in different regions.

An important point to note here is, that if you have created VNet peering between network A and network B, it does not automatically mean connectivity will be there from network B to A as well. One needs to create an additional peering from B to A. Also, VNet peering is not transitive, that is A to B connectivity and B to C connectivity do not mean an automatic A to C connectivity.

Virtual Network Gateways: A Virtual Network Gateway needs to be deployed in its own Subnet, so you will start by creating a special “Gateway Subnet”. After this, you create two virtual network gateways in this subnet, for example, one for Virtual network A and another for B. And after that, you can create a connection between the two networks. Again you will need to create a separate connection from A to B and B to A as per the requirement.

Azure DNS: It is a Service for hosting your domain name system record. You can not only create a public domain, but also a private domain accessible from within virtual networks.

You start by creating a DNS zone and adding records. Type A record will map a domain name to an IP address. A CName record will provide an alias for existing domain, for example, www.kamalmeet.com can be an alias for kamalmeet.com

Azure Load Balancing Options

There are multiple ways in which one can manage traffic or balance load in Azure.

Load Balancer

Azure Load balancer work at layer 4 of the OSI model, i.e. at the transport layer. This means it just directs the incoming traffic to destination IPs and does not have access to request data.

A load balancer has the following main components

  • Frontend IP configuration
  • Backen Pool (for example VMs)
  • Health Probes
  • Load Balancing rules

Application Gateway

The application gateway in Azure works at layer 7, which is the Application layer in the OSI model. This means the API gateway can access request data and form rules on that. For example, we can set rules that /images pattern is getting redirected to a backend, whereas /videos pattern to another. Additional one can have features like SSL termination, and WAF (Web Application Firewall, that will protect from threats like SQL injection attack, Cross Site Scripting or XSS attack, etc.) implemented.

Application gateway core components

  • Frontend IP (public or private)
  • Listeners (listens to traffic and route based on rules)
  • Request Routing Rule (when adding rule, you need to define listener and backend pool)
  • Backend pool

While talking about application gateway, it is important to mention Azure Front Door, which can work at the global level. From Azure “While both Front Door and Application Gateway are layer 7 (HTTP/HTTPS) load balancers, the primary difference is that Front Door is a non-regional service whereas Application Gateway is a regional service. While Front Door can load balance between your different scale units/clusters/stamp units across regions, Application Gateway allows you to load balance between your VMs/containers etc. that is within the scale unit.

Traffic Manager

The traffic manager distributes traffic at the DNS level, hence it is used for managing traffic at the global region level. For example, you might want to send traffic originating from Europe to hit Europe servers whereas traffic from North America to hit North America servers. While resolving the DNS, the traffic manager will choose the backend endpoint based on the rules set. An important thing to note here is that actual traffic never passes through the traffic manager, as was the case with the Load balancer or Application gateway, because the traffic manager is only responsible for providing back the endpoint, and after that client directly interacts with the endpoint.

Following routing methods are allowed

  • Priority
  • Weighted
  • Performance
  • Geographic
  • Multivalue
  • Subnet

Virtual Networks

Sometime back I wrote about virtual networks and Azure-specific implementation. Here is a quick recap and some additional details.

As the name suggests, the term virtual network has two words, virtual and network. we deal with networks on daily basis, in our offices and workplaces, which are nothing but a collection of computers, machines, and other devices. with infrastructure moving to the cloud, where we deal with virtual machines and devices, it is logical to have a network that is virtual, hence a virtual network.

Next within the network, we create subnets to logically divide our network. The network address space is divided among subnets.

Network Virtual Appliances (NVA) are Virtual machines with pre-installed images that can provide capabilities for networking such as firewall, WAN optimizer, routers, load balancers, etc.

A virtual network gateway (creates encrypted cross-premises connections to your virtual network from on-premises locations, or encrypted connections between VNets) is composed of two or more VMs that are automatically configured and deployed to a specific subnet you create called the gateway subnet. The gateway VMs contain routing tables and run specific gateway services. It can use one of the three protocols, Open VPN protocol, SSTP (Secure Socket Tunneling Protocol, windows only), and IKEv2 (Internet Key Exchange version 2).  

To communicate between Virtual networks, we have VNet peering, which can be local (Same region VNets) or global (different regions VNets).

Additionally one can set up a Load balancer, which can be internal (within the network) or external (traffic from outside the network). A 5 tuple hash is used by default to route traffic, which includes – Source IP, destination Ip, Destination port, and protocol.

DORA Metrics

With the popularity of the Agile development approach, frequent deployments to prod have become commonplace. DevOps teams manage these deployments, sometimes multiple deployments on the same day. With these frequent deployments, it is important to define and measure the success criteria. DevOps teams use DORA metrics to measure their performance.

Deployment Frequency: Refers to the frequency of successful software releases to production.

Lead Time for Changes: Time it takes for change that was committed to reach to production.

Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and complete recovery.

Change Failure Rate: Indicates how often a deployed changes lead to failures.

How DORA Metrics Can Measure and Improve Performance

https://www.leanix.net/en/wiki/vsm/dora-metrics