Archive for April, 2013

One of the major updates done on Windows Azure is the capability to build and deploy Virtual Machines on it, which gives Microsoft Cloud Computing solutions the true meaning of offering the Infrastructure as a Service. As you certainly know that the Cloud Computing is composed of main 3 layers, the Infrastructure as a Service, the Platform as a Service and the Software as a Service. Yes Windows Azure is Microsoft Solution for the Cloud Computing Platform but it also offers you the solution of Virtual Machine to get the ability to deploy your applications on the desired Operating system, this is the true meaning of the Infrastructure as a Service.

Once we started talking about the Infrastructure as a Service or Windows Azure Virtual machine, then the target segment is totally different, from developers to IT Pros.

Here are some blog post that I hope they will help you understand more about the Virtual Machine on Windows Azure. The Disks and Images, Virtual Machines Networks (coming soon) and Virtual Machine Scalability and Availability.

Integration with Windows Azure Cloud Services or previously known as the Compute PaaS (Compute Node)

Why Windows Azure Virtual machine and what are its advantages on the VMRole?

There are a lot of differences between both of them regarding the Storage for example, the Virtual Machine is based on persistent Storage. If the application goes down for any reason, the data will be available unlike the VMRole. In the Virtual Machines you will have the capability to add new VHD easily through the Cloud directly unlike the VM Role which will require to do these things offsite then deploy it to Windows Azure.

So IaaS or PaaS, I mean what you will choose if the Windows Azure Virtual Machine will give you all these things. You can find all these related issues in the following blog post.

Here is an example of how you can create a Virtual machine using an image already existing on the portal.

Explaining each type of the Cloud Services Roles separately. The Cloud Services has three types of roles the WebRole, WorkerRole and the VMRole.

As for each of the web role and worker role, each one of them require the developer to develop the application again from scratch. As for the pre-developed applications it requires a new type of roles the VMRole. This is simply a role where you can host the pre-developed application on it. Certainly you will also have to do the required configuration and the service definition to be able to host your application on the Cloud.

However, I wont need to continue a lot in the VM Role because simply it will retire and will no longer be available, you can migrate your existing VM Role to the Windows Azure Virtual Machine. Here is where you can find on migrating your existing VM Role to Windows Azure Virtual Machine.

Explaining each type of the Cloud Services Roles separately. The Cloud Services has three types of roles the WebRole, WorkerRole and the VMRole.

The WebRole is all what is related to your web application, no matter what programming language your application is developed with. You can start working with the webrole application from this blog post. Certainly you can make the required connection between your WebRole and WorkerRole using the Queue, WCF or even the Service Bus.

Each WebRole can be configured through the configuration and the service definition file. These 2 files configure and define the application and the virtual machine where this application will be host. For those who have worked before on Windows Azure Virtual machines, here is a simple example between why choosing Windows Azure Cloud Services, or the differences between the Windows Azure Virtual Machines and the Windows Azure Cloud Services.

Explaining each type of the Cloud Services Roles separately. The Cloud Services has three types of roles the WebRole, WorkerRole and the VMRole.

The WorkerRole you can consider it as a background services that runs on Windows Azure Data Centers, consuming its Servers processing power. Certainly the amount of the processing power is defined by the VM size in the Service Definition file. Let me try to approach the example: if you start your computer and you find it so slow, it is not necessary that your laptop has something wrong in it. it might means that you have a lot of background services that runs in the background without the need to have a user interface. If you are a developer you certainly knows that for example the SQL Server has some services that need to start on the start of the computer.

The same concept goes for the WorkerRoles, they run in the background they don’t have an interface and can run once triggered to forever. Certainly you can link them to your WebRole application.

So when to use the WorkerRole?

This is mainly designed for the applications that require a lot of processing power and you don’t want to make the application’s users feel that there are any delays or any processing power consumption from there side, or even a delay in a webpage loading. You can simply send the required task to the WorkerRole and when it finishes it, it will the result to the desired application.

If you develop a WebRole application with a WorkerRole, you don’t have to have similar number of instances for the worker and the web. The WorkerRole might process several WebRole requests. You might have several WorkerRoles to your WebRole, where each has a certain requests and process to do.

Now with the IaaS new meaning of the Windows Azure and the new updates always done on the Windows Azure Virtual Machines, there are certainly a lot of differences between hosting applications on Windows Azure Cloud Services and Windows Azure Virtual Machines. Please note that the Windows Azure Cloud Services are considered Platform as a Service and the Virtual Machines are considered Infrastructure as a Service.

My point of this blog post is the following, if I do have the capability to create a Virtual machine and host on it my application with no need of learning new things about Windows Azure neither the Cloud Services why am I in need of the Windows Azure Cloud Services.

Here is the answer simply, yes you can host on your Virtual Machine whatever applications you want and with the number you like, in other words in your Virtual Machine you can host on it the number, which gives you more control and probably it might be cheaper in some cases, BUT…

The Windows Azure Cloud Services can offer you a lot of features that the Virtual Machines can’t offer like different type of roles that are mainly designed for a certain purpose like the WorkerRole and its different types: the Cache Worker and the Worker Role with the Service Bus Queue. The Windows Azure Cloud Services helps the developers deploying the applications in a lot easier way, whether by packaging the application and then deploy it or by simply publishing it directly from the Visual Studio and maybe through the Service management API.

Also one of the main reasons to use the Windows Azure Cloud Services is that it is somehow cheaper that the Virtual Machine, remember it is all about how you develop your applications, it could save you a lot of money and it could cost you a lot.

Certainly the Cloud Services could help you a lot without the need to make the updates and upgrades manually, they are automatically done without the need of any interference.

I am not trying to convince you with the Windows Azure Cloud Services but I am trying to clarify the main differences between them. The Virtual Machine is awesome in its turn, it offers its users and specially the IT Pros a lot of capabilities like hosting CRM or SharePoint on it, and from there you can do a lot. It also can help those who don’t work with Microsoft Technology like those who use MySql you can easily build your applications on Windows Azure Virtual Machine.

Lately Windows Azure has seen a lot of updates, in my opinion some rearrangements and re-categorization of its features. Talking about any operating system, it should provide with 2 main things the Processing power and the storage. These are the main things Windows Azure or any Cloud Computing Platform offers. Certainly with the competition between the Cloud Providers, the services added to the Platform are so considerable and these are the main things that differs the cloud providers from each-others – certainly other than the costs. If you remember, the compute node, one of my pervious blog posts, it was all about the node that was charge of processing power of your application. I have also mentioned before several types of roles, the WebRole and the WorkerRole, maybe the VM Role.

However my point now is that all these kind of roles are now considered as Windows Azure Cloud Services. Each roles run separately on different Virtual Machine where you can make its Configuration and Service Definition and control the number of instances, directly from the xml files or from the portal itself – New Addition.

What exactly a role mean? If you understand the concept of the OOP, I think you will get what I mean, if you create a class with a certain attributes and functions. You can create from it a number of objects, maybe they can be different from each other’s, but always have the same characteristics as they share the same functionalities. The same concept goes for the role, this where you can develop your application with any programming language. After that you can create the number of instances you want and maybe make some intercommunication between them – Certainly this will depend on your business, application and traffic needs. Remember that everything costs money on the Cloud, if you develop a well-structured application it could save you a lot of money otherwise it could cost you a lot.

Watch out that to develop on Windows Azure now you have to be working with .Net Framework 4.0 or above, because simply after the release of Windows Server 2012 and the upgrades done on the Virtual Machines of the Windows Azure Cloud Services, it will not allow lower that .Net Framework 4.0 to run on it.

After the last two blogs, the Service Bus Brokered Messaging API Details and the Service Bus Relayed Messaging API Details, here are the main differences between them, how and when to use anyone of them.

The relayed Messaging Service was launched with the launch of the Windows Azure Service Bus. As the main target of the Service Bus is to connect multiple applications over the internet for better enhancement for the enterprise application integration no matter where the applications are hosted whether on the Cloud or a private one. The Service Bus Relayed Messaging has mainly accomplished the target of connecting these applications without any changes required to be done on the firewall neither on the network infrastructure of the application.

The relayed messaging enables you to do service remoting by exposing securely exposing a service hosted on a private cloud to its consumers without the need to open a specific port on the firewall. The relayed service supports only one-way messaging, request/response messaging or peer to peer messaging.

The disadvantage of the Relayed service, is that the client and the message sender have to be online in the same time the message is sent otherwise, the service will fail.

The other one, the Brokered Messaging, is a decoupling or asynchronous way of messaging over the cloud. The senders and receivers of the Windows Azure Service Bus Brokered Messaging doesn’t have to be online in the same time, the message can be sent and when the receiver is online he will be able to receive the message.

The relayed messaging is used to connect multiple applications whether they are running on the same infrastructure on whether each one of them is hosted on different host, all what you need is a web service with no need to make changes in your firewall. The Brokered Messaging is an asynchronous messaging service that give the sender and the receiver to send messages and they don’t have to be online on the same time.

For more information here are the question I have previously asked related to this topic on stackoverflow.

Here is one of awesome resources, Best Practices for Leveraging Windows Azure Service Bus Brokered Messaging API, it introduce both the windows azure relayed and brokered messaging. After that it continue the explanation with the Windows Azure Brokered Messaging.