7 Cool things I like about Azure
Where Azure Stands out ….
Today there are 3 big names when it comes to Public Cloud — AWS, Azure and GCP. While majority (~85%) of their offerings are similar, each of them have few differentiators which makes it stand out from rest. In this article I list down few of the Azure Cloud Offering where it stands out from other 2 public cloud providers. Either they do not have similar offerings, or the features provided by Azure outweighs their offering.
1. App Service Plan — As part of any cloud offering we get IaaS, PaaS or SaaS services. In the IaaS service, typical offering is Virtual Machines(VMs) where we get compute/memory on pay as you go basis and we need to take care about maintaining the VMs in terms of keeping them up-to date with latest updates and anti-virus software. The upside is that we get good control of the VMs which we need to deploy and manage Enterprise Applications. With App Service Plan we do get sets of Virtual Machines where we can deploy our Enterprise Application, but the service is completely managed by Azure. This means we do not have to worry about maintaining the underlying Operating System. What’s more is that we can manually or auto scale the App Service Plan as the application grow (or its usage grows). It allows for horizontal as well as Vertical Scaling. As part of App Service Plan we can host web apps or even background jobs. App Service plans provide various pricing tiers ranging from free (shared with other customer) to completely Isolated (at host level). It integrates with Azure Dev Ops in terms of upgrading the App, providing for Green/Blue Deployment slots (for production and staging). The App Service plan can be natively connected to an Azure Virtual Network which means that traffic between the applications deployed on App Service Plan and that on Virtual Network will flow via Azure Backbone network and not thru the public Internet.
2. Integration with Active Directory — While the cloud offerings are relatively new, the IT operations of Enterprises are not. It means whichever organization undertake its cloud transformation journey; it will already have existing Identity Management Solution in place. Also, for a good period both the on-premise application and cloud applications are going to exist together. What it inherently means that you would need to support both On-Prem Identity Management Solution along with Cloud based Identity Management Solution.
Now as an Identity Management Solution Microsoft Active Directory is widely implemented with as much as 95% of fortune 500 companies using the same. What Azure offers is seamless integration of on-premise Microsoft Active Directory with Azure Active Directory. Azure AD connect provides easier user synchronization across the two Active directories. You can use Password Hash Synchronization (where users can be authenticated from either on-premise AD or from Azure AD) or a Pass Thru Authentication (where Azure AD uses on-premise AD for user authentication in a manner transparent to user).
Azure AD offers a feature rich identity management solution where you can provide Just In Time Access to users or create dynamic groups (based on some attributes such as Job Title) or conduct reviews of users access or even enforce various policies. Using the Pass Thru Authentication we can use all the features available with on-premise Active Directory as well.
3. Migration of VMs — Native Support from Hypervisor hosts. — Once an enterprise decides to embark on its cloud transformation journey, the major task it must undertake is migration of its existing estate on cloud. There are multiple ways to approach the migration as denoted by 6Rs –
a. Repurchase — Here you drop your existing legacy applications e.g. CRM and go for a new cloud-based application e.g. SaaS, Outlook365
b. Rehost (Lift and Shift) — Here you basically deploy the VM from your datacenter onto the clouds or just deploy existing app onto cloud in a VM. There is no change of architecture or platform whatsoever.
c. Re-platform — Here you change the platform of your application for eg. Instead of using SQL DB on legacy you start using the cloud PaaS offering of SQL DB (this is completely managed and hence takes less operational support). Azure allows you to use the existing on-premise license as well.
d. Refactor/Re-Architect — As part of this, you rearchitect your legacy application into a cloud native application. The cloud native application uses cloud services and hence is more available, scalable, and manageable.
e. Retire — You just retire some of the application that you realize are no longer required post migration.
f. Retain — Keep the application on-premise due to lack of business case for moving onto cloud.
For the cloud transformation, majority of the applications would fall in the Rehost category — here you would have machines hosted on-premise within your datacenter. Azure provides Site Migration Services, where it can assess the current on-premise machines (whether on Hypervisor or VMware or Physical Servers) and suggest the compute required on cloud. It also creates the supporting infra on cloud such as Virtual Network, Storage and migrates the on-premise machines (whether on Hypervisor or VMware or Physical Servers) onto cloud Virtual Machines. You also have replication option to check if everything is working fine on cloud before you failover the on-premise machines.
4. Multiple Backend APIs for No-SQL Databases — Azure offers NoSQL database as a PaaS service. However, when it comes to NoSQL databases, there are various ways that underlying data can be stored — as Documents, or Name-Value Pairs or Graph.
With Azure you get to choose what kind of underlying No SQL Database are you looking for by selecting the right APIs. Azure offers the following APIs for its No SQL PaaS service Cosmos DB -
a) MongoDB API — Stores JSON Documents.
b) Table API — Stored as Name-Value pair.
c) SQL API — Stores JSON document.
d) Cassandra API — Columnar DB.
e) Gremlin API — Graph DB.
5. Azure SQL Database Elastic Pool — As part of Database elastic pool, you can have a set of databases and they all share underlying resources. This way you can combine a set of Databases with varying loads (peak load at different times), you can put them in elastic pool to reduce the overall cost. Here you do not have to over-provision individual Databases to service their peak load, but the underlying shared capacity takes care of peak (and varying) load of all the Databases.
6. Traffic Routing and Load Balancing — While all the public cloud offers Load Balancing Services but what’s different is the range of Traffic Routing and Load Balancing services that azure offers. It ranges from simple Layer 4 Load Balancer (which distributes load based on Source IP, Destination IP, Port, and protocol) to the following –
a. Application Gateway — Layer 7 load balancer to distribute traffic based on URL path, provides SSL offloading, safety from SQL injection using Web Application firewall, provides session affinity and supports multisite routing.
b. Traffic Manager — DNS based multi Region routing service with options to route traffic based on Priority of destination, Weightage given to each destination, Latency for each destination, Subnet and Geography or even allows the client to select the destination.
c. Front Door — This basically combines both Traffic Manager and Application Gateway which means it’s a Layer 7 load balancer across region with multiple options to route traffic.
d. Content Delivery Network — Not directly a load balancer but improves user experience by servicing the static content from nearest edge location across the regions.
7. Serverless (but on server) — All the ley public clouds offer services to execute code in a serverless manner i.e. we pay only for the execution time of the code and not when the code is sitting idle waiting to be invoked. While this works well in terms of cost for the code that is sparingly invoked and that too for a short duration of time(say days) but the cost advantage that it offers starts to wane when the code that we want to deploy serverless needs to be executed regularly for large duration of time(say months or years). Azure offers the serverless functions to be deployed both in ‘Consumption’ mode and ‘App Service Plan’ mode. In the consumption mode, the functions work as true serverless (pay only for the time function runs) where in the ‘App Service Plan’ mode, we deploy the function as part of App service plan; it uses the combined resources of the app services when invoked and hence there are no extra charges apart from the App service Plan charges. While we do need to consider this function while provisioning the App Services Plan but App Services plan supports auto-scaling meaning we can avoid paying for the extra capacity and cost per execution second of the function within App service plan is much cheaper as compared to when deployed in serverless mode. Besides the functions can be trigger from a lot of other services such as Blob Storage or Queue Storage or Event Hubs apart from the usual HTTP based or time-based trigger.
Abhinav Ajmera
Senior Data Scientist, Cloud and Data Architect
The opinions of the author are personal, and author is in no way associated with Microsoft.
