Currently one very important space is the development of applications for Connected Devices like Windows Phones, Windows Slates, and so on.
One important element is that we are currently going more and more to Wireless, and so it’s important to understand the current state of the art on Wireless.
According to AT&T, “We will deliver as much data over our network in the first 5 weeks of 2015 as we did all year in 2010”.
Also, currently there are several identified congestion factors that are affecting Wireless, like:
- More subscribers with SmartPhones consuming data, uploading and downloading photos and videos
- Spectrum + cell towers + antennas + home users
- Mobile operator bandwidth caps
- Latency of all communication between the server and the destination device, passing by the cell towers, backhaul network, internet, firewalls, and so on
And so having this is mind, it’s really important to understand that we as developers cannot continue thinking that we’re going to continue developing our apps and services the same way, without thinking about these network related topics, because this will greatly affect the user experience of our solutions. And one important note is that UX is not only related to the User Interface (UI), like some developers try to think, it’s more than that. It’s really about having a great experience while using our applications.
So in order to do great applications for connected devices, and support millions of those devices, we need to think about scale.
Some examples of how we can scale our applications are:
- Making database that almost nobody touches, since we really shouldn’t let every single device connect and work on our databases; instead we should really be doing multi-tier applications to abstract those devices from the database, and by doing that, we are reducing the stress of our databases and at the same time enabling the possibility of scaling the services that really give us access to our data
- Place thousands of Web Servers on commodity hardware, by scaling out their app
- Replicate data
- Scale horizontally
- Use NoSQL databases at the edge
- Share our data using small tables for fast access
- Place load-balancing at every tier
- Use hundreds of terabytes of data in a in-RAM distributed cache (for example, Facebook uses MemCache and has something like 300 TB of data in memcache)
- Use pre-compiled elements, since compiling is slow (for example, Facebook uses PHP because they think that is very productive for them, but it didn’t work very well in terms of compiling, so they made a team to create a PHP to C++ compiler in order to get more performance)
- Use the MapReduce pattern for parallel analysis of “Big Data”
Some of the apps that are doing this are, Bing, Facebook, Twitter, Google, Zynga, and so on.
In order to achieve that kind of scale we have Windows Azure. But what should we do to take the best out of Windows Azure for Connected Devices?
- Scale-out. This is easy in Windows Azure, because we can define the number of instances we want of a particular role
- SQL Azure should never be touched by the devices. Instead, we should use:
- In terms of outbound data - Worker roles that replicate outbound data from SQL Azure to NoSQL Azure Table Storage
- In terms of inbound data - Worker roles move inbound data from Azure queues to SQL Azure
- Use distributed caching, that in Windows Azure is handled by AppFabric caching
- Do wireless efficient services. For example, using Web Roles that expose REST + JSON WCF Services is very interesting, because it saves message size, and by doing so, saves time and money
- Also important is making our devices cache data and work on it offline. Not every thing should be made “live” and on top of “live” data. Don’t stress out the wireless connection.
I hope this helps you think better about your Connected Device apps.
