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