Microsoft Azure Reviews

Back in January Scott Gu announced the official release of Windows Azure Media Services. It is amazing platform that was out in the wild (as a CTP, or Community Technology Preview) for less then an year. Before it was RTW, I created a small project to demo out its functionality. The source code is public on GitHub and the live site is public on Azure Web Sites. I actually linked my GitHub repo with the Website on Azure so that every time I push to the Master branch, I got a new deployment on the WebSite. Pretty neat!

At its current state Windows Azure Media Services  does support the VOD (or Video On Demand) scenario only. Meaning that you can upload your content (also known as ingest), convert it into various formats, and deliver to audience on demand. What you cannot currently do is publish Live Streaming – i.e. from your Web Cam, or from your Studio.

This blog post will provide no direct code samples. Rather then code samples, my aim is to outline the valid workflows for achieving different goals. For code samples you can take a look at the official getting started guide, my code with web project, or the MediaServicesCommandLineTools project on GitHub, which I also contribute to.

With the current proposition from Azure Media Services you can encode your media assets into ISO-MP4 / H.264 (AVC) video with AAC-LC Audio, Smooth Streaming format to deliver greatest experience to your users, or even to Apple HTTP Live Streaming format (or just HLS). Everything from the comfort of your chair at home or in the office. Without the big overspend in expensive hardware. Getting the results however may be tricky sometime, and the platform does not help you with very detailed error messages (which I hope will change in the very near future).

You can achieve different tasks (goals) in different ways sometime. Windows Azure Media Services currently works with 4 Media Processors:

• Windows Azure Media Encryptor
• Windows Azure Media Encoder
• Windows Azure Media Packager
• Storage Decryption

When you want to complete some task you always provide a task preset and a media processor which will complete the given task. It is really important to pay attention to this detail, because giving a task preset to the wrong processor will end up in error and task failure.

So, how to get (create/encode to) a Smooth Streaming Content?

Given we have an MP4 video source - H.264 (AVC) Video Codec + AAC-LC Audio Codec. The best will be if we have multiple MP4 files representing same content but with different bitrates. Now we can use the Windows Azure Media Packager and the MP4 To Smooth Streams task preset.

If we don’t have MP4 source, but we have any other supported import format (unfortunately MOV is not a supported format), we can use Windows Azure Media Encoder to transcode our media into either an MP4 (H.264) single file, or directly into Smooth Streaming Source. Here is a full list of a short-named task presets that can be used with Windows Azure Media Encoder. To directly create a Smooth Streaming asset, we can use any of the VC1 Smooth Streaming XXX task presets, or any of the H264 Smooth Streaming XXX task presets. That will generate a Smooth Streaming asset encoded with either VC-1 Video profile, or H.264(AVC) Video Codec.

OK, how about Apple HTTP Live Streaming (or HLS)?

Well, Apple HLS is similar to Smooth Streaming. However, there is a small detail, it only supports H.264 Video codec! The most standard way of creating Apple HLS asset is by using Windows Azure Media Packager and the XML task preset for “Convert Smooth Streams to Apple HTTP Live Streams”. Please take a note on the media processor – it is the Windows Azure Media Packager. This also will accept an input asset to be valid Smooth Streaming Asset encoded with H.264 (AVC) video codec! Do not forget that you could have created Smooth Streams with VC-1 Video Profile codec, which are totally valid and running Smooth Streams, but they will fail to convert to Apple HTTP Live Streams.

Hm, can’t we get all-in-one?

I mean, can’t I have a single media asset and deliver either Apple HTTP Live Streams or Smooth Streams, depending on my client? Sure we can. However this is CPU intensive process. It is called “dynamic packaging”. The source must be a multi-bitrate MP4 asset. This one consists of multiple MP4 files of same content with different bitrates. And it requires an on-demand streaming reserved units from Media Services. You can read more about dynamic packaging here.

I was recently involved into interesting project, that was using the plain old ASMX web services. We wanted to migrate it to the Windows Azure Access Control Service and make use of Claims.

The way we achieved that is to add additional Soap Header to the client requests that includes Simple Web Token (SWT). On the server side, we make a check for this specific header existence, then extract the token, perform some validation checks and inject a fresh new Claims Identity into the Service instance. One thing to look out for is that you have to think of a workaround, if your ASMX WebService is a Singleton object. My implementation works with non-singleton implementations. And I currently get my Simple Web Tokens from Windows Azure Access Control Service’s WRAP endpoint. I have configured a “Password” service identities and I play with the RuleGroups to add additional claims, based on identity used. It is pretty flexible!

The result is on … GitHub. I initially wanted to be on CodePlex, because I have other projects there and am more used to TFS style of working. But CodePlex’s TFS is down for quite some time, which was a good excuse to use GitHub. There is some explanations in the Readme.txt file, as well as comments in the code. So feel free to get the code, play around with it, ping me if it is not working for some reason, and so on!

The project makes extensive use of SWT Implementation, done by the Two10Degrees’ team. But I added a compiled assembly reference for convenience.

In my previous post on Windows Azure Basics, I tried to introduce you the cloud computing concept and explain the Windows Azure Platform with not so technical terms. It is time now to get over the networking. What is happening behind the scenes? What we can or cannot (currently) use?
Lets first take a look at the following picture, which tries to show almost complete Windows Azure hosted service:

Here are the terms/abbreviations you see on the illustration:

• LB – Load Balancer. It is the Windows Azure software Load Balancer, which routes the Internet traffic to and from your hosted service;
• VIP – virtual IP address. This is the internet facing public IPv4 (currently) network address for your hosted service. You have to pay attention to it, as you only have one single internet facing IP address per hosted service;
• DIP – direct IP address. This is an internal subnet IPv4 network address that each single instance of your roles has. You have one of these DIPs for every single instance, and there is only one per instance. This IP address in internal subnet and cannot be used to directly access a specific instance from outside the Windows Azure hosted service. You can, however use this address for internal communication between instances of your roles within the whole Windows Azure deployment (hosted service)t;

Any Windows Azure Hosted service is considered a closed environment, meaning that no Internet traffic is routed to your service, unless you explicitly say so (we will later understand how)! And not only that, but any single instance is considered a closed environment. That means two things:

1. The LB (Load Balancer) will not route any Internet traffic to the instances of your roles;
2. The Windows Firewall of all your instances is set to default block everything (Effectively blocking even communication between different instances in a single deployment);

Of course the hosted service can access the Internet.
Couple of words on protocols. Currently the Windows Azure hosted service only supports the TCP/IP stack of protocols. Meaning that you can only have TCP traffic to/from/within your instances. UDP is not currently supported (thus excluding  IPSec also). What about web roles? Well, web roles are using HTTP protocol, which essentially lives over TCP. HTPS is also supported, because it also relies on TCP/IP. I very often see questions on whether sending/receiving mails is supported in Windows Azure, and the answer is yes. Before all, SMTP, POP(3), IMAP protocol families are all stacked over TCP. So we can have everything within the TCP stack, and (yet) nothing on the UDP stack (no SMB, no IPSec, no RTMP, etc).
Now, how can we route the Internet traffic to our instances in Windows Azure. The platform introduces an entity called Endpoint.
Endpoint is a combination of protocol type + port number, which effectively expose your instance to the internet at the given port number. What about protocol types? Well, currently you can only choose from “tcp” and “http/https”. There are two kind of endpoints: Input Endpoint and Internal Endpoint.  While the Input Endpoint will expose your instance to the Internet, by routing all Internet traffic on selected port to your instance, the Internal Endpoint will only open communication between instances in a single deployment.

Side note: you maybe already noticed that I am using “instances” more often then “roles”. I hope that you’ve read my first post and already know the difference. The key difference is that the instance is the actual VM (Virtual Machine) where your code lives, while the Role only defines the “footprint” for what to be instantiated on the Virtual Machine.

The catch. There is always a catch, and the current one is on the constraints put on the Endpoints:

• You can have a maximum of 25 Endpoints per hosted service (Input + Internal);
• You define your endpoints by a Role! Meaning that two different roles cannot share a single Endpoint;
• All your Endpoints within a Hosted Service must be unique. Meaning that you cannot have an Input Endpoint (i.e. “EndpointWeb") serving HTTP protocol on port 80 for one Role and have another Input Endpoint (i.e. EndpointWebMVC) serving again HTTP protocol on port 80 for another Role. Here I stress that we define Endpoints at Role level, so every instance of this role will have the endpoints defined;

Behind the scenes: When you add a Web Role in your cloud project, the Visual Studio Tools for Windows Azure automatically create an HTTP endpoint on port 80 for your WebRole. It is named “Endpoint1” (but this might change in the future). Having in mind last of the constraints, if you add a second WebRole to your cloud project, a new Endpoint (Endpoint2) will be automatically created with protocol HTTP and port 8080! So be aware of that fact and do not let it surprise you
Something more on Windows Azure networking – the LB (Load Balancers) do not use sticky sessions. That means that every single request is routed on its own. So and end user can open a page on your website hitting Instance 0 of Web Role (check the illustration at the top), that page may create several AJAX requests and all AJAX request will go on their own route. Any of the requests may either hit Instance 0, but they may also Instance 1, and so on. That requires us to build a fully stateless applications. The application logic shall be fully operational and aware that some user’s requests may end up in one instance, other in other instances. So we have to always use a common storage (Azure Storage or SQL Azure or AppFabric Caching service) for all the data that needs to be persisted across user’s requests.
Remote Desktop? Yes, it is supported! Remote desktop operates on port 3389 over TCP protocol. Again the catch: Be aware that enabling a Remote Desktop for all your roles in your deployment (which just a checkbox), will automatically create an Input Endpoint for your service. This affects the total number of Endpoints per service (remember, it is 25)!.
What about sending mails, again? As I already wrote, the common mailing protocols are supported (SMTP, POP, IMAP), however Windows Azure does not provide a “Email-as-a-service” service. Luckily enough, a great collaboration was announced, and every Windows Azure subscription receives a complimentary free account on SendGrid with a limit of 10000 e-mails monthly (I think, this you can check ). So you can use the SendGrid service to send your application / service e-mails. You get it for free for the first 10k e-mails in the month. If your needs exceed this limit, you can upgrade your account for a very reasonable price!

We live in dynamic times. Buzzwords such as cloud computing, elastic scale, reliability and their synonyms are taking more and more space in our daily life. People (developers) want to move to the cloud. They are often confused by all the new terms. In this part 1 of [we-will-see-at-the-end-how-many] articles I will try to explain with non-geeky words the Windows Azure terms.

First of all, what is Cloud Computing before all? This is when Computing power (namely CPU, RAM, Storage, Networking) is delivered as a service via a network (usually internet), and not as a product (a server that we buy).

Cloud computing is a marketing term for technologies that provide computation, software, data access, and storage services that do not require end-user knowledge of the physical location and configuration of the system that delivers the services. A parallel to this concept can be drawn with the electricity grid, wherein end-users consume power without needing to understand the component devices or infrastructure required to provide the service.

So what is Windows Azure? Is it the new server operating system from Microsoft? Is it the new hosting solution? Is it the new workstation OS? Well, Windows Azure is the Microsoft’s Cloud Computing platform. It delivers various cloud services. Compute, Database, Storage, CDN, Caching, Access Control to name few.

Next part of the article will be focusing on Windows Azure Compute services.

Windows Azure Guest OS? When we talk about cloud computing, inevitably we talk about virtualization. Virtualization at very big degree. And when we talk about virtualization, we have a Host OS and Guest OS. When we talk about Windows Azure OS, we talk about Windows Azure Guest OS. This is the operating system that is installed on the Virtual Machines that run in the cloud. Windows Azure Guest OS has 2 families – OS Family 1 and OS Family 2. Windows Azure Guest OS Family 1 is based on Windows Server 2008 SP 1 x64, and Family 2 is based on Windows Server 2008 R2. All and any guest OS is 64 bits. You can get the full list of Windows Azure Guest OS here.

Windows Azure Cloud Service, or Hosted Service. The Hosted Service is the essence of your Cloud application:

A hosted service in Windows Azure consists of an application that is designed to run in the hosted service and XML configuration files that define how the hosted service should run

A hosted service can have one or more Roles.

Now it comes to the Roles. Our cloud application can be a Web Based application, or a background processing application, or some legacy application which is hard to migrate. Or mix of the three. In order to make things easy for developers, Microsoft has defined 3 distinguished types of “Roles” – Web Role, Worker Role and VM Role. You can read a bit more for the “Role”s here. But the main idea is that a Role defines an application living environment. The Role contains all the code that our application consists of. It defines the environment where our application will live – how many CPUs will be installed; the amount of RAM installed; volume of local storages; will it be a full IIS or a background worker; will it be Windows Azure Guest OS 1.x or 2.x; will it has open ports for communication with outer world (i.e. tcp port 80 for Web Role); will it has some internal TCP ports open for internal communication between roles; what certificates will the environment has; environment variables; etc.

The Role is like a template for our cloud application. When we configure our Cloud Service (or Azure Hosted Service), we set the number of instances involved for each Role.

Instance is a single Virtual Machine (VM), which has all the properties defined by the Role and has our application code deployed. When I mentioned that the Role defines the number of CPUs, RAM, local storage, I was referring the configuration for each VM where our code will be deployed. There are couple (5) of predefined VM configuration which we can use:

Virtual Machine Size	CPU Cores	Memory	Cost Per Hour
Extra Small	Shared	768 MB	$0.04
Small	1	1.75 GB	$0.12
Medium	2	3.5 GB	$0.24
Large	4	7 GB	$0.48
Extra Large	8	14 GB	$0.96

More information on Virtual Machine sizes can be found here.

And here comes the beauty of the Cloud. We code once. We set the overall parameters once. And we deploy once! If it comes that we need more servers – we just set the number of instances for our role. We do it live. There is no downtime. Windows Azure automatically will launch as many VMs as we requested. Will configure them for our application and will deploy our code in each and every one of them and will finally join them to the cluster of our highly available and reliable cloud application. When we don’t need (let’s say) 10 servers anymore, then we can easily instruct Windows Azure that we only need 2 from now on and that’s it. The cloud will automatically shutdown 8 servers and remove them, so we won’t be paying any more extra money.

It is important to note, though, that the Role defines the size of the VM for all the Instances of it. We cannot have instances of same Role but different VM size. This is by design. If we defined our Role to use Extra Large VM, then all the instances we have will be running on that size of VM.

Key takeaways

I hope that this article helped you understand couple of basic terms about Windows Azure. You shall be able to confidently answer the following questions:

• What is Windows Azure ?
• What is Windows Azure Hosted Service (or just Hosted Service)?
• What is a Role?
• What is a Role Instance (or just Instance)?

Following the first two posts of the series “Windows Azure Basics” (general terms, networking) here comes another one. Interestingly enough, I find that a lot of people are confused what exactly is the compute emulator and what are these strange IP Addresses and port numbers that we see in the browser when launching a local deployment.

If you haven’t read the Windows Azure Basics – part 2 Networking, I strongly advise you to do so, as rest of current post assumes you are well familiar with real Azure deployment networking components.

A real world Windows Azure deployment has following important components:

• Public facing IP Address (VIP)
• Load Balancer (LB) with Round Robin routing algorithm
• Number of Virtual Machines (VM) representing each instance of each role, each with its own internal IP address (DIP – Direct IP Address)
• Open ports on the VIP
• Open ports on each VM

In order to provide developers with as close to real world as possible, a compute emulator needs to simulate all of these components. So let's take a look what happens when we launch locally a Cloud Service (a.k.a. Hosted Service).

VIP Address

The VIP address for our cloud service will be 127.0.0.1. That is the public IP Address (VIP) of the service, via which all requests to the service shall be routed.

Load Balancer

Next thing to simulate is the Azure Load Balancer. There is a small software emulated Load Balancer, part of the Compute Emulator. You will not see it, you are not able to configure it, but you must be aware of its presence.  It binds to the VIP (127.0.0.1). Now the trickiest thing is to find the appropriate ports to bind. You can configure different Endpoint for each of your roles. Only the Input Endpoints are exposed to the world, so only these will be bound to the local VIP (127.0.0.1). If you have a web role, the default web port is 80. However, very often this socket (127.0.0.1:80) is already occupied on a typical web development machine. So, the compute emulator tries to bind to the next available port, which is 81. In most of the cases port 81 will be free, so the "public" address for viewing/debugging will be https://127.0.0.1:81/. If port 81 is also occupied, compute emulator will try the next one – 82, and so on, until it successfully binds to the socket (127.0.0.1:XX). So when we launch a cloud service project with a web role we will very often see browser opening this wired address (https://127.0.0.1:81). The process is same for all Input Endpoints of the cloud service. Remember, the Input endpoints are unique per service, so an Input Endpoint cannot be shared by more than one Role within the same cloud service.

Now that we have the load balancer launched and bound to the correct sockets, let's see how the Compute Emulator emulated multiple instances of a Role.

Web Role

Web Roles are web applications that run within IIS. For the web roles, compute emulator uses IIS Express (and can be configured to use full IIS if it is installed on the developer machine).  Compute Emulator will create a dedicated virtual IP Address on the local machine for each instance of a role. These are the DIPs of the web role. A local DIP looks something like 127.255.0.0. Each local "instance" then gets the next IP address (i.e. 127.255.0.0, 127.255.0.1, 127.255.0.2 and so on). It is interesting that the IP Addresses begin at 0 (127.255.0.0). Then it will create a separate web site in IIS Express (local IIS) binding it to the created Virtual IP Address and port 82. The emulated load balancer will then use round robin to route all requests coming to 127.0.0.1:81 to these virtual IP Addresses.

Note: You will not see the DIP virtual address when you run ipconfig command.

Here is how does my IIS Express look like when I have my cloud service launched locally:

Worker role

This one is easier. The DIP Addressing is the same, however the compute emulator does not need IIS (neither IIS Express). It just launches the worker role code in separate processes, one for each instance of the worker role.

The emulator UI

When you launch a local deployment, Compute Emulator and Storage Emulator are launched. You can bring the Compute Emulator UI by right clicking on the small azure colored windows icon in the tray area:

For purpose of this post I've created a sample Cloud Service with a Web Role (2 instances) and a Worker Role (3 instances). Here is the Compute Emulator UI for my service. And if I click on "Service Details" I will see the "public" addresses for my service:

Known issues

One very common issue is the so-called port walking. As I already described, the compute emulator tries to bind to the requested port. If that port isn't available, it tries next one and so on. This behavior is known as "port walking". Under certain conditions we may see port walking even between consequent runs of same service – i.e. the first run compute emulator binds to 127.0.0.1:81, the next run it binds to 127.0.0.1:82. The reasons vary, but the obvious one is "port is busy by another process". Sometimes the Windows OS does not free up the port fast enough, so port 81 seems busy to the compute emulator. It then goes for the next port. So, don't be surprised, if you see different ports when debugging your cloud service. It is normal.

Another issue is that sometimes browser launches the DIP Address (https://127.255.0.X:82/) instead the VIP one (https://127.0.0.1:81/). I haven't been able to find a pattern for that behavior, but if you see a DIP when you debug your web roles, switch manually to the VIP. It is important to always use our service via the VIP address, because this way we also test out application cloud readiness (distributing calls amongst all instances, instead of just one). If the problem persists, try restarting Visual Studio, Compute Emulator or the computer itself. If issue still persists, open a question at StackOverflow or the MSDN Forum describing the exact configuration you have, ideally providing a Visual Studio solution that constantly reproduces the problem. I will also be interested to see the constant repeatable issue.

Tip for the post: If you want to change the development VIP address ranges (so that it does not use 127.0.0.1) you can check out the following file:

%ProgramFiles%\Microsoft SDKs\Windows Azure\Emulator\devfabric\DevFC.exe.config

DevFC stands for "Development Fabric Controller". But, please be careful with what you do with this file. Always make a backup of the original configuration before you change any setting!

Happy Azure coding!

Valuable Features:

Room for Improvement:

Valuable Features:

Room for Improvement:

Other Advice:

Valuable Features:

Room for Improvement:

Other Advice: