Demystifying Azure Cloud Service: Cloud Services and Virtual Machines – Part 3


I have noticed that there is a general sense of mystery around Azure Cloud Service. Some equate it to Cloud Services in general while others get confused with the relation of Azure Cloud Service and Virtual Machines while some one else gets confused about using Azure Web Apps (formerly Websites) with webjobs over Azure Cloud Service. If you have been in a similar dilemma as I have been in the past, I will try and clarify the confusion and get you started on Azure Cloud Service through this tutorial series.

image

Demystifying Azure Cloud Services – Part 1

Demystifying Azure Cloud Services: Cloud Service or WebApp? – Part 2

So we have covered basics of Cloud Services and how are Cloud Services different from WebApps. In this post, we will dig into how does cloud service relate to virtual machines. As explained in Part 1, Azure as a cloud platform had started with Cloud Services and then when the requirement came to gaining more control on the instances hosting the website, this gave rise to infrastructure as a service in the form of virtual machines. Hence, as we understand it today virtual machines are essentially a collection of virtual hardware resources such as cpu, ram and storage disks which are logically grouped together and presents itself to us a virtual machine.

From a cloud service perspective: Cloud Services (web and worker roles) are hosted on instances and these instances can be thought of as virtual machines with limited access and control.

From a Virtual Machine perspective: Virtual machines are built on the cloud service architecture. VMs reside in a role which resides in a cloud service. This was done to take advantage of the load balancing and other capabilities of cloud services.

In the current portal, when ever you create a Virtual Machine, you always specify a cloud service  (either existing or create a new one) in which the VM will reside. The new preview portal has clarified the confusion by not referring it as Cloud Service but as domain name while creating the VM as shown in the diagram below.

image 

If you are wondering why I have made the last statement bold is because a whole lot of us have been wanting this change and it is finally here. This clears a lot of confusion about the relationship between VMs and cloud services.

Although VM still uses cloud services, but is aptly renamed as domain name since that is exactly what the cloud service does, ie assigns a domain name or a public DNS to the VMs. VMs within the cloud service interacts through ports. The ports, also called as endpoints, can be created as private or public. If public, and set to Auto, the cloud service assigns a port number to the VM automatically. The VM interacts with the outside world through this public port. VMs interact with each other within the same cloud service through these ports. Lets explain this through a scenario.

Consider the following environment:

  • 3 Virtual Machines: vmtest1, vmtest2, vmtest3
  • All VMs in the same domain (formerly cloud service): vmtest.cloudapp.net
  • Assigned public port numbers (either created manually or automatically): vmtest1:3333, vmtest2:3334, vmtest3:3335

Now if someone from the public domain wants to communicate with vmtest2, they will want to refer to: vmtest.cloudapp.net:3334. Once vmtest.cloudapp.net receives a request for traffic to port 3334, it will redirect the traffic to vmtest2.

To clarify this further, while creating VMs, you assign (or create a new) a domain name. You can have multiple VMs within the same domain. Think of the domain as a container of VMs. This domain was initially called as Cloud Service. When a domain is not assigned in a virtual network, it is referred to as a Stand Alone Cloud Service ( or Domain). VMs within the same stand alone domain interact with each other through public ports and the traffic goes through the public internet. If you don’t want the traffic to go through the public internet, define a virtual network and assign the domain to this virtual network in which case, the communication between the virtual machines will not go through the public internet. More on cloud services and virtual network in following posts of this tutorial series.

A snapshot of a cloud service (in the preview portal) with multiple instances is shown below:

image

As you can see, the name of the cloud service is MarsLunchLearn. This has 5 VMs which uses the same domain name marslunchlearn.cloudapp.net. In the Roles and Instances section you can see that the role is name of the VM itself, however if we had a web or a worker role, the role would be names as web or worker respectively.

Summary

  • Cloud Services act as containers for roles (web or worker) and instances (virtual machines).
  • From a VM perspective, cloud services are referred to as domains now (in preview portal.azure.com) which still performs as a load balancer and traffic manager for the VMs in it
  • A single VM cannot be a part of 2 different domains (or cloud services), however multiple VMs can be a part of a single domain (or cloud service).
  • Once you delete all the VMs in a domain (or cloud service), the domain still exists and needs to be deleted exclusively in case you want to reuse the name

Hope the confusion between cloud services and virtual machines are clarified. If you still have further questions or doubts please reach out to @AdarshaDatta. In the next post I will cover Virtual networks and Cloud Services and how are they related. Stay tuned!

 


Comments (3)

  1. SMACLAREN says:

    Fantastic articles. Greatly appreciated, as there is little in depth discussion on this I feel.  Having been bamboozled by the Azure calculator (which is not bad) and really not understanding the service parameters relationship to the VM parameters, I may be back soon.. Meantime thanks again.

  2. krishna says:

    Thanks a lot !! real life saver

  3. Sameer Pattanaik says:

    Wonderful article… Clarified a lot of doubt…

Skip to main content