Category Archives: Cloud Computing

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.

Cloud-Native Design with 12 Factor App

There are many guidelines available for building a cloud-native application. One of the Industry accepted set of guidelines is 12 factors suggested on https://12factor.net/

In nutshell, here are the 12 factors to help your application build in a cloud native manner.

Codebase: One codebase tracked in revision control, many deploys
Dependencies: Explicitly declare and isolate dependencies
Config: Store config in the environment
Backing services: Treat backing services as attached resources
Build, release, run: Strictly separate build and run stages
Processes: Execute the app as one or more stateless processes
Port binding: Export services via port binding
Concurrency: Scale-out via the process model
Disposability: Maximize robustness with fast startup and graceful shutdown
Dev/prod parity: Keep development, staging, and production as similar as possible
Logs: Treat logs as event streams
Admin processes: Run admin/management tasks as one-off processes

A good tutorial on practical usage of these 12 factors in your application

Istio- Getting started

I recently wrote about service mesh and how it helps ease managing and deploying services. Istio is an open-source service mesh that layers transparently onto existing distributed applications. Istio helps to create a network of deployed services with load balancing, service-to-service authentication, monitoring with no additional coding requirements. Istio deploys a sidecar for each service which provides features like canary deployments, fault injections, and circuit breakers off the shelf.

Let’s take a look at Istio at a high level

The overall architecture of an Istio-based application.
Image source: https://istio.io/latest/docs/concepts/what-is-istio/

Data Plane: as we can see in the design above that Data Plane uses sidecars through Envoy Proxy and manage traffic for microservices.

Control Plane: Control plane helps to have centralized control over network infrastructure and implement policies and traffic rules.

Control plane functionality (https://istio.io/latest/docs/concepts/what-is-istio/)

Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.

Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.

A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.

Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.

Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

Currently Istio is supported on

  • Service deployment on Kubernetes
  • Services registered with Consul
  • Services running on individual virtual machines

Lets take a look at core features provided by Istio

Traffic management

Istio helps us manage traffic by implementing circuit breakers, timeouts, and retries, and helps us with A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits.

Security

Another core area where Istio helps is security. It helps with authentication, authorization, and encryption off the shelf.

While Istio is platform-independent, using it with Kubernetes (or infrastructure) network policies, the benefits are even greater, including the ability to secure pod-to-pod or service-to-service communication at the network and application layers.

https://istio.io/latest/docs/concepts/what-is-istio/#security

Observability

Another important aspect that Istio helps with is observability. It helps managing tracing, monitoring, and logging. Additionally, it provides a set of dashboards like Kiali, Grafana, Jaeger, etc to help visualize the traffic patterns and manage the services.

Additional Resources –

https://istio.io/latest/docs/

https://dzone.com/articles/metadata-management-in-big-data-systems-a-complete-1

Disclaimer: This post was originally posted by me in the cloud community – https://cloudyforsure.com/cloud-computing/istio-getting-started/