Udostępnij za pośrednictwem


I’m confused between Azure Cloud Services and Azure VMs – what the ****?

I’ve finally caved in after a webinar yesterday in which this question came up for what seems like the 100th time. So I thought I’d blog it and send people here for the full explanation in the future.

Back in the good old bad old days when Microsoft Azure was first released there were hardly any services. Compute, which in those days was known as “Azure Hosted Services”. There was a SQL database service and some add-on bits of infrastructure to make it easy to build apps – a Security Token Service called the Access Control Service and an app messaging service called “Service Bus”. These bits were packaged up in to something called “Windows Azure App Fabric”. That name was eventually dropped when people got confused between “App Fabric” and the “Fabric” that runs and orchestrates operations inside the Azure data centres.

“Azure Hosted Services” were what you used when you wanted some computers to do some computing for you. There were 2 types of compute roles. Web Roles and Worker Roles. You might typically build a cloud app with say a web front end (for which you’d very likely use Web Roles) and say a middle tier (for which you’d very likely use Worker Roles) and a database back end for which you’d use the SQL DB service I mentioned earlier.

The computers (Windows Servers) that lived in these Roles were known as “instances”. You could have say a Web Role with multiple instances and you could dynamically add and remove instances as the app was running. You could do this with Worker Role instances too.

So you had the instances (servers) inside the roles and the roles lived inside another container called a Hosted Service. All the bits of compute inside a Hosted Service could talk to each other over a common network infrastructure. You could specify which ports were open to each computer (they were all closed by default) and you could connect ports up to a load balancer which was in turn connected to the Internet. So a Hosted Service was like a container for the compute parts of your app. One important thing it was granted, so you could talk to the compute within it, was an IP address that was connected to the Internet (via the aforementioned load balancer).

So here was the idea. As a dev, you’d write some code that would run on your Web Role and some other code that would run on your Worker Role. You’d package that in to a special file called a “Cloud Service Package” (.cspkg). You’d then describe the boxology of your app in couple of XML files in which you’d define the roles you had, how many instances of each role and how powerful each instance was. For example you might have a medium (2 cores, 3.5GB RAM) instance for the Worker Role and a Large instance (4 cores, 7GB RAM) for the Web Role. One file (.csdef) had things like ports and instance sizes, the other (.cscfg) had things like how many instances were in each role.

All you had to do was create these 2 files (you could use Visual Studio) and send them to Microsoft. Then somewhere between 8 and 15 minutes later your app would be live and running on the Internet. Fantastic. No management of infrastructure. Azure would do all the service management, patching, security fixes, failure-management etc for you.

Eventually, this way of doing things - “Hosted Services” - got renamed to “Cloud Services”.

OK, so then customers started saying “…well, I’d love to use Azure but I’d just like to start with an architectural model that’s more like what I have in my own data centre today. I can see how cloud services are great if I write apps to fit exactly in to the cloud services architecture but most of my apps are a few years old and they aren’t written that way – how can you help?”.

So on the 22nd June 2012, Microsoft announced Azure Virtual Machines. Dead easy to create a VM – click New, VM, then select a machine from a gallery. Answer a few questions like what you’d like the machine name to be what you’d like the password to be and so on and a few minutes later you’re running a server.

Virtual Machines were designed to fit in to the existing Cloud Services infrastructure and this is where the majority of the confusion comes from. Because when you look in the portal – it definitely looks like Cloud Services and Virtual Machines are 2 separate things: they are, but they are related:

image

So, if you go in to Cloud Services and click “New” – you’ll be able to create a Cloud Service as I’ve described it in the opening part of this blog-post with Web Roles and Worker Roles and integrated service management, fault management, automatic patching, SPs, security fixes and all that goodness. You’ll get to a question that asks you to supply a .cspkg and a .cscfg. SO at this point it wouldn’t appear to have anything to do with Azure Virtual Machines.

But when you get to page 3 of the New VM Wizard, it asks you to either create a new cloud service, or to put the VM in to an existing cloud service:

image

As I said earlier, VMs leverage the existing Cloud Services architecture. So when you create a VM, it will end up living inside a Role which will live inside a Cloud Service.

You normally don’t see the Role and you’re not all that interested in it anyway. By default, the Role will have the same name as the machine-name. But you have to either put your VM in to an existing Cloud Service or create a new one. This will give any VMs you put in to the same cloud service network access to each other. They will all be deployed on to a common network that is isolated from all the other VMs in Azure. Just like the Cloud Services I described in the opening part of this post. You also get access to a load balancer and you get an IP address that is connected to the Internet.

By default, if you create a new Cloud Service, the wizard will give it the same name as the server. Resist the temptation to accept the default at this point. In the pic above – you can see it wants to create a Cloud Service called plankysrv1.cloudapp.net. Now let’s imagine some time later, you add a new machine called plankysrv2 to this cloud service. It’s going to be confusing referring to plankysrv2 using the DNS name plankysrv1.cloudapp,net. So a much better strategy would be to name the Cloud Service something neutral – say, in this case “plankysrv.cloudapp.net”.

The thing about a Cloud Service, currently, is that whether it’s a “pure” Cloud Service or one that wraps around some Azure Virtual Machines, is that you get a single IP address connected to the Internet. Which means you get a single DNS name too. So you can see a name that doesn’t reference a specific server makes sense.

This is all fine if you don’t connect any of your Azure Virtual Machines up to the outside world. Most of the servers in your private datacentre are not connected directly to the Internet. But what if you create a web-front end across say 3 IIS web servers? Well, that’s where the load balancer comes in. Each Cloud Service has a load balancer connected to the Internet. If you connect your 3 web servers’ HTTP ports up to the load balancer then HTTP requests from the Internet will be load-balanced across all 3 servers.

But what if you want to do some configuration to a specific server and you want to RDP in to it? In that case, the load balancer can map different ports for you. So an example might be that to access different servers you use their port number in the RDP client.

plankysrv1 plankysrv.cloudapp.net:50267
plankysrv2 plankysrv.cloudapp.net:50268
plankysrv3 plankysrv.cloudapp.net:50269

When the load balancer sees an RDP request coming in on port 50268, it knows to send the data to plankysrv2 on the default RDP port (3389). So you don’t need to make any port modifications to the server at all. The Azure load balancer takes care of it for you. When you set up RDP access to your Azure Virtual Machines, you can either set up the port mapping explicitly yourself (like I’ve done in the table above). Or you can just let Azure find a spare high-numbered port for you. This is called “Automatic” and it looks like this when you go through the wizard:

image

OK – so here is what I see in the Cloud Services node, BEFORE I create a new Azure Virtual Machine:

image

If I now create a new VM called plankysrv1 and put it in to a Cloud Service called plankysrv.cloudapp.net – this is what I’ll see in the Cloud Services Node:

image

So that sort of proves that Azure Virtual Machines always end up in Cloud Services. You have no choice. But how can I tell which VMs are in that service? If I drill in to the service and select the Instances tab – it shows me:

image

I’m now going to add plankysrv2 in to the plankysrv.cloudapp.net Cloud Service – a la:

image

In the Cloud Services node, it won’t make any difference, but if I drill in to the Instances tab within the plankysrv.cloudapp,net service, then I’ll see 2 servers now:

image

You might also notice, in the New VM wizard, when you pick a specific Cloud Service, you can’t change the Region once you’ve made the choice. And that’s because a Cloud Service lives in one and only one Region. So whatever region the cloud service is in, that’s where your Azure Virtual Machine will be created. You aren’t offered a choice to change it.

OK, so I’ve now got 2 new Azure Virtual Machines (plankysrv1 and plankysrv2). I’m going to delete both of them. Here is the Virtual Machines node before I delete them:

image

…and here it is afterwards:

image

…so with all the Azure Virtual Machines gone – you’d think the Cloud Service would also disappear wouldn’t you? It forced you to create a Cloud Service with your first Azure Virtual Machine so it should therefore logically undo it when you delete the last Azure Virtual Machine? But that’s not what happens. Because it’s impossible to have an Azure Virtual Machine without an associated Cloud Service. But you can have an empty Cloud Service. It just sits there a bit like an empty shopping bag waiting for you to one day put something back in to it. So if you want to get rid of it – you have to explicitly delete it from within the Cloud Services node. Here is a screenshot of the Cloud Service empty but still in existence:

image

…however, if we take a look on the Instances tab – it’s empty:

image

I hope that’s given you a little bit of an understanding of the relationship between Cloud Services and Virtual Machines. If you always remember an Azure Virtual Machine cannot exist without a Cloud Service, but a Cloud Service can exist without an Azure Virtual Machine – it can be empty. That basic idea will see you through.

Planky == @plankytronixx

Comments

  • Anonymous
    April 24, 2014
    So the empty shopping bag does not be paid I guess

  • Anonymous
    April 24, 2014
    Correct. If there's no VM in the cloud service then there's nothing to pay for. In fact, if you look at my 4th screen shot - you can see machines that are stopped. Well they must live in a cloud service because you can't have an orphaned VM. But you don't pay for them either.

  • Anonymous
    April 24, 2014
    The comment has been removed

  • Anonymous
    June 10, 2014
    So if I have a VM do I pay for the cloud service as well as the VM? Or does a VM associated cloud service come free when you pay for the VM?

  • Anonymous
    June 10, 2014
    The comment has been removed

  • Anonymous
    October 03, 2014
    The comment has been removed

  • Anonymous
    November 19, 2014
    The comment has been removed

  • Anonymous
    November 19, 2014
    OK what I have so far discovered is the Virtual network rules and even splitting a virtual network between 2 cloud services allows full communication between the VMs Subnets of a virtual network also work in an open way (even over cloud services) Now onto different virtual networks

  • Anonymous
    December 28, 2014
    Any response to Mike's questions? Also, how does it matter if I had 5 VMs as a part of a cloud service or as a part of VNET? What is the difference between cloud service and VNET?

  • Anonymous
    December 28, 2014
    Is there any use for an empty Cloud Service [with no VM in it]?

  • Anonymous
    January 19, 2015
    If I have a VM that I do want connect at all to the outside, Can I delete the cloud service for it?

  • Anonymous
    January 19, 2015
    Hi Scott - no. A VM always lives inside a cloud service. If you don't want the VM to be connected to the outside world, just don't connect any endpoints to it. THe only way the cloud service's load balancer will route traffic to the VM is if it has endpoints connected. That's a task you have to explicitly do for each VM. So if you want it entirely self-contained and unable to communicate with the outside world - just don't connect any endpoints. Hope that helps.

  • Anonymous
    February 17, 2015
    Awesome article, thanks! There is really a big confusion about these terms

  • Anonymous
    February 23, 2015
    The comment has been removed

  • Anonymous
    February 25, 2015
    Relax.  Think of the service as the firewall.  You open ports to your VM's, and add Load balanced sets, etc.

  • Anonymous
    March 07, 2015
    You didn't bother reading the article.  Deleting a VM does not delete the cloud service.  You can delete the service, although you probably didn't read that article either, or you can just put your new VM into an existing cloud service.

  • Anonymous
    March 10, 2015
    Thanks you for writing this post. As an infra guy, coming from Virtual Server....  I never really got the whole "why does a VM have a cloud" service and why do I need one. Thanks for taking the time to write this up. Totally helped me.

  • Anonymous
    March 11, 2015
    I said I'd provide a video to answer the person who has named themselves "VMs and Cloud Services - naming". So hopefully you're re-visiting sometime and will see this is really very simple to do. You just have to know what to do. You don't have to use powershell. You can use the standard tools. Also I describe and show the difference between cloud services and VMs and also the *relationship" between them. Hope it helps. Go to this link: http://youtu.be/qyB0HY5g0nI

  • Anonymous
    March 13, 2015
    Great article.  Really clarified relationship between cloud service and VM's.  This is especially useful for those of us with little or no experience with Azure PaaS.

  • Anonymous
    March 23, 2015
    Great article !!! Just had a query, how can I create a VM in a cloud-service with a Web or Worker role using Azure portal ?

  • Anonymous
    March 26, 2015
    Hey, can a VM be in two cloud services?  Like port 80 for one and 21 for another?  I don't think so (did not see that as an option) - but just want to confirm?

  • Anonymous
    March 27, 2015
    Hi Ashish - you can't create web and worker roles in the portal directly. You need to create the code that will run on them and also create a "service model" (it's all done in Visual Studio with the Azure SDK). Then you can either deploy that directly to Azure from VS, or you can use VS to give you a package (a .cspkg file with your code in it) and a configuration file (.cscfg file) and use the portal to upload it and create a live-running cloud service for you. If you just go to the portal (the old portal - Cloud Services haven't appeared in the preview portal - yet!) and click New|Compute|Cloud Service, you'll just have an empty service sat there doing nothing. You need the package and the config. I'd recommend you have a quick watch of a demo I do of it in video at http://aka.ms/12to16maydemos.

  • Anonymous
    March 27, 2015
    The comment has been removed

  • Anonymous
    June 02, 2015
    all these stories behind what was a cloud service before and "HOW IT WORKS" now is of little use. I say it so that you and other people in Microsoft understand the very simple things that likes of Amazon get it right from the first shot. As a enterprise user who is testing migration from On-Prem and Amazon AWS to Azure, I need to know the following: Why, when and How should I be using cloud services from an architectural point of view. I have read million posts and watched gazillion videos and I can create cloud services with my eyes closed! but how do they fit in the bigger picture of infrastructure architecture and how do they tie in with Virtual networks (again from architectural point of view) to provide SECURITY and flexibility. I wish you people go to Amazon's documentation and see the ease with which customers can get information. We can only wish ...............

  • Anonymous
    June 24, 2015
    Will loadbalancer be automatically created for every cloud service that is created as part of VM creation or we have configure loadbalancer explicitly?

  • Anonymous
    June 24, 2015
    Hi Preeti, Every Cloud Service, no matter what type, always has a load-balancer included. With the type of Cloud Service that includes Azure VMs, you have to explicity go in and connect the VMs to the load balancer. You do this my managing endpoints. So you might connect port 80 of a VM to the load balancer and expose it to the outside world on port 80. So you don't really configure the load balancer, you just configure the connections between your VM and the load balancer....

  • Anonymous
    August 19, 2015
    Can you have one VM in multiple cloud services? Or better, what if I have a pool of 8 vm's they all respond to port 80, but 4 will also respond to 443. Is the only way to do this by separating into different cloud services? Which goes back to the first question, if the only way to do this is separate cloud services, then I could have a port 80 cloud service and a port 443 cloud service, with the 4 port 443 servers also living in the port 80 cloud service. It came up in a discussion with a friend of mine, and I wasn't sure it was possible, and it may not be, or it's entirely possible that I just really don't know how to make the LB do what I want it to.

  • Anonymous
    August 24, 2015
    This is an excellent article.  I appreciate the historical view as well as how MS was able to leverage that for evolving needs.  This article cleared up the majority of my confusion.  

  • Anonymous
    September 09, 2015
    The comment has been removed

  • Anonymous
    September 21, 2015
    Hi Planky, thanks for the great post. Question on Web/Worker Role pricing: You have mentioned when you have VMs in Cloud Service you pay for each machine and Cloud Service itself is free. But what happens in case of Web/Worker roles? Do I pay per instance of my Web/Worker role same price as per VM? I cannot find pricing calculator for Web/Worker roles. Thanks!

  • Anonymous
    October 23, 2015
    we can use single cloud service for multiple VMs. what is the best practice?. creating single cloud service for all VMs or having new cloud service for each VM?

  • Anonymous
    November 09, 2015
    The comment has been removed

  • Anonymous
    December 19, 2015
    Thank you Planky for straightening this matter out! Any chance you could create another youtube demo in regards of "Mike Courtney 20 Nov 2014 2:25 AM" post/question. And maybe include his other comments from "Mike Courtney 20 Nov 2014 3:51 AM" .  Thank you again!!!

  • Anonymous
    January 19, 2016
    Cloud Services are PaaS and VMs are IaaS - simply put.

  • Anonymous
    February 09, 2016
    Hi, will i pay the same thing if i create one Cloud Services by VM or less Cloud Services for same number of VM ? Just for know if i can isolate the VM in a dedicated Cloud Services without pay more. Thank you !