We already said that Microsoft announced their version of the public cloud in 2008 and public release was in 2010. At this time, the official name for Microsoft's public cloud platform was Windows Azure. The name was changed in April 2014 to Microsoft Azure. The reason for the change was never publicly announced but there were many guesses. One of the theories was that Microsoft needed to change its name due to embracing open source software. As Microsoft added a Linux virtual machine to their offering, the name convention became too confusing. A virtual machine running Linux on a Microsoft public cloud would initially be Windows Azure Linux virtual machine, and having Windows and Linux in same name was confusing indeed. Changing it to Microsoft Azure Linux virtual machine made more sense. Now, this is only one of the theories that you can find and not an official reason for the name change.
Not only the name changed over the years. The first version of Azure, Windows Azure, had completely different specifications and a different type of portal. The first Azure portal was accessed at the address https://manage.windowsazure.net and was based on Silverlight. This portal was later referred to as a classic portal and the model of management for resources created in the classic portal was referred to as Azure Standard Management (ASM). The classic portal layout is shown in the following screenshot:
At this time, Microsoft realized there were issues with their cloud model and started working on completely new fabric. In 2014, a new Azure portal was announced. Along with a new portal, we got a new model of management called Azure Resource Manager (ARM). ARM brought new features like role-based access control (RBAC) and resource groups.
These features changed how we managed resources in the cloud. In ASM, the only way to allow someone to administrate Azure resources was to add this person as a co-administrator to the Azure subscription. This person would have total access and control over the subscription in question. With RABC, we got the option to give different permission levels to users such as reader or contributor, without giving them full access to the subscription.
Resource groups went even further. Resource groups in Azure represent logical containers where you can place resources depending on the convention of your choosing. For example, you can place all resources that are used by a single application in a single resource group. This would allow you to give user access to a single resource group with the option to manage or access only that specific resource group. When that user logs in to the tenant, he will be able to see only the resource group that was assigned to him even if you have other resource groups under the same subscription or tenant. You could go further with RABC and assign only users to a specific resource but that is too granular and hard to manage. Assignment based on resource groups is considered best practice and the best way to manage Azure resources.
The new Azure portal was considered a preview version until December 2015. At that time, it became an official portal and could be accessed at the address https://portal.azure.com. This portal became available in April 2014, when it was announced, but it was a preview version. The new portal layout is shown in the following screenshot:
The classic portal was announced to be retired and this eventually happened in January 2018. Along with RBAC and resource groups, ARM brought us another amazing feature—ARM templates. ARM templates are JSON files that hold information about Azure resources and can be used to deploy new resources or edit existing resources.
With the ARM model and ARM templates, Microsoft stepped up and really changed cloud business. In the cloud and in DevOps, the Infrastructure as code (IaC) concept is very important and that was exactly what ARM templates were. You are able to create an ARM template and reuse it multiple times to create similar environments. By doing so, you automated your infrastructure deployment steps and removed possible mistakes in the deployment and configuration process.