You’ve probably been virtualizing things on-premise for a while now and it’s pretty straightforward.  You spin up a VM, connect it to a network much like a physical machine, configure it as you need it and go on your way.  Depending on it’s role you might configure  your perimeter firewall so that it has some ports open on an Internet routable IP address.

And that pretty much sums it up. In Azure, a lot of that is same.  Except for the whole “Cloud Service” thing. A Cloud Service is a key part of the Azure fabric and if you’ve been working with PaaS for a while, it’s likely very familiar.  But if you are coming from the data center, it’s a new idea. Or at least, it was for me.

If you’ve taken one of the free Azure IT Camps or gotten a similar presentation on Azure IaaS you’ve likely seen this graphic:

What this shows is that a cloud service is a container that holds your VM.  This container is the “steward” of several key components that make your server room in the cloud work. A cloud service holds an external IP address and unique DNS name, is tied to a physical location in the Azure global fabric and acts as a firewall boundary.

You can create a cloud service first and add a VM to it, or you can create a VM and a matching cloud service will be made for it.  I prefer making the cloud service first (and I’ll explain why) but first, let’s break those things down:

• Physical Location – When you create a cloud service, it’s tied to one of Microsoft’s eight worldwide data centers.  They are grouped in pairs (US – West Coast, US – East Coast, Europe and Asia).  At minimum, you must select the region your cloud service lives in.
• DNS Name – Each cloud service has an external DNS name in the cloudapp.net name space. By default, creating a VM will automatically create a cloud service with a matching external DNS name, if the DNS name is available.  (If not, you’ll be prompted to name it differently.) The DNS name does not have to be the same as the server name.

Up to 50 VMs can live inside a single cloud service, so if you are using a cloud service to host some servers for a website, you might want your external DNS name to be something meaningful for the service those servers provide.

For example, only one cloud service is needed for “mywebsite.cloudapp.net”, but inside it contains four servers that are all available to service requests to the same site.

• External IP Address – Once your cloud service is populated with at least one running VM, it will be assigned an external IP address.  This address has a lifetime lease, however I recommend using the DNS name as the best way to reference the service from other systems.
• Firewall Boundary – The cloud service is used as the boundary where all the input endpoints are opened so you can access the VMs within it using the protocols of your choosing.  By default, RDP and Powershell is open for Windows operating systems, but this is all configurable by either using the Azure portal or via Powershell. Depending on what service you’ll be providing, you’ll need to open other ports.

Now, why do I like making an empty cloud service first?

Because it allows me to create the *.cloudapp.net DNS name separate from the machine creation process and think about how I want my VMs and applications to be grouped and accessible BEFORE I get started spinning up machines. Whenever I’m creating a cloud service in conjunction with VM creation, I nearly always end up with a DNS name I don’t like. 

Creating VMs in Azure is an almost trivial task, but the placement of them isn’t, so taking the time to understand cloud services, endpoints and other factors before getting down the business of creating VMs is something I consider a personal best practice. 

Azure doesn’t allow for name and location changes once a cloud service or VM is created, so correcting that requires deleted your work and starting over.  I’m crossing my fingers that some basic edits are built into Azure in the future, but for the moment, I like to “plan twice, create once!”

Once upon a time, a very short time ago, I had a data center of my very own. If you’ve read this blog often enough, you know that before I joined Microsoft I was part of a NetOps team that had it’s own little server room.  We had some applications and servers that were still stand-alone on physical hardware, lots more servers virtualized on VMware.  Cables and VLANs and a phone system… all the usual stuff.

Also once up a time, several years before, Microsoft started talking about Azure.  And I looked at it with curiosity and saw that it was all platform-as-a-service geared toward mostly Developers.
And then my brain tuned out.

Click! Back to the things that mattered to my data center.

And then, not so long ago, Microsoft started talking about IaaS in Azure. It started to seem more relevant to me, so I started to look closer. And now I’m working for Microsoft and I’ve been learning a lot more about Azure IaaS. And I realize that if I was still sitting outside my server room door, Azure would probably be one of the things topping my list of projects.  It’s THAT relevant.

But coming from a “classic” data center mindset, there are bits of Azure that take a moment to get your head around.  A little shift of thinking.  Because there are some things I was really comfortable with in my data center that Azure just doesn’t do the same way.

Check back tomorrow when I touch on Cloud Services, the first thing in my list of high level Azure concepts that I’m learning to love.