Azure-in-bullet-points

Designing an Infrastructure Strategy

Application Architecture Patterns in Azure

• In software engineering, these best practices are commonly referred to as design patterns.
• Microsoft Patterns & Practices
  • Created & maintained by patterns & practices team at Microsoft
  • Available on github https://github.com/mspnp
• Azure Architecture Center
  • Architecture Center Guide
• Performance Patterns
  • Stateless Applications
    • Modular applications make it easier to design both current and future iterations of your application.
      • Existing modules can be extended, revised or replaced to iterate changes to your full application.
    • Modules can also be tested, distributed and otherwise verified in isolation.
  • The Valet Key Pattern
    • Dependency on a storage mechanism => being an overhead to the cloud application
      • Requires the client to have access to the security credentials for the store.
      • After the client has a connection to the data store for direct access, the application can’t act as the gatekeeper.It’s no longer in control of the process and can’t prevent subsequent uploads or downloads from the data store.
      • Granular access: Lower performance, higher data transfer costs and the requirement to scale out.
    • The Valet Key pattern introduces a mechanism where your application can validate the user’s request without having to manage the actual download of the media. Both can occur while keeping the media private and locked away from anonymous access.
      • E.g. SAS tokens in Azure Storage / EventHubs…
    • Flow
      • Client needs to send a request to the web service or application if it wants to access a media asset.
      • The application then validates the request.
      • If the request is valid
        • The application goes to the external storage mechanism
        • Generates a temporary access token
        • Provides the URI of the media asset to the client, along with the temporary access token.
    • Result
      • It is up to the client application or browser to use the URI and temporary access token to download the media asset.
      • Now, the storage service is responsible for scaling up to manage all the requests for media while the application can focus solely on other functionality.
  • Command and Query Responsibility Segregation (CQRS) pattern
    • Segregate read & update operations to data using separate interfaces.
    • Maximizes performance, scalability, and security.
    • Supports the evolution of the system over time through higher flexibility, and prevents update commands from causing merge conflicts at the domain level.
    • Traditional CRUD designs
      • Same entity, DTO (data transfer object) and DAL (data access layer) repository for read and write.
      • However complex domain may introduce:
        • Mismatch between the read and write representations of the data, such as additional columns or properties that must be updated correctly even though they aren’t required as part of an operation.
        • Update conflicts caused by concurrent updates when optimistic locking is used
        • Security and permissions more complex because each entity is subject to both read and write operations, which might expose data in the wrong context.
    • CQRS
      • Data models used for querying and updates are different.
        • The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views, e.g. domain models.
      • Separation of the read and write stores also allows each to be scaled appropriately to match the load. E.g. reads encounter more load than writes.
      • When the query/read model contains denormalized data (see Materialized View pattern), performance is maximized when reading data for each of the views in an application or when querying the data in the system.
  • Throttling pattern
    • A strategy to autoscaling is to allow applications to use resources only up to a limit, and then throttle them when this limit is reached.
    • The system should monitor how it’s using resources so that, when usage exceeds the threshold, it can throttle requests from one or more users.
    • Enables the system to continue functioning and meet any SLAs.
• Resiliency Patterns
  • Transient Errors
    • Handling transient errors: Big difference between on-premises and cloud applications.
    • Transient errors are as errors that occur due to temporary interruptions in the service or due to excess latency.
    • Many of these temporary issues are self-healing and can be resolved by exercising a retry policy.
    • A break in the circuit must eventually be defined so that the retries are aborted if the error is determined to be of a serious nature and not just a temporary issue.
    • Transient Fault Handling
      • Managing connections and implementing a retry policy
      • Implemented in many .NET libraries such as Entity Framework and Azure SDK.
    • Circuit breaker pattern
      • If everyone is retrying due to a service failure, there could be so many requests queued up that the service gets flooded when it starts to recover.
      • If the error is due to throttling and there’s a window of time the service uses for throttling, continued retries could move that window out and cause the throttling to continue.
      • At a certain retry threshold your app stops retrying and takes some other action, such as: custom fallback , fail silent (e.g. return null), fail fast (e.g. exception with try again later message).
  • The Retry Pattern
    • When the initial connection fails, the failure reason is analyzed first to determine if the fault is transient or not. If the failure reason or the error code indicates that this request is unlikely to succeed even after multiple retries, then retries are not performed at all.
    • Retries are performed until either the connection succeeds or a retry limit is reached.
    • Implemented in many libraries such as Entity Framework and Enterprise Library.
  • Queues
    • You can use a third-party queue to persist the requests beyond a temporary failure. Requests can also be audited independent of the primary application as they are stored in the queue mechanism.
    • Queue-Based Load Leveling pattern
      • Use a queue that acts as a buffer between a task and a service it invokes in order to smooth intermittent heavy loads that can cause the service to fail or the task to time out.
      • Help you design solutions that handle transient errors.
      • Benefits
        • Control costs
          • The number of service instances deployed only have to be adequate to meet average load rather than the peak load.
        • Maximize scalability
          • Both the number of queues and the number of services can be varied to meet demand.
        • Maximize availability
          • Delays arising in services won’t have an immediate and direct impact on the application, which can continue to post messages to the queue even when the service isn’t available or isn’t currently processing messages.
• Scalability Patterns
  • Asynchronous Messaging
    • Messaging supports asynchronous operations, enabling you to decouple a process that consumes a service from the process that implements the service.
    • Asynchronous Messaging with Variable Quantities of Message Producers and Consumers
      • Problem: handling variable quantities of requests
      • Applications passes data through a messaging system to another service (a consumer service) that handles them asynchronously
        • Business logic in the application is not blocked while the requests are being processed.
      • In Azure: Storage Queues or Service Bus Queues
      • Most message queues support three fundamental operations:
        • A sender can post a message to the queue.
        • A receiver can retrieve a message from the queue (the message is removed from the queue).
        • A receiver can examine (or peek) the next available message in the queue (the message is not removed from the queue).
  • Cached Data Consistency
    • Impractical to expect that cached data will always be completely consistent with the data in the data store.
    • Consider a strategy that helps to ensure that the data in the cache is up to date as far as possible, but can also detect and handle situations that arise when the data in the cache has become stale.
    • Read/Write-Through Caching
      • If the data is not in the cache, it is transparently retrieved from the data store and added to the cache. Any modifications to data held in the cache are automatically written back to the data store as well.
        • Cache-aside strategy: This strategy effectively loads data into the cache on demand if it’s not already available in the cache.
      • Example implementation in Azure using Redis Cache
        1. When the web application loads for the first time it makes a request (GET) to the Redis Cache instance for the name of the featured player using the key: player:featured.
        2. The cache will return a nil value indicating that there is not a corresponding value stored in the cache for this key.
        3. The web application can then go to the Cosmos DB data store and gets the name of the featured player.
        4. The name of the featured player will be stored in the Redis Cache using a request (SET) and the key player:featured.
        5. The web application returns the name of the featured player and displays it on the homepage.
        6. Subsequent requests for the home page will use the cached version of the value as Redis Cache will successfully return a value for the name of the featured player.
        7. If an administrator updates the featured player, the web application will replace the value in both Redis Cache and Document DB to maintain consistency.
  • Load Balancing
    • The application traffic or load is distributed among various endpoints by using algorithms.
    • Flexibility to grow or shrink the number of instances in your application without changing the expected behavior.
    • Load Balancing Strategy
      1. Decide whether you wish to use a physical or a virtual load balancer
         • 💡 Deploy virtual load balancer (hosted in VM’s) if a company requires a very specific load balancer configuration.
      2. Select a load balancing algorithm e.g. round robin or random choice.
         • Round-robin: List is ordered on each request and sent to next instance.
           • No standard for deciding which address will be used by the requesting application. -E.g. geographically closer
      3. (optional) Configure state (affinity or stickiness)
         • Stickiness allows you determine whether a subsequent request from the same client machine should be routed to the same service instance
• Data Patterns
  • Redis Cache
    • Azure Cache => Depreciated, use Redis Cache.
    • Redis Cache
      • Open source cache and message broker that you can deploy to support high availability.
      • Key-value pair NoSQL storage.
      • SKU’s
        • Basic: Single node. Memory-sizes: 250 MB - 53 GB
        • Standard: Two nodes in master/replica configuration, and SLA.
        • Premium: On more powerful hardware, geo replication, VNet integration, and more.
  • Database Partitioning
    • The physical separation of data for scale.
    • Any data access operation will only occur on a smaller subset (volume) of data which in turn ensures that the operation will be more efficient when compared to a query over the entire superset of data for your application.
    • Partitioning also spreads your data across multiple nodes which can individually be replicated or scaled.
    • Scenario:
      • Problem: Hosting Large Volumes of Data in a Traditional Single-Instance Store
        • Limitations:
          • Finite storage space
          • Finite computing resources:
          • Finite network bandwith
          • Geography: Single region, hard with more.
        • Scaling vertically is temprory solution that can postpone effects.
          • Cloud application should be scale almost infinitely.
      • Solution: Partitioning Data Horizontally Across Many Nodes
        • Divide the data store into horizontal partitions or shards.
        • Each shard has the same schema, but holds its own distinct subset of the data.
        • 💡 Abstract the physical location of the data in the sharding logic
          • Provides a high level of control over which shards contain which data
          • Enables data to migrate between shards without reworking the business logic of an application.
          • The tradeoff
            • The additional data access overhead required in determining the location of each data item as it is retrieved.
            • To handle it, implement a sharding strategy with a shard key that supports the most commonly performed queries.
      • E.g. sharding for Azure SQL Database
        1. Manually create shards
        2. Use Elastic Scale feature
           • Each partition is an instance of Azure SQL Database.
           • If load to one shard gets high:
             • Uses “Split” feature to create new shards from original
           • If load to multiple shards get low
             • Uses “Merge” feature to create new single shard from multiple shards.

VM Availability

• Microsoft Azure provides a Service Level Agreement (SLA) that is backed by a financial service credit payment for infrastructure as a Service (IaaS) Virtual Machines.

• The SLA depends entirely upon the deployment of the virtual machine and what resources it uses.

• Availability Set
  • Ensures SLA can be provided.
    • One VM being available at least 99.95% of the time.
  • Ensures VMs you deploy within an Azure datacenter are isolated from each other.
  • Ensures that all virtual machines that are added to the set are placed in such a way as to ensure that neither hardware faults or Azure fabric updates that is unplanned and planned maintenance events can bring down all of the virtual machines.
  • *Application availability can be impacted by:
    • Unplanned hardware maintenance event
    • An unexpected downtime
    • Planned maintenance events
  • To reduce or remove the impact of downtime:
    • 💡 Place virtual machines in an availability set for redundancy.
    • 💡 Use managed disks for all VMs placed in an availability set.
    • 💡 Use Scheduled Events to respond to events.
    • 💡 Place each tier of your application in a separate availability set.
    • 💡 Use a load balancer in combination with availability sets.
  • 💡 Avoid single instance VMs in an availability set. These are not subject to any SLA unless all the Operating System and Data disks are using Premium storage.
  • Update and Fault Domains
    • Each machine in the Availability set is placed in an Update Domain and a Fault domain.
    • A Fault Domain (FD) is essentially a rack of servers.
      • It consumes subsystems like network, power, cooling etc.
    • Update Domain (UD)
      • Purposeful move to take down one (or more) of your servers.
      • It will walk through your update domains one after the other.
    • FDs come in sets of 2 and UDs come in sets of 5 (default)
      • So if you deploy more than 5 VM’s in an availability set they’ll end up in same UD and FD.
  • Multiple availability sets
    • E.g. N-tier availability sets
      • An extension of the availability set model is used logically to place individual tiers of an application into separate Availability Sets.
      • E.g. put front-ends in one, and data tier in another availability set.
• Availability Zones
  • Advent of a datacenter-wide fault would prevent the Availability set from functioning.
  • Allows for a complete data center failure and keep your VM based application running.
    • Zone = separate zone or building within a single Azure region.
  • You can set the count of zones while creating VM.
    • There is a maximum of three Availability Zones per supported Azure region.
    • Each Zone operates on an entirely isolated power source, cooling system, and network infrastructure.

Azure VM Scale Sets

• Allow accurate auto-scaling
• Provides high degree of control like IaaS, but manages networking/storage/compute/load balancing like PaaS.
  • Requires no pre-provisioning
    • The network and load balancer are created, configured and managed automatically, including the Network Address Translation (NAT) for access to and from the VM Instances.
• Handles resource creations, dependencies and configurations.
• Allows a Virtual machine to deploy up to 1000 times in the same subnet.

• Virtual Machines vs. Virtual Machine Scale Sets

  Functionality	Scale set	VM
  Azure Autocale	👍	👎
  Availability zones	👍	👍
  Reimaging	👍	👎
  Overprovisioning	👍 Automatically increase reliability and faster deployment	👎 Custom code is required
  Upgrade policy	👍 Can upgrade all VMs in scale	👎 Must be orchestrated
  Attach data disks	👍 Applies to all instances in data sets	👍
  Attach non-empty data disks	👎	👍
  Snapshot	👎	👍
  Capture image	👎	👍
  Migrate to use managed disks	👎	👍
  Assign public IP addresses	👎 Requires load balancer	👍 Possible on NIC

• Connecting to a VM Scale Set instance VM
  • Done by accessing Load balancer inbound NAT rules and using the correct IP address and custom port.
  • You can see & set it in Load Balancer -> Inbound NAT Rules.
• Continuous Delivery in VMSS
  • By default, the pipeline builds code, and updates VM scale set with the latest version of your application.
    • Can be done by two ways:
      1. Immutable Deployment
         • Create a custom image that already contains the OS and application in a single VHD.
         • Advantages:
           • Predictability
             • Any new versions of the application can be tested on a similar VM Scale set and then deployed directly into the production instances without any downtime.
           • Easy to Scale
           • Easy to roll-back
           • Faster to scale (no code to install on each VM as it is deployed)
           • Can use toolset from Visual Studio Team Services
      2. Use of VM extensions to install software to each instance at deployment time.
         • Customs script VM extension to install/update your application on VM scale set
• Large VM Scale Sets
  • ❗ Scale sets created from Azure Marketplace images can scale up to 1,000 VMs.
  • ❗ Scale sets created from custom images can scale up to 300 VMs.
  • Layer-7 load balancing with the Azure Application Gateway is supported for all scale sets.
  • Scale sets are defined with a single subnet:
    • 💡 Ensure subnet is large enough to handle all potential VM instances.
  • Large scale set: can scale beyond 1000 VMs
    • Requires singlePlacementGroup = false property setting.
      • Layer-4 load balancing with scale sets composed of multiple placement groups requires Azure Load Balancer Standard SKU.
      • Fault Domains and Update Domains relate to a single placement group, to maintain high availability ensure there are at least two VM instances in each Fault Domain and Update Domain.
    • ❗ Large scale sets require Azure Managed Disks.
    • Ensure your compute limits are high enough, the requirement for compute cores will prevent a successful deployment if not.

Hybrid Cloud

• Azure AD
  • In its basic form, it’s a free service that provides the ability for Single Sign-On into cloud applications.
  • Azure AD allows connection with consumers (Azure AD B2C) and business partners (Azure AD B2B) without deploying complex infrastructure or federation.
  • Azure AD Connect
    • Provides the ability to integrate your on-premises directories with Azure AD.
    • Having deployed AD Connect, you can provide single sign-on to cloud applications such as Office 365, Azure and other SaaS applications.
  • Azure AD Hybrid solutions
    • Azure AD Connect provides the choice of:
      • 1. Password Synchronization only , the ability to synchronize users and groups.
      • 2. ADFS , to allow on-premises authentication, 3rd party MFA, etc.
      • 3. Pass-through authentication , provides on-premises authentication without deploying ADFS.
    • In all 3, you need Azure AD Connect to provide the synchronization engine.
      • Additionally, the Microsoft Identity Manager (MIM) can be installed on-premises and used to configure the users, groups and attributes to be synchronized.
  • Pricing
    • Basic: SLA + self-service password reset for cloud users.
    • Premium: MFA + other stuff.
    • P2 only: Conditional risk policy, privileged identity management
• Azure AD Domain Services
  • Provides managed domain services such as domain join, group policy, LDAP and Kerberos authentication.
  • Windows Server Active Directory compatible.
    • Not all features available in Windows Server AD are available in Azure AD Domain Services.
    • LDAP, Kerberos, NTLM, Group Policy, and domain join capabilities are compatible.
  • Compatible with both Cloud only tenants and hybrid tenants using Azure AD Connect.
  • No additional costs other than Azure IaaS Virtual Machines.
  • Cloud Only Tenant
    • Managed by Azure.
    • All the Azure AD objects are available within this domain
    • All user identities, credentials and groups, including group memberships, are created and managed in Azure AD.
    • The advantages of this solution are:
      • The domain administrator does not need to manage this domain or any domain controllers.
      • AD replication for this domain does not require management. All objects are automatically available.
      • Azure manages this Domain, so the Azure AD tenant administrator has no domain or enterprise admin privileges.
  • Hybrid Cloud Tenant
    • Synchronized to an on-premises directory
    • An additional stand-alone Domain is created by the managed service.
    • The managed domain is a standalone domain and not an extension to the on-premises directory.
      • Tenant identities are still created and managed within Azure AD
      • On-premises identities are still created and managed on-premises.
    • All objects from the on-premises domain and the Azure AD tenant are available to the managed service domain.
    • Allows users to sign in to cloud services with their on-premises identities
      • Azure AD Connect must be configured to allow password synchronization
        • Allows resources in the cloud to connect to the managed domain can use Kerberos to authenticate.
    • The advantages:
      • The domain administrator does not need to manage this domain or any domain controllers for the managed domain.
      • AD replication for this domain does not require management. All objects are automatically available.
      • Azure manages this Domain, so the Azure AD tenant administrator has no domain or enterprise admin privileges.
• Azure AD Pass-Through Authentication
  • Enables users to sign in to both on-premises and cloud applications using the same credentials.
  • Azure AD validates users’ passwords against your on-premises Active Directory.
  • No need to deploy ADFS infrastructure.
    • No need for complicated certificates or trusts.
  • Azure AD Connect installs Pass-through authentication agent on same server where it is.
    • 💡 Install additional agents to make the service highly available.
  • Free for all Azure AD tiers.
  • Multi-forest environments are supported, although some routing changes may be required.
  • Users can be enabled to use self-service password management from the Azure AD directly.
  • No additional ports or network configuration is required since the agent communicates outbound, so no perimeter network is required.
  • Secure storage of passwords since on-premises passwords are never stored in the cloud.
  • Takes advantage of Azure AD Conditional Access policies, including Multi-Factor Authentication (MFA).

Networking Azure Application Components

• Virtual Networks
  • VNet => the logical unit of multiple or all network resources in an Azure region.
  • Within a VNet, you create one or more subnets.
    • 💡 All traffic within a subnet is allowed, but communication across different subnets is blocked by default
  • Several Azure Resources are making use of VNets and subnets for IP addressing
    • IaaS e.g. :Virtual Machines, VM Scale Sets, Load Balancers, Azure Traffic Manager,…
    • PaaS e.g. : Service Fabric, Azure Container Services, Hadoop, Azure Application Services,…
  • Network Security Groups (NSGs)
    • Software-defined firewalling
    • Protects incoming traffic to Azure public IP addresses.
    • Top level object that is associated to your subscription.
    • Rules
      • Inbound rules are applied on the incoming packets to a VM.
      • Outbound rules are applied to the outgoing packets from the VM.
      • Can be changed at any time, and changes are applied to all associated instances.
      • An incoming or outgoing packet has to match an Allow rule for it be permitted, if not it will be dropped.
      • By default
        • Connectivity to the internet is allowed for Outbound direction.
        • Blocked for Inbound direction¨
      • 💡 The default rules cannot be deleted, but because they are assigned the lowest priority, they can be overridden by the rules that you create.
        • For example, a rule with a lower priority number (e.g. 100) is processed before rules with a higher priority numbers (e.g. 200). Once a match is found, no more rules are processed.
    • Can be assigned to both VNet and VM (individual NIC).
    • ❗ Limitations:
      • A VM or subnet can be associated with only 1 NSG, and each NSG can contain up to 200 rules.
      • You can have 100 NSGs per subscription.
      • NSGs cannot span Azure Regions.
  • Multi-Region Virtual Network Architecture
    • Applies for cross regions and on-premises
    • 💡 From the Public Internet, Azure allows for load balancing across multiple Azure Regions by deploying Azure Traffic Manager.
    • Interconnecting Azure Regions with each other is possible in three different ways:
      1. Configuring Azure Site-to-Site VPN between both regions
         • Encrypted tunnel connection over internet.
      2. Configuring Azure ExpressRoute communication tunnels
      3. Azure VNET Peering Networking without encryption.
    • Interconnecting Azure Regions with on-premises datacenters is possible in two different ways:
      1. Configuring Azure Site-to-Site VPN between Azure and on-premises
      2. Configuring Azure ExpressRoute communication tunnels between Azure and on-premises
• IP Addressing
  • IP-address gets allocated to a NIC during provisioning of the NIC
  • First available IP-address in a subnet range is x.x.x.4
  • Azure Subnets support dynamic (=default) and static IP addressing
• Public IP-addressing
  • Used for all public internet-facing communication
  • Required parameter when creating a VM from the portal
• Private IP-addressing
  • Used for all inter-VNET communication
  • Used for all communication between an Azure VNET and an on-premises VNET
  • Azure DNS Resolving
    • DNS Server settings are configured on VNET level
    • Using Azure DNS is the default configuration setting, but this can be modified
      • Use your custom DNS configuration:
        • Azure DNS Appliance (from Azure MarketPlace)
        • Azure VM (e.g. Windows ADDS with DNS)
        • On-premises DNS solution (requires connectivity)
    • Public DNS names (available for VMs and App Services) must be unique across Azure regions.
      • An example of such Public DNS name is host.region.cloudapp.azure.com
• Load Balancing
  • Azure provides several built-in Azure Load Balancing Solutions:
    1. Azure Load Balancer
       • Can be configured both as an external load balancer, or as an internal load balancer.
         • where one cannot act as both external and internal at the same time.
       • Uses private IP addresses in back-end pools.
         • You can associate it to a Availability set, Single virtual machine or Virtual machine scale set
           • 💡 In an availability set, it allows it to grow to 10x the number of instances (100 in Basic to 1000 in Standard in a single Availability Set).
       • Can handle almost any TCP or UDP traffic e.g. RDS (Remote Desktop Services Farm), Linux SSH.
       • External load balancer
         • The load balancer front-end is configured with a Public-facing IP-address
         • Sends all traffic along to the back-end pool servers, using their internal IP-addresses.
       • Internal Load Balancer
         • Doesn’t have a Public-facing IP-address, and all communication is based on internal IP-addressing and IP-routing.
         • Used for e.g. database Server backends
       • SKUs | Basic | Standard | | — | — | | Up to 100 backend instances | Up to 1000 backend instances | | Single Availability Set | Availability Sets are not required; providing support for Availability Zones | | Basic NAT and Probe health status | Integrated Frontend and Backend health metrics | | No HA Ports | Support for HA Ports | | Network Security Groups (NSG) are optional | Network Security Groups are required during configuration and deployment | | Free | Charged hourly based on number of rules configured (except NAT) & data processed |
    2. Azure Application Gateway
       • Load Balancing, active on Layer 7 of the network stack; this mainly means it is “application intelligent.”
       • Main features Application Gateway provides, compared to Azure Load Balancer, are:
         • HTTP/HTTPS traffic only, no other ports allowed
         • SSL Offloading
         • Cookie Affinity
         • Web Application Firewall (WAF)
         • URL Based Routing
       • SSL Termination
         • SSL Offloading, by importing the SSL Certificate onto the App Gateway; traffic to the backend servers don’t require HTTPS communication, also that would still be an option.
         • HTTP to HTTPS redirect ; this means that, whenever a user is connecting to the web app using HTTP, the request will be redirected to HTTPS, forcing SSL Tunneling for this given request.
       • Web Application Firewall (WAF)
         • Protection against several common attacks and threats on application workloads.
           • E.g. SQL Injection, Cross-site scripting, Protocol violations, Generic attacks, HTTP rate limiting, Scanner detection, Session fixation, LFI/RFI.
    3. Azure Marketplace Load Balancing Appliance
       • Recommended for more capabilities around management, monitoring and control.
       • Support is initially provided by Microsoft, backed by SLA’s, and acting as a SPOC (Single point of contact).
       • 2 licensing models:
         • BYOL, Bring Your Own License
           • This is an ideal candidate if you are removing or downsizing on your on-premises running third-party load balancer.
           • Depending on the specific licensing terms of the vendor, one can reuse the license key on the Azure VM Appliance.
         • Pay-Per-Use
           • The monthly Azure VM consumption cost is based on the VM Size allocation to the Appliance, as well as a monthly licensing fee for the third party load balancing application within the VM.
    4. Azure Traffic Manager
       • Control the distribution of user traffic to your specified endpoints.
       • It works by applying an intelligent policy engine to Domain Name System (DNS) queries for the domain names of your internet resources.
       • Very flexible because as it allows you to mix various endpoints behind the same DNS name.
       • Often use cases are:
         • Failover
           • Can poll to determine if and endpoint is online or offline.
           • Traffic is routed in the next online endpoint that’s highest in the priority list.
         • Geography Uses Internet Latency Table to find closes endpoint to the client.
         • Distribution
           • Near-random way to distribute evenly across set of endpoints.
           • Distribution can optionally be weighted.
             • 💡 Weighting is good if you have a smaller recovery site and want to keep majority of the traffic to the primary site using larger service tiers.
       • Easy to integrate with Web Apps.
       • Workflow
         1. User traffic to company domain name, e.g. fabrikam.com
         2. Company domain name to Traffic Manager domain name
            • CNAME resource record that maps the company domain name (e.g. fabrikam.com) to traffic manager domain name (e.g. fabrikamweb.trafficmanager.net)
         3. Traffic Manager domain name and profile: The user’s DNS server sends a new DNS query for the Traffic Manager domain name (e.g., fabrikamweb.trafficmanager.net), which is received by the Traffic Manager DNS name servers.
         4. Traffic Manager profile rules processed: load balancing method and monitoring status to determine endpoint.
         5. Endpoint domain name to user:
            • Returns CNAME that maps Traffic Manager domain name to the domain name of the endpoint.
            • Users DNS server resolves domain name to IP and sends it to user.
         6. User calls the returned endpoint directly by using its IP address.
• Connectivity options
  • On-Premises to Azure Connectivity
    • This can be between an on-premises network and one or more Azure regions, or between multiple Azure regions | Connectivity | Benefits | | — | — | | ExpressRoute | • 💡 Use ExpressRoute as primary cross-premises connectivity. • Multiple circuits for redundancy & better routing. • 💡 Use ExpressRoute-VPN co-existence for highly available, redundant paths. | | Site-to-Site VPN | • 💡 S2S VPN over internet for remote branch locations • BGP & active-active configuration for HA and transit | | Point-to-Site VPN | • P2S VPN for mobile users & developers to connect from anywhere with macOS & Windows • AD/radius authentication for enterprise grade security |
    • Multi-Region VPN Connectivity
      • Forced Tunneling
        • Azure traffic can be rerouted to an on-premises virtual network, to be routed through an existing Site-to-Site VPN or ExpressRoute, into the internal Azure VNET.
        • Security improvement as internal Azure VMs are no longer accessible through the public internet.
  • Securing Access to PaaS Services
    • If you want to disable access to PaaS services from public internet.
      • Use VNET service endpoints, where you define which PAAS services are no longer accessible through the public internet
        • Virtual network service endpoint
          • ❗ Only available to Azure Storage Accounts, SQL DB Services in PAAS and Web Apps.
          • Provides the identity of your virtual network to the Azure service.
          • Service endpoints are configured on a subnet in a virtual network
          • You can configure multiple service endpoints for all supported Azure services on a subnet.
          • VNets and resources can be in different subscriptions and regions with exceptions:
            • ❗ SQL VNet must be in same region.
            • ❗ Storages Storage Account must be in same region.
        • Flow:
          1. Connect storage account to a VNet.
          2. Add service endpoints to the VNet.
          3. Once service endpoints are enabled in VNet, you can secure Azure service resources to your virtual network by adding a VNet rule to the resources.
      • Access from on-premises
        • You must also allow public (typically, NAT) IP addresses from your on-premises or ExpressRoute.
        • Those IP addresses can be added through the IP firewall configuration for Azure service resources.
  • VNET Peering
    • Uses the Microsoft Backbone (not the public internet).
    • Communication relies on internal IP addressing.
    • Primary features
      • Allows you to interconnect 2 Azure VNET as if they are 1 large VNET.
      • Possible within the same Azure region, or across Azure regions
      • Supported to interconnect an Azure Classic VNET with an ARM VNET (e.g., for migrating workloads).
    • 💡 If VNET peering is not an option, because you might want to encrypt your traffic within the VNET tunnel, deploy a VPN Gateway on both Azure Regional VNETs to create a Site-to-Site VPN tunnel across those regions.

Messaging Services

• Messaging services: Azure Storage Queues, Service Bus Queues, Service Bus Relay, IoT Hubs, Event Hubs, and Notification Hubs

• Integration services include Azure Functions and Logic Apps.

• Event Messaging
  • Storage Queues
    • Components
      • Storage account
      • URL: E.g. http://[account].queue.core.windows.net/\<queue>
      • Queue: A queue contains a all of messages.
      • Message: A message, in any format, of up to 64KB.
    • Storage Queue Message Handling
      • 💡 Processors/consumers must be designed to not have side effects from processing the same message multiple times.
        • E.g. if it inserts to SQL it should check first if record exists.
        • Service Bus Queues on the otherhand guarantees that a message is handled at least and most by single customer.
      • Operations:
        • Create/Delete Queue: Client SDKs, PowerShell or the REST API
        • Measure Queue Length
          • You can get an estimate of the number of messages in the queue
          • ❗ This count is not guaranteed and should be treated in your application as an approximate queue length.
        • Insert Message into Queue: Either a string (in UTF-8 format) or a byte array.
        • Retrieve the Next Message
          • A copy is retrieved
          • Message is made invisible for a specific duration
            • After duration the message is available to other queue consumers.
        • Extend Message Lease: You can return to the queue and update the invisibility duration for the queue message
        • Peek at the Next Message: Does not make message invisible
        • Update a Message
          • The contents of a retrieved message can be updated in the queue
          • Used e.g. with checkpoints or state for queue messages.
        • Delete a Message: Otherwise invisible will timeout and message will be reprocessed.
  • Service Bus
    • Infrastructure for communication, event distribution, naming and service publishing.
    • Provides connectivity options for Windows Communication Foundation (WCF) and other service endpoints e.g. REST
      • Endpoints can be located behind network address translation (NAT) boundaries, or bound to frequently-changing, dynamically-assigned IP addresses, or both.
    • Partitioned into namespaces as each namespace provide both a service and security boundary.
    • Provides both relayed and brokered messaging capabilities
      • Relayed messaging pattern (relays)
        • Direct one-way messaging
        • Request/response messaging
        • Peer-to-peer messaging
      • Brokered messaging pattern
        • E.g. topics (one-to-many), queues (one-to-many), Event Hub.
        • Available through APIs and SDKs over HTTP.
        • Asynchronous messaging with Queues, Topics and Subscriptions
        • Publish-subscribe and temperal decoupling
          • Senders and receivers do not have to be online at the same time.
            • Messages are stored until they are received.
    • Service Bus Queues
      • Extends Storage queues.
      • Implements FIFO.
      • Guarantees that message is received and processed both at least and at most once by the message consumers
      • Flow: Message sender (e.g. web app, mobile app and service) => Namespace (contains queue) => Message receiver (service or application)
    • Service Bus Relay
      • Connects existing services to new client applications without exposing the true location or address of the service.
      • Supports direct peer-to-peer communication
      • Advantages / Use-cases:
        • On-prem resources can be revealed without them having a public IP address but using outbound connection.
        • Abstraction helps with having same URI pointing out different resources.
      • Flow: Application <=> Service Bus Relay <=> Client1, Client2
  • Event Grid
    • Single service designed to manage and route systemic events from any source service in your Azure subscription.
    • Removes need to polling
      • Triggers applications when needed
      • Pay per event: Consume compute only when necessary.
    • Can use custom workloads or pre-determined events with each Azure service.
    • Reliability through the use of a 24-hour retry with exponential back-off.
    • Example ways to use:
      • Integration: Integrate various components of your workloads together using a publish-subscribe mode.
      • B2B: Enable your solution to listen to events from third-party B2B services of publish events for the third-party services to consume.
      • Compute: Create serverless compute that is triggered by a specific Azure service event such as the creation of a database or VM.
      • Ops automation work: Automate the deployment of resources by subscribing to ARM events.
        • E.g. a user can request Event Grid to notify Azure Automation when a virtual machine starts or a SQL Database is spun up.
          • Events can be then used to e.g.
            • Tag virtual machines
            • File work items
            • Put metadata into operations tools
            • Automatically check to ensure services configurations are correct.
      • Router: You can use filters to route specific events to different or even multiple endpoints.
        • You can route to a WebHook endpoint or event handler.
• Integration
  • Serverless Integration
    • Serverless applications: Azure Logic Apps, Azure Functions.
    • Development: IDE support, visual debug history, local development, verbose debugging.
    • Platform:
      • Functions: Developer Tooling, Bindings and triggers, open source
      • Logic Apps: Visual designer, 200+ connectors, functions orchestration
      • Even more such as data/storage, messaging, gateway connectors, intelligence, bots
  • Notification Hubs
    • Service infrastructure and a set of client libraries that allows you to publish push notifications.
    • Can send to specific user, all users or segmented users.
    • Abstracts the implementation of the various Platform Notification Systems (PNS) for each mobile platform with a single method call.
      • Devices are only responsible for registering PNS handles.
      • Backend is responsible for sending platform-independent messages to users or interest groups.
    • Advantages
      • Multiple platforms
      • Works with any backend
      • Scale
      • Rich set of delivery patterns
      • Personalization: Each device can have one or more templates to achieve per-device localization and personalization without effecting the back-end code
    • Platform notification system flow
      1. Client application contacts the PNS to retrieve its handle.
      2. Application stores the handle for later usage.
      3. App back-end contacts the PNS by using handle to target a client application.
      4. PNS forwards notification to the device specified by the handle.
    • Notification hub flow
      1. Client reaches out to the PNS through Notification Hubs SDK and registers PNS handle.
      2. Alternatively, client sends PNS handle to application backend to have the application register the service.
      3. Application back-end sends message to Notification hubs service, service forwards it to appropriate target client by using their PNS handles.
  • Internet of Things (IoT)
    • Event Hubs
      • Event ingestion service
      • Can be used as a “front line” for an event pipeline of a solution architecture, sometimes known as an event investor
        • An event investor is a service or component that sits between the event consumers and publishers to separate the production of an event stream that obtained said events.
      • Capable of publishing via AMQP 1.0 or HTTPS
      • It can capture Event Hubs streaming data to store in an Azure Blob storage account.
        • Allows e.g. :
          • to each consumer to read a specific subset of the event stream
          • to consumer to act independently
      • Uses SAS (Shared Access Signature) tokens
        • Can identify and authenticate the event publisher though SAS tokens.
      • Pricing
        • Throughput units or Pre-purchased units of capacity
        • Throughput units can include the capacity of either 1 MB per second or 100 events per second
        • Up to to 2 MB per second if its egress
        • Units are billed hourly for a minimum of one hour, and up to a maximum of 20 throughput units per Event Hubs namespace.
      • Flow: Event Producers –HTTP,AMQP–> Partitions -> Consumer Groups -> Event Recievers.
      • Common scenarios
        • Process streams
        • Save in long/term storage e.g. service bus, Azure DBs, HDInsight, Azure Storage, Azure Data Lake
        • Present take actions through Power BI Dashboards, Search and query, Cortana analytics, Devices to take action
    • IoT Hubs
      • Provides reliable and secure bi-directional communication between a multitude of IoT devices with a solution back end.
      • Message routing option built in that sends the message to other Azure services
      • More advanced & device specific than Event Hubs
        • Can provide additional features such as Device twins, which can be used to store and research device state information.
        • Event Hubs handles only event ingress communication (device-to-cloud) while IoT provides device-to-cloud and cloud-to-device communication.
      • You can use an IoT Hub to receive messages from a device and then push them to a Logic App for processing
        • ❗ Up to 10 endpoints are supported.
      • Connection & security
        • Uses outbound connection only from devices.
        • The path between device and service must be secured at application protocol layer.
        • Requires gateway that can be protocol gateway or field gateway
          • Protocol gateway
            • Always deployed in the cloud
            • With a protocol gateway protocol, translations are carried out, such as MQTT to AMQP.
          • Field gateway
            • Deployed locally with a device.
            • You can make time-sensitive decisions, run analytics on edge, provide device management services or even enforce security and privacy constraints.
    • Event Hubs vs IoT Hubs | Area | IoT Hub | Event Hubs | | — | — | — | | Communication patterns | • Device-to-cloud communications (messaging, file uploads, and reported properties) • Cloud-to-device communications (direct methods, desired properties, messaging). | Only enables event ingress (usually considered for device-to-cloud scenarios). | | Device state information | Device twins can store and query device state information. | No device state information can be stored. | | Device state protocol | • Supports MQTT, MQTT over WebSockets, AMQP, AMQP over WebSockets, and HTTPS. • Works with the Azure IoT protocol gateway, a customizable protocol gateway implementation to support custom protocols, authentication, message transformations etc.| Supports AMQP, AMQP over WebSockets, and HTTPS. | | Security | Provides per-device identity and revocable access control. See the Security section of the IoT Hub developer guide. | Provides Event Hubs-wide shared access policies, with limited revocation support through publisher’s policies. IoT solutions are often required to implement a custom solution to support per-device credentials and anti-spoofing measures. | | Operations monitoring | Enables IoT solutions to subscribe to a rich set of device identity management and connectivity events such as individual device authentication errors, throttling, and bad format exceptions. These events enable you to quickly identify connectivity problems at the individual device level. | Exposes only aggregate metrics. | | Scale | Is optimized to support millions of simultaneously connected devices. | Meters the connections as per Azure Event Hubs quotas. On the other hand, Event Hubs enables you to specify the partition for each message sent. | | Device SDKs | Provides device SDKs for a large variety of platforms and languages, in addition to direct MQTT, AMQP, and HTTPS APIs. | Is supported on .NET, Java, and C, in addition to AMQP and HTTPS send interfaces. | | File upload | Enables IoT solutions to upload files from devices to the cloud. Includes a file notification endpoint for workflow integration and an operations monitoring category for debugging support. | Not supported. | | Route messages to multiple endpoints | Rules determine how messages are routed to custom endpoints. ❗ Up to 10 custom endpoints are supported. | Requires additional code to be written and hosted for message dispatching. |
    • Time Series Insights
      • Product built for visualizing, storing, and querying vast amounts of time series information, such as information generated by IoT devices
      • Requires no upfront data preparation
      • It can obtain and store millions of sensor events per day with a one-minute latency, giving it the ability to provide near real-time insights
      • The way it works
        • Time series data shows how an asset or process changes over time.
          • It has a timestamp that is unique to its kind which is most meaningful as an axis.
        • The time series data arrives in time order and can usually be an insert rather than an update to your database.
        • Because time series data obtains and stores every new event as a row, the changes can be measured over a time frame, enabling one to not only look back into the past but also predict the future with the data.
      • When to use?
        • Storing and maintaining time series data in a scalable format.
        • Near real-time data visualization
          • When you connect an event source, the event data can be viewed, queried, and explored.
        • Producing customer application with REST API.
        • Global view of time series data streaming from different locations for multiple sites or assets
          • Allows you to connect multiple event sources to the environment

This site is open source. Improve this page.