Windows Azure Tools for Microsoft Visual Studio extend Visual Studio 2008 and Visual Studio 2010 Beta 1 to enable the creation, building, debugging, running and packaging of scalable web applications and services on Windows Azure.

The most interesting feature is probably the support for multiple roles. Now one can deploy many web/worker roles.

What’s new in the Windows Azure SDK?

• The Windows Azure SDK supports developing and deploying services containing multiple web and worker roles. A service must include at least one role, of either type, and may include zero or more web roles, and zero or more worker roles.
• The new PowershellRole sample hosts the Powershell runtime within a Windows Azure role. It demonstrates a simple remote console web role as well as a worker role whose implementation is a Powershell script. The host also includes the CloudDrive sample snap-in to provide access to Windows Azure Storage from script.

What’s new in Windows Azure Tools for Visual Studio

• New project creation dialog
• Support for developing and deploying services containing multiple web and worker roles. A service may contain zero or more web roles and zero or more worker roles with a minimum of one role of either type.
• Ability to associate any ASP.NET Web Application project in a Cloud Service solution as a Web Role
• Support for building Cloud Services from TFS Build
• Enhanced robustness and stability

The new CTP Release can be downloaded from this link.

I already explained what Azure is a previous post, Windows Azure Application Architecture, but I find this video funny and interesting.

PS: Sorry but this post is not XHTML valid :( I haven’t managed to embed the object in a proper way. Does anyone have a suggestion of how to correct this?

Windows Azure compute hours are charged only for when your application is deployed so while developing and testing your application you may want to remove the compute instances that are not being used to minimize compute hour billing. Windows Azure storage is metered in units of average daily amount of data stored (in GB) over a monthly period. Storage is also metered in terms of storage transactions used to add, update, read and delete storage data. These are billed at a rate of $0.01 for 10,000 (10k) transaction requests. Bandwidth is charged based on the total amount of data going in and out of the Windows Azure platform services via the internet in a given 30-day period.

Microsoft Partners receive an additional 5 percent promotional discount on Windows Azure compute, SQL Azure and .NET Services.

A more detailed description on the pricing model is available on the Windows Azure Blog.

< Part 1 (Intro)

Contents:

1. A little more Live Mesh (CTP)
2. The Actors
3. The Modern Approach

1. A little more Live Mesh (CTP)

Today, online and offline tend to be two different approaches for building software. Most software companies offer either online or offline versions of their software.

If they somehow offer both then mostly sure one is a limited (reduced functionality) version of the other. Moreover companies tend to create a gap between the time when the offline and the online version gets updated. You always hear thing like “the online version does not yet support feature X that is available in the desktop version. Will be available soon”. The bad thing is the soon might mean a couple of months.

Creating software that works the same way both online and offline is not a new idea but until not it would require a lot of overhead. There was the need to simulate either the offline environment online or the reverse.

Now, with Live Mesh, the online environment is simulated on the local machine with no overhead for the developer. The guys from Microsoft resolved this problem and they’ve simplified our lives.

There are some aspects that need to be clarified as pointed in Part 1 about online services and applications:

• The user experience: this problems was somehow resolved by enabling applications to be based on Silverlight. This technology enables web applications to deliver an improved experience compared to the classical web apps. It is client-side technology.
• The need of permanent connectivity: just like smart clients, Mesh Enabled Applications can run with no network connectivity, persist offline what needs to be processed online and continue the process when connectivity is available. In other words what can be done offline is done anytime and if Internet access is required the task is queued.

2. The Actors

Lets consider a company named InvoiceGuys which offers a service called InvoiceService that exposes functionality for processing invoices. Anyone can subscribe the this service – for the sake of simplicity we’ll just ignore authorization and authentication; just don’t do this in real life!

DeliveryGuys is a another company that delivers packages of any kind. They have all they need except an invoice processor. Also they have a lot of delivery boys that have laptops but the Internet connection is not the best possible – sometimes is just doesn’t work. Moreover DeliveryGuys’ employees are not technical and they know to use only a limited set of applications.

DelivertyGuys have the following requirements:

1. the invoice processing must be automated
2. because of the their non technical employees they want a unified experience for all their software
3. there will be software that runs on the delivery laptops but also on the company’s sales desktops that are always connected to the Internet.
4. each workstation (mobile or not) must run the latest version of the delivery software and the update process must be transparent to the user
5. all data must be synchronized between company’s workstations
6. managers must be able to access the application from any PC regardless of their local rights

3. The Modern Approach

Each of the previous requirements is analyzed:

1. “the invoice processing must be automated”

This is the easiest part. As mentioned above, InvoiceGuys offer the InvoiceService service so all we need to do is consume their it and, of course, pay whatever they require for using it. So our application will rely on a 3^rd party service that might be offline sometime – remember this!

2. “because of the their non technical employees they want a unified experience for all their software”

3. “there will be software that runs on the delivery laptops but also on the company’s sales desktops that are always connected to the Internet”

and

6. “the managers must be able to access the application from any PC regardless of their local rights”

Mesh CTP allows applications to work both online and offline. Moreover the same experience is offered both online and offline. Even from a public computer you can sign in and use the application.

4. “each workstation (mobile or not) must run the latest version of the delivery software and the update process must be transparent”

When connecting to the Internet, Mesh CTP synchronizes your local application with the latest available offline with no user interaction. While using the online version from a web browser you always have the latest version so there is no need to worry.

5. all data must be synchronized between company’s workstations

This is what Mesh actually does – it synchronizes data across machines. This will not be a problem.

In conclusion, Mesh CTP is a good choice for the client application.

A possible representation of the scenario using a use case diagram is provided left.

If Internet connection is available the user can use the local application of its web version. Both look and work the same and if the application is locally installed the choice is just a matter of preference. Also the application will use the online data and will synchronize immediately.

If no Internet connection is available then the application will connect to the local Mesh that has a cached version of the online data, will work as much as possible with it and will synchronize with the live environment when possible.

Basically the local data is just an extension of the live data.

The modern approach is that we can have applications that rely on services which might not be available all the time and also can run both offline and online – the application itself can be a software offered as a service.

Part 3 will present the actual implementation of the client application and a skeleton for the service.

Special thanks to Timotei Dolean and Andrei Ignat for reviewing this post.

Part 2 (The Idea) >

Contents:

1. What is Software + Services
2. Azure Services Platform
3. Live Mesh

1. What is Software + Services

Over the past decade, the world we live in has been transformed by the Web. More and more people gain Internet access, services become more accessible  and the experience is improving. There are a lot of advantages of using Internet services:

• Low hardware requirements: services use the resources provided by the vendor and not the local ones. We only need devices capable of displaying the information that the service is sending. Most of the time no processing is done locally.
• Device independence: a service can be accessed from any device connected the Internet. It does not require special privileges on the local machine and no installation is required.
• No maintenance: services are maintained and updated by the service provider, the client must do nothing to configure it. The service is an out of the box solution.
• Flexibility: we can change the service provider whenever we want. This capability creates new opportunities for businesses that can dynamically swap services and choose the one that matches their needs.

However there are still some limitations for which running local software is preferred instead of a web application/service:

• User experience: browsers are not yet capable of delivering the same user experience as a local running application.
• Privacy: there are situations when a company chooses the keep all its data within its controlled/trusted borders. There are many privacy concerns when using 3^rd party services because there is no control over the security and must rely on the provider’s security. Some complex federation problems might occur.
• Offline experience: even though the Internet is now available most of the time there are still situation when network access is not available (maybe some technical problems) and the service  cannot be accessed.

What do we do when we want to power of local running applications and the flexibility and ease-of-use of the Internet services? Simple: we take the best part of each, create an architecture that combines them and use it for application that work both online and offline. Ray Ozzie (Microsoft Chief Software Architect) mentioned that “when you combine the ever-growing power of devices and the increasing ubiquity of the Web, you come up with a sum that is greater than its parts. … Software-plus-Services is the next logical step in the evolution of computing.  It represents an industry shift toward a design approach that is neither exclusively software-centric nor browser-centric” ^[1].

Software plus Services describes the idea of combining hosted services with capabilities that are best achieved with locally running software. It describes composite applications created by combining traditional software with remote services to provide consistent and seamlessly integrated user experience across devices and form factors. Software plus Services is a concept that Software as a Service (SaaS) complements the traditional packaged software running on both client or server by services adding value^[2].

To get a better image of what Software + Services mean that a look at the video below created by CommonCraft. The video presents a generic situation about two people, one using services and the other an on premise solution, each needing a part of what the other has. The result is a combination of Software + Services:

2. Azure Services Platform

Azure Services Platform is Microsoft’s cloud computing platform that provides a wide range of internet services that can be consumed from both on-premises environments or the Internet.

It allows the development of scalable services that can be hosted in Microsoft’s data centers. The Azure Services Platform is a service, per se, that allows clients to buy and use compute and storage resources in order to provide other services. In other words is a service for services.

Services created on the Azure platform can be exposed through web interfaces and web services. If the functionality is exposed through a web service then it can be consumed by any client and can be easily integrated in some enterprise solutions. Hosting services in the cloud has many advantages like the elasticity of resources and costs, no worries about maintenance and insurance that no data is lost because of hardware problems.

The cloud platforms have some limitations but if they can be overcome this approach of building and hosting services can be a real benefit  for businesses both in terms of expenses and availability.

For more information about the Azure Service Platform see my other posts about it:

• Microsoft Patent no. 20080319910
• Windows Azure Application Architecture
• GeekMeet Brasov #1 – Cloud Computing

3. Live Mesh

Live Mesh is a data synchronization service from Microsoft. It allows users to sync files and folders across devices and the Live Desktop. The information about devices and folders participating in a synchronization relationship is not stored locally but at the service-end. Live Mesh is an application that runs on the Azure platform and is a good example of Software plus Services.

There is the “live” part that runs in the cloud and offers a Live Desktop that displays the files/folders synchronized and the devices that take part in the synchronization. The client application is installed locally (on Windows, Windows Mobile or MacOS) and takes care of the local files, determines when files and/or devices changed and require a new sync.

At the time of writing there are two versions of Mesh (Mesh.com and Mesh-CTP.com) that will eventually be merged. Mesh.com is the version of Mesh that is available to everyone and allows sync of files across devices.

Apparently no difference between Mesh and MeshCTP (note the Apps button in the right image)

Mesh-CTP is the version for developers that is available only by invitation (you can apply for the CTP program in order to get one). The main difference between the two versions if that the CTP allows the development of applications for the Live Desktop.

As I told before Mesh allows files and folders to be synchronized across devices and Live Desktop. Mesh-CTP brings in a new concept: application synchronization. The applications created for Mesh will be synchronized across devices and will work offline (!) by connecting to a local version of Mesh. Once online the files that have changed on the local device or any other will sync again. To be more precise, when not connected to the Internet the application provides only the functionality that not requires Internet access.

The idea above is not new (see Outlook, IE, FeedDaemon etc. that have an offline mode) but the revolutionary thing is that the same (!) application can work both online and offline and can be deployed on the local computer or on the Live Desktop. Also the latest version of the application is always installed because once a new version is available it is synchronized with all devices.

The next two parts of this article will present a modern approach for constructing software (that works both online and offline) and services using the Live Mesh (CTP) and respectively Azure Services Platform.

Part 2 (The Idea) >

References:

^[1] http://www.microsoft.com/softwareplusservices/software-plus-services-full-story.aspx

^[2]http://en.wikipedia.org/wiki/Software_plus_services

Special thanks to Timotei Dolean, Ursul and Andrei Ignat for reviewing this post.

For those who don’t know, Windows Azure is the Microsoft’s cloud operating system. It is an operating system that runs in the cloud and only in MS’ data centers so don’t bother asking how can you install this new OS because there is no way you can do it. If you want more details about cloud computing and Windows Azure join my live presentation on GeekMeet Brasov on March 28 (it’s a presentation in Romanian).

Let’s see what new goodies are in the March release:

First of all there is support for FastCGI which allows developers to deploy and run web applications written with 3^rd party programming languages such as PHP.  This provides developers using non-Microsoft languages the ability to take advantage of scalability on Windows Azure. Also the IIS URL Rewrite Module has been enabled.  URL rewriting, a feature often used by FastCGI developers, enables the creation of URLs that are easier for users to remember and easier for search engines to find. The Visual Studio Tools for Windows Azure includes a FastCGI Web Role that creates a Web Application project tailored to make it easier to configure, run and package a FastCGI application.

Geo-location provides developers with the ability to specify a location for their applications and data to build responsive services with lower network latency as well as the capability to meet location-based regulatory and legal requirements. Until now there were Azure data centers only in the north western United States but now you can also choose the data centers in south. Some officials from Microsoft said that “Going forward, we plan on expanding our presence to more locations, especially outside the U.S”.

One of the great things about Windows Azure is that it handles the deployment, monitoring, and management of your service so that you have more time to focus on the business logic.  Until recently, realizing these benefits meant your code had to run under Windows Azure partial trust, a code access security (CAS) level which locks down certain .NET functionality. Windows Azure now offers the option of running the code in your Web and worker roles under full trust.  This unlocks a number of compelling scenarios such as:

• Invoking non-.NET Code: Many developers have existing investments in native code or may choose to use native code for some specialized tasks.  .NET full trust makes it possible to use native code via spawning processes or Platform Invoke (P/Invoke).
• Using .NET Libraries that Require Full Trust: Certain .NET libraries, including libraries in the .NET Services SDK, require full trust and can now be used in Windows Azure.
• Inter-process Communication via Named Pipes: If you application spawns processes, you can communicate among them via named pipes.

However you must be aware that the Full Trust is not really Full Trust :) There are some obvious limitations like writing to registry and writing to the file system. These limitation might not be that obvious when programming against the local development environment.

Least but not last, even though it was not officially announced, I think there are plenty of bug fixes and other nice things.

The SDK and Tools for Visual Studio can be downloaded from the following links:

Windows Azure Tools for Microsoft Visual Studio (March 2009 CTP) – now include the SDK
Windows Azure Software Development Kit (March 2009 CTP) – if you don’t need the Visual Studio Tools

1. Azure Services Traning Kit

The Azure Services Training Kit which includes a comprehensive set of technical content including hands-on labs, presentations, and demos that are designed to help you learn how to use the Azure Services Platform. The February release includes the following updates:

• 19 demo scripts that walkthrough several of the services
• 10 presentations covering the entire Azure Services Platform
• 3 additional hands-on labs for Live Services’

The technical content covers services including: Windows Azure, .NET Services, SQL Services, and Live Services.

It can be downloaded from here.

2. “How Do I?” videos for Azure Services Platform

For Windows Azure:

For .NET Services:

For Live Services:

A service hosted in the Windows Azure fabric implements one or more roles. A role is a scalable component built with managed code. A service may run multiple instances of a role. Within the Windows Azure fabric, running instances of a role are replicated across multiple physical machines to implement all or part of the functionality of a service. Each role runs in a virtual machine that has following predictable resources allocation: 64bit Windows Server 2008 OS, 1.5-1.7 64 bit CPU, 1.7 GB RAM memory, 100 MB/s network and 250 GB storage space (only 50 available in the CTP). So basically the developer creates the application as being used by one user and, in the cloud, many instances of it are created to support multiple clients.

The Windows Azure fabric currently supports two types of roles:

• Web Role is an application accessible through HTTP and/or HTTPS endpoints. A web role is hosted in an environment designed to support a subset of ASP.NET and Windows Communication Foundation technologies.
• A Worker Role is a background processing application. A worker role may communicate with storage services and with other Internet-based services. It does not expose any external endpoints. A worker role can read requests from a queue defined in the Queue storage service.

Because workers do not have some public endpoints some architectural considerations must be taken. How can a worker process external data? How web roles and workers exchange information? Why do we need workers?

Web roles can send/receive data to/from workers using the Storage Services. Storage Services include Blob, Queues and Tables.

• Blobs are sets of binary data; they are similar with files from your local windows storage. Blobs are organized in catalogs that are similar to folders.
• Queues are just message queues. They are FIFO (First In First Out) data structures that can hold messages up to 8kb each.
• Tables provide structured storage in the form of tables. However this is not a relational database system! They are just some tables that hold data with no relation between them.

Of course, web role or worker role can make any external HTTP/HTTPS request. Also blobs, queues and tables can be accessed from outside the cloud through HTTP(S) requests. I will focus today on the internal could application architecture and not on the outside requests.

While you service is running in the cloud you cannot know where a specific instance is located, instances do not communicate directly one with another and you don’t have references to them. Every instance is “blind”. It knows only about itself. Also HTTP requests cannot be directed to a specific instance – the fabric has a load balancer that redirects requests. The same thing applies to workers: jobs cannot be dispatched to a specific worker.

The best strategy in this distributed environment is similar to the thread pool pattern. Web roles get requests from users, put messages in a queue and, asynchronously, a worker will take one message and process it. Even though instances can be located anywhere on the Globe, a message from the queue will be taken by only one worker – pretty cool, huh?

If the information that needs to be send to the worker is larger than 8KB then part of it can be saved in blobs or tables. For example you could use the table to store information about the client (name, address, phone etc) who sent the request, save in the blob the documents he sent and put a message in a queue saying “There is a new request. It was stored, in a table, having ID number 1234 and its associated blobs are Document1, Document2 and Document3″. The worker who will pop the message must first get the information from table, documents from blob containers, process them and save the results.

Workers act like a team that has a number of tasks to complete. When someone from the team finishes a task it takes another one. If there are no more tasks it waits.

Because Azure pricing will be influenced by the number of instances it is said that this value will be able to be modified “on the fly”. Assuming that your business has 1 million requests in December and only 10.000 in January then you could use 1000 web role instances in Dec. and only 10 in Jan, dynamically scaling your investments. Making roles and instances independent and communicating between them using the Storage Services gives you the ability to scale up or down the application transparently.

Another thing that must be taken in consideration when building could services is their asynchronously nature. If no worker is available to process a job, the message might be placed in a queue and processed later (maybe after 5 seconds or 5 hours). So client interfaces must support later result retrieving and must inform the user that the response might be delayed.