4. WHY AZURE?
• deploy anywhere with Azure as your datacenter
• run virtually any Windows or Linux-based workload
• monitoring, scale and automation is built-in
• flexible hybrid connectivity options
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/regions-and-availability
https://azure.microsoft.com/en-us/regions/
5. • order hardware (and licenses)
• setup networking infrastructure
• setup server infrastructure
• provision storage
• install and patch OS
• install and configure apps
• what if you have multiple environments (prod/dev/test)?
– do it again.
TRADITIONAL DEPLOYMENT
6. • configure virtual network
• deploy VMs
• patch the OS
• install and configure apps
• what if you have multiple environments (prod/dev/test)?
– you automate!
AZURE DEPLOYMENT
7. • identify repeatabe processes
• build automation (scripts, templates, …)
• execute
• what if you have multiple environments (prod/dev/test)?
– change parameters and execute again
DEPLOYING WITH AUTOMATION
8. RESOURCE TEMPLATES
• declarative, model based
• allowing consistent deployment
• source file, checked-in
• parameterized input/output
• „version control your entire infrastructure”
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-
templates
9. • your private network(s) in the cloud
• supports hybrid connectivity to on-premises or other
regions
• offers network traffic segmentation and virtual appliance
support
• deploy virtual machines, cloud services or app services
AZURE VIRTUAL NETWORK (1)
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/network-overview
10. • it provides:
– isolation (vNets are completely isolated)
– Internet connectivity (all VMs have Internet access)
– name resolution (Azure DNS or own DNS)
– Azure resource connectivity (interconnecting resources)
– VNet connectivity (interconnecting VNets)
– on-premises connectivity (interconnecting „datacenters”)
– traffic filtering (Network Security Groups -> L4 FW)
– custom routing if needed
AZURE VIRTUAL NETWORK (2)
11. • keep in mind:
– network latency can be higher, not predictable as on-
premises which is a result of virtualization, security, QoS, load
balancers…
– host VMs in the same virtual network to enable direct
communication
• allows communication via internal IP addresses (DIPs)
• reduces network round trips
– try to place „chatty” application layers on the same VM if
possible
AZURE VIRTUAL NETWORK (3)
13. • ability to connect your datacenter to the cloud or your datacenter in the cloud
to other parts of the cloud
• 3 options
– P2S (point-to-site)
• connect individual computer to the virtual Azure network using SSTP (without
using the Public IP to connect to Azure VMs)
– S2S (site-to-site)
• IPsec/VPN for connecting one or more on-premises networks to the Azure
virtual network
– Express Route
• dedicated connectvity between your network and Azure (through a 3rd party
Express Route partner)
AZURE VIRTUAL NETWORK (5)
14. • multitenant and highly scalable storage system
• two types offering different limits and performance
– Standard
• data is stored on hard disk drives (HDDs)
• Dev/Test scenarios and less critical workloads
• all Azure VMs
– Premium
• data is stored on solid state drives (SSDs)
• scenarios for running I/O-intensive workloads
• only Premium storage compatible VMs (DS-series, DSv2-series, GS-series and FS-
series)
AZURE STORAGE
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/about-disks-and-vhds
15. • Unmanaged disks (the old way)
– traditional type of disks used by VMs
– easy to exceed the scalability of the storage account (~20,000 IOPS)
– user must manage number of storage accounts and disks in each
• Managed disks (the better way)
– Azure handles the storage account creation/management
– simply specify the disk size and the performance tier
(Standard/Premium)
– one storage account per Azure region
– better reliability for Availability Sets
UNMANAGED AND MANAGED DISKS
https://blogs.technet.microsoft.com/canitpro/2017/04/19/azure-managed-disks/
16. • OS disk C: (persistent)
– Dynamic 127GB disk for OS
• Temporary local disk D: (non-persistent)
– Used for temporary data storage & OS page files
– Hosted in attached disks on physical host
– Physical disks shared across other VMs on physical host
– Cleaned up in case of a VM failure or recycling
– DO NOT USE it for user or system database files
• Data disk (persistent)
– A VHD you can attach to a VM to store app data
– Maximum 1TB in size
– Up to 40 disks
VM DISK TYPES
17. AZURE VIRTUAL MACHINES
• most flexible compute option
• supports Windows and Linux operating systems and
most workloads
• built-in capabilities for availability and scale
19. • Resource Group
– container for grouping resources
• Affinity Group
– placed near each other
• Availability Set
– place in different racks
• Fault Domain
– physical racks
• Update Domain
– update at different times
RG, AG, AS, FD, UD ()
20. AUTO SCALE
• automatically deal with under or over provisioned
workloads
• service that starts or stops VMs based on:
– a performance metric
– messages in a queue
– as part of schedule
• simple to configure elasticity with stateless workloads
21. VM EXTENSIONS
• extensible endpoints during
or after VM deployment
• examples:
– antimalware
– monitoring
– reset local password
– DSC
– Chef
– …
22. AZURE LOAD BALANCER
• load balance traffic on public IP or a private (internal) IP for:
– performance (spread the load between multiple VMs)
– fault tolerance (ensure responsiveness if a VM is down)
• supports TCP or UDP protocols (L4 LB)
• flexible affinity options
– source IP, source port, destination IP, destination port,
protocol type
– source IP, destination IP
– source IP, destination IP, protocol
• for more „power” (L7), there are appliances which can be
deployed ()