The Which, the When, and the How of Windows Azure Services: Devices

Windows Azure is a platform with many different services that you, the developer can piece together to create your solutions. But when do you use which service and how? In this blog series, you’ll discover the answer to that by using different scenarios used by developers working with Windows Azure today.

I’ll never forget this one time (at band camp? LOL) I was doing a presentation and after a full 2 hours of going through the Windows Azure platform, a developer at the back of the room stood up and said to me “Jonathan, now that I understand what Windows Azure is, what do I use when?” I took a minute to reflect on the question – to understand exactly what he was asking me. I thought he was joking at first, but after thinking about it for a bit, the question made sense. It’s very easy to understand what each individual service does, but it is a bit harder to piece together how all the different services work together.

In the next few posts, I’ll go through some scenarios that I see often being used today and will endeavour to highlight how different services can be used to meet certain requirements.

Previous Post

• Websites

If you need a crash course or a refresher on the Windows Azure platform, check out my Azure Camp Online series or visit an Azure Camp in a city near you. 

This week, we’ll talk about devices. I would have said we’ll talk about mobile applications, but why stop there? Granted, common devices would be phones like Windows Phone, Android, and the iPhone; and tablets like the Android tablets and the iPads; but there are so many device applications that can leverage the power of the Cloud. Basically, anything that can send and receive data via the Internet can use Windows Azure, like Blu-ray players, gaming consoles, etc.

Attributes of Devices

Before going to into the which, the when, and the how of Windows Azure services for devices, let’s take a moment to understand some of the key attributes of a devices:

• Limited computing capabilities
  As powerful as devices are these days, at the end of the day, they are still limited in what they can do and how much computing load they can handle. More importantly, you have to respect the fact that your application is not the only application running on the device. The devices’ computing capabilities are shared amongst all of the running apps. You definitely don’t want your application to be the one that is found to hog all of the system resources. That just translates into bad experiences and further, lack of future business.
• Limited storage capacity
  Devices usually come with a fixed amount of storage capacity. For example, you buy a Samsung Focus, your device is limited to 20GB. You buy an iPad, you’re limited to the GBs of the version that you buy. Granted there can be expansion slots that give you the ability to add more storage capacity, still, you remain limited to the sum of the storage capacity of the device’s HD and the memory card in the slot. Similar to computing resources, you are also sharing the storage capacity with other applications. You definitely don’t want your application to be the one that is found hogging all of the storage – especially on devices like the phone and tablets where chances are the user has their music and video collection loaded as well. You’re not going to really ask your user to remove some of their music and videos just so that your app can work, will you? I didn’t think so.
• Can connect from anywhere
  Connecting from anywhere is arguably one of the most important attributes of device applications. Think about it this way – today you’re home and working with your device from somewhere in North America. Tomorrow you travel to Europe. Chances are you’re going to take your device with you. You get to your destination and turn on your device. You’re naturally going to expect that your applications work just as well as they did back home, regardless of the fact that you are geographically in a different region of the world.

There are definitely more, but we’ll focus on these for this discussion.

Mapping Attributes to Services

Now that we know the above, we can map these attributes to Windows Azure services:

• To address the limited computing capabilities (by increasing), you would outsource the required horse power to web services hosted on Windows Azure Compute instances. Think about it this way – your device is the UX, allowing it to be sexy and responsive and your Compute instances become the remaining tiers of your application. The user interacts with the UX and makes requests of the application. The device application then sends the request to your web services. Depending on how complicated processing of the request is, the request may be processed right on the web role that hosts the web service or perhaps the request would be delegated off to a worker role to process the request (this is usually done by using the Queue (Storage) Service). Once processing of the request is complete, the result is sent back to the device app.

The above uses a web service as a proxy into your Windows Azure environment, but technically, you could remove the web service from the equation all together and communicate with roles in Windows Azure by reading and writing to a queue via the Queue (Storage) Service. Since the Queue service is a REST based web service in and of itself, you can have the device app read and write to it quite easily.

Whether to use a web proxy or work with the Queue service directly is an architectural decision that you’ll need to make based on the requirements of your application, specifically around security as the Queue service requires a security key which would have to be saved on the device.

When outsourcing computing resources to Windows Azure, there’s an additional attribute to add to the attribute list above – varying demand needs. Varying demand needs relate to scale. With device applications, scale refers to the backend services that support the application – i.e. the services that the application connects to and works with. Scale is achieved by using one or more Windows Azure Compute instances. The more compute instances you add, the more “horse power” the backend services will have and therefore the more they will be able to take on. This will increase the speed at which they respond to requests from the device application. Then when the demand is not there, you remove compute instances.

• Similarly, to increase the limited storage capacity on the device, you would outsource the hard drive space to Windows Azure Blob (Storage) Service. Blob Storage , delivered to you as a service (so you’re not worrying about its scalability, availability, or most importantly, its capacity), can take on all of your storage needs. Rather than storing the data that is required (or produced) by your application on the device itself, you’ll store the data in blobs on Windows Azure. Through the UX, you can make it look like the image, document, video, etc is located on the device. When the user requests it, the application will retrieve the data from blob storage and hand it to the user. When you need to save data, you save it to the blob. You’ve now enabled infinite data storage for your application on the device. At the same time, you’ve also enabled other devices to access the same data. Because the data is not physically stored on the one device, this becomes possible. You can now add additional user interfaces, such as a website or desktop client, and work with the same data. You’ve also now secured the data in multiple ways. Your data is now encrypted and stored in a secured facility. More importantly, with the data being off the device, in the event that the device is lost or stolen, your data will not be.

Note: You’ll need to decide whether your application will communicate with the Blob Service directly, via its REST-based web services or whether it will communicate with a web proxy that will communicate with the Blob Service. Using the Blob Service directly will require some additional security considerations.

• Can connect from anywhere, specifically referring to applications connecting to backend services from anywhere. There are two different services that fulfil the requirement of being able to connect from anywhere. The one thing that is common between both, however, is that the emphasis is put on not just being available from anywhere, but more importantly, available, responsive, and providing the best experience from anywhere. Traffic Manager takes care of intelligently routing requests from the device application to a data center that is closest to where the user is located based on rules that you can define. For example, if you have your backend services deployed to one of the Windows Azure North American data centers and to one of the European data centers and a user is using their device application in Asia, Traffic Manager can route the user to the European data center. The European data center is physically closer, thereby reducing the length of the trip, and getting the data back to the user as fast as possible. If you’re outsourcing your storage to Windows Azure as well, you’ll want to use the Content Delivery Network (CDN) to geographically distribute those storage objects (images, videos, documents, etc), placing copies in “edge nodes”, or cache nodes around the world, thereby making them physically closer to application requests. This reduces the distance the storage objects have to travel and therefore increases the responsiveness of your application (i.e. the application’s ability to return the data to the user).

Using the attributes of device applications as a guide, we’ve now been able to map Windows Azure services to meet the requirements of each.

Next Steps

If you’ve read the previous post in this series, you know what I’m going to say - as with everything in technology, there is always more than one way of achieving the same result, but one way will work better than another for the requirements of your particular application. The best way to figure out which one is best, is to try it out yourself.

If you’re thinking of developing applications for Windows Phone, iOS (iPhone/iPad), and/or Android (phone/table), you can download great toolkits that were specifically designed to make it easier for you to integrate Windows Azure into your device applications. The toolkits contain the native libraries for each of the platforms, samples that you can peruse and learn from, project templates, and of course, documentation.

Download:

• Windows Azure toolkit for Windows Phone
• Windows Azure toolkit for iOS
• Windows Azure toolkit for Android

Keep In Mind

Testing with the emulators that are included with the Windows Azure SDK (while it is definitely something you should do before deploying)will not give you as accurate of an idea as testing with the live production environment. In order to truly determine what will work best, you’ll definitely want to test with Windows Azure itself.

• If you’re device application is going to be communicating with services deployed to Windows Azure, you’ll want to test out the services running in instances in the Compute emulator. You can have the application on the device point to the service address provided by the emulator. Once that’s done, deploy to Windows Azure and have the device connect to the Staging URL to test out connectivity and operability.
• If you’re device application is working with the storage services (Blobs, Tables, Queues), you can test working with those using the Storage emulator. Once you have the storage emulator running, you can point the device application to the storage emulator URLs (make sure you pay attention to the port numbers), and test it out. Once that’s done, switch over to working with the live storage services, create your blobs, tables, and queues, and test out the application with the live environment.

If you’re an MSDN, MPN, or BizSpark member, you have Windows Azure benefits included with your subscription that give you ample resources with which to test Windows Azure. If you’re not a member, you can use the 90 day free trial which also gives you ample resources with which to test. The only difference is that you’ll have 90 days to do it in. For most scenarios, 90 days is sufficient to do the necessary testing.

TIP: You can now set usage limits on your Windows Azure deployments. This will help you ensure that you don’t go over the resources that are included with the trial or MSDN, MPN, and BizSpark memberships. This will then prevent any unwanted charges going on your credit card.

Get a Conversation Going

Do you have any questions about Windows Azure as it relates to devices? Have you already tried different services and architectures for your solution and learned a few things along the way? Start a conversation on LinkedIn and ask or share with others.

Disclosure

As I mentioned above, there is more than one way to do anything mentioned above and different scenarios will call for different architectures. What’s mentioned in this post is just A way of architecting the solution. Don’t take this post to mean that it is the only way or the best way.