Windows Azure Use-Case: Mobile Development

One of the most natural development use-cases for the Windows Azure platform is with mobile devices, such as smartphones, tablets and even embedded computers in cars and other devices.

The reason this paradigm works so well is that most mobile devices are not as powerful as larger computers - they simply don’t have the room to power the device, keep it cool, and hold the components that they would like. So leveraging the computing power, data and networking capability from a massively distributed system is a natural fit.

Mobile devices, by definition, are often constantly connected to the internet. That means that you can access Windows Azure components from these devices whenever they are connected, and you don’t have to open firewalls into your own computing environment. In fact, you don’t have to have an infrastructure at all to set this all up - the user has the client (mobile device) the Internet is your network, and Windows Azure runs your code. Nothing on-premise is needed. Of course, using a hybrid model you can include components from on-site into your design as well.

So what are the main components of a mobile platform? There’s a great video by my friend Wade Wegner that you can watch here that covers these components step-by-step, but in a simple outline, here they are:

Client development environment and deployment

Each mobile device has an operating system and environment that it works with. Windows Azure has full toolkits you can use to develop against the major platforms in use today. You’ll need the Windows Azure Software Development Kit first (free) and a development environment (even the free Visual Studio Express edition is fine) and then you simply download the toolkits here:

Windows Phone: 


iOS (Apple):

Security and authentication

From there, you need to log people in and out of the service you provide. You can certainly write your own authentication into Windows Azure if you wish, but it’s often far easier to allow your users to connect with an identity they’ve already established. This takes you out of the business of storing profiles, names and passwords.

You can use multiple providers - and some of the easiest to work with and most popular are Windows Live, Facebook, Google and Yahoo. Using the Access Control Service (ACS) feature in Windows Azure, you can “point” to those providers and the user will be presented with those login screens. From there, you trust the provider to hold the names and passwords identifying the user. You can learn more about that process here: 

Of course, you’re still able to write your own login logic, and you always control access to the assets the user can see.

Networking and connectivity

With a mobile device, the carrier that the user has is responsible for the “last-mile” to the device. But with Windows Azure, you are using the some of the largest connections to the internet available - and you have three regions around the world to deploy your applications to. You’re able to select which region you want, so you can provide everything from code to data to the device in a reliable way.

One caveat here - you need to ensure your code has logic to deal with connectivity issues. You don’t control the provider the device uses, so you should make decisions about caching, retry logic, disconnect messages and so on based on what your application does. Different parts of your application might require a specific strategy around what needs to be constantly connected and what can display on it’s own from the storage on the device. There are always tradeoffs for each of these decisions.

Platform components

Windows Azure is a platform - which means that it isn’t a single unit or thing, it’s a group of components that work together. You can choose any or all of these components based on what your application needs to do.

Computing - With Windows Azure, you can call on standard computing resources to provide the front-end for your application, or to do the processing for your application logic. You might choose to embed the full client experience on the device, and simply have Windows Azure compute data or perform other logic. Or, you might choose to develop the entire application, front-end and all, on Windows Azure. This approach is sometimes the least “rich experience” method, but the most device-independent. Using the Windows Azure platform you can scale (even programmatically) from very small when the demand is low to thousands of compute resources based on higher demand, and back down again.

Storage - Windows Azure has multiple types of storage, from NoSQL-like table storage to binary large object storage for documents, music, videos, and so on. Your application can use storage independently - perhaps backing up the application’s data into Windows Azure and nothing else. Or, you can use storage with the computing resources. There is also a message queue that is part of the Windows Azure storage, allowing a fully REST-ful development paradigm which allows for scale. Queues are also interesting for a combinatorial approach - passing computing work between devices and then re-combining those. In fact, using this paradigm you could have your mobile device submit jobs to a super-computing fabric.

The binary storage also has a Content Delivery Network (CDN) feature that moves the data closer to the user in an “edge” methodology.

Application Fabric - The Application Fabric component of Windows Azure is actually made up of yet more components. This is the area that holds the ACS mentioned earlier, and it also has a full Service Bus component for inter-process communication. You can also leverage a cache in this component to speed up your applications.

SQL Azure - For mobile development, working with location-aware applications is a primary feature. SQL Azure is a Relational Database Management System (RDBMS) that has a Spatial Data capability, where you can work with not only Geodesic information on the mobile device, but geometric data as well.


There are many resources for Windows Azure development for mobile devices. The primary one is here: You can find code, videos, whitepapers, the toolkits and more from that link. In addition, be sure and follow Wade Wegner’s blogs and postings for more information.

Comments (1)

  1. agileinfoways says:

    From the abstraction point of the view, the Azure Service Bus represents a logical connectivity between the event sources and their consumers using a loosely decouple model – reference:…/

    The connection string can either be retrieved from the portal, or using our powershell / x-plat CLI tools.

Skip to main content