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.

WhichWayI’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 Posts

AzureCampIf 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 social apps and games. Just to make sure that we’re on the same page, let’s define them first:

  • A social application is an application that centers around the communication and interaction between several people. Further, one might argue that social applications are the same as social networks. There is no clear cut definition, so for the purposes of this discussion, let’s consider them as either/or. Facebook, Twitter, and FourSquare are all examples of social networks, all of which have front ends that are the social applications.
  • A social game is a game that, similar to social applications, centers around the interaction between people. Notice I say people rather than players who may actually be computer simulated players.

Attributes of Social Apps and Games

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

  • Centered around the communication and interaction between people
    This attribute is self-explanatory. Where it gets interesting, however, is when you look at the number of people that are involved in the communication or interaction. This number could be in the single digits or in the millions, either way, the architecture of the app/game and its infrastructure need to be able to handle it.
     
  • Potential of Viral Growth
    Chances are that if you’re thinking of creating a social app/game, you’re thinking of either building it to be accessed from existing social networks like Facebook, Twitter, LinkedIn, and others or creating a new social network between those that will use your app. Especially in the case of the former, where you’re integrating into existing networks, those networks have millions of users that may potentially want to use your app/game. All it takes is a few people who really like it to share with their friends, followers, connections, etc. and your app/game goes viral in no time.
  • Expectations of Immediacy
    When we think social, we think shared experiences. When we think shared experiences, we think of real-time or immediate interactions. Unlike email where you send and eventually expect a response back, social apps and games are all about what’s happening now. If you’re playing a game, like Tankster, with someone, you’re going to expect that when he or she makes a move, you immediately know about it. If you’re updating your status or posting something in your social app, you’re not only going to want people to see it on their end right away (because whatever you’re talking about is happening now), but when they respond, you’re going to want to see their responses right away. Social apps and games are all about the now.

    In addition, when integrating with established social networks, they’ve set the bar for performance. When you integrate, you simply must meet or exceed that bar in order for your users to be happy. For example, say you build a Facebook application. Someone accesses your application from their Facebook profile. They’re going to expect it to respond just as fast, if not faster, than Facebook itself did.
  • Connections from anywhere
    Not only can your app/game go viral easily, the likeliness of your users to be in one geographic location is quite low. Most use social experiences like apps and games to bridge the distance that exists when people are all over 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:

  • Let’s look at centered around the communication and interaction between people and the potential of viral growth first. Similar to websites, the ability to react to increased demand relates to scale. Scale is achieved by using more than one Windows Azure Compute instances. The more compute instances you add, the more “horse power” your app/game will have and therefore the more it will be able to take on. This increases the speed at which the app/game will respond to requests, and more importantly, its ability to handle the traffic that comes to it by sharing the work across the multiple instances.

    If you’re social app/game is device-based or even PC-based, scale will refer to the backend services that support you app/game – i.e. the services that the app/game connect to and work with. In this case, those would be deployed to the compute instances and would get the additional “horsepower”. (More about this in the devices discussion)
  • Expectations of immediacy actually breaks into a few areas and consequently has different services that address them:

    Performance – Performance is addressed with Windows Azure Compute instances as mentioned above. In addition to Windows Azure Compute instances, the Caching Service can increase the performance of your app/game by temporarily storing information in memory (within the service), saving you the trip back to relatively slower data mediums, such as Storage Services or SQL Azure (it can also reduce the costs associated with transactions against those services).

    Latency - Latency is the amount of delay your application can tolerate between requesting a resource and receiving a response. The most basic thing you can do to ensure low latency is host your app/game or backend services in a datacenter that is geographically close to your users.  Choosing where to deploy your compute instance(s) is a feature that comes out of the box with Windows Azure.  There are also two additional services that can assist with reducing latency. Traffic Manager takes care of intelligently routing requests from users to a datacenter that is closest to where the user is located based on rules that you can define. For example, if you have your app/game/backend services deployed to one of the Windows Azure North American datacenters and to one of the European data centers and a user is using accessing the app/game from 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. For content such as graphics, app/game data, and other binary data, you’ll want to use the Content Delivery Network (CDN) to geographically distribute those storage objects, placing copies in “edge nodes”, or cache nodes around the world. These copies would then be physically closer to application requests, reduce the distance the storage objects have to travel, and ultimately increase the responsiveness of your app/game.
  • The connections from anywhere attribute is addressed by the services mentioned above.

Using the attributes of social app/games 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 posts 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 social apps and/or games, you can download the Windows Azure Toolkits for Social Games that, through its core libraries and samples, will show you how to build the components you would need for real-time, scalable social apps and games. The toolkit contains native libraries in different languages, samples that you can peruse and learn from, project templates, and of course, documentation.

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 your social app/game is going to be deployed to Windows Azure, you’ll want to test it with the Compute emulator first to make sure that everything is working as expected. Once that’s done, deploy it to Windows Azure, test the app/game in the staging environment, and then finally, deploy it to the production environment.
  • If you’re social app/game is going to deployed outside of Windows Azure but will be communicating with services deployed to Windows Azure, you’ll want to first test the services themselves running in instances of the Compute emulator. Then test with your app/game, pointing it to the services at the address provided by the emulator. Once that’s done, deploy the services to Windows Azure and test the app/game connected to the Staging URL. Once that’s done, test the app/game connected to the production URL.

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 social apps/games? 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.