2. Who am I?
Chris Woodruff
MVP, Visual C#
Director at Perficient
Co-host of Deep Fried Bytes Podcast
@cwoodruff / cwoodruff@live.com / Skype: cwoodruff
3. Talk Goals
• Overview of SQL Azure Mobile Services
• Understand Benefits of SQL Azure Mobile Services
• Introduction to Azure Mobile Services
• Demo Azure Mobile Services
• Understand Mobile Services Push Notifications
• Demo Mobile Services Push Notifications
• Why does Windows Azure Mobile Services benefit your projects?
• Wrap Up
9. Understand
Authenticated
Storage with Mobile
Services
1. Request a Shared Access Signature
(SAS) from your service
2. SAS returned from your service
3. Upload blob (image/video/binary
data) directly to Blob Storage using
the SAS
4. Storage service returns response
What Are Shared Access Signatures?A Shared Access Signature is a URL that grants access rights to containers, blobs, queues, and tables. By specifying a Shared Access Signature, you can grant users who have the URL access to a specific resource for a specified period of time. You can also specify what operations can be performed on a resource that’s accessed via a Shared Access Signature. In the case of Blobs operations include:-- Reading and writing page or block blob content, block lists, properties, and metadata-- Deleting, leasing, and creating a snapshot of a blob-- Listing the blobs within a containerWhy not just use the storage account name and key directly?There are a few standout reasons:-- Security – When building device applications you should not store your storage account name and key within the device app. The reason is that it makes your storage account susceptible to being misused. If someone were to reverse engineer your application take your storage account key then they would essentially have access to 100TB of cloud based storage until such a time that you realized and reset the key. The safer approach is to use a SAS as it provides a time boxed token with defined permissions to a defined resource. With policies the token can also be invalidated/revoked-- Scale Out (and associated costs)- A common approach I see is uploading an image directly through their web tier e.g a Web API or Mobile Service unfortunate consequence of this at scale is that you are unnecessarily loading your web tier. Consider that each of your instances on your web tier has a limited network I/O. Uploading images directly through this will result in maxing out that I/O and the need to scale out (add more instances) much sooner then alternative approaches. Now consider a scenario where your application requests only a SAS from your web tier you have now moved MBs or image load off your web tier and instead replaced it with a small ~ 100 – 200 byte SAS. This essentially means a single instance now will provide much more throughput and your upload I/O now directly hits the Blob storage service
Let Perficient’s Healthcare team be your rapid response to jumpstarting your 4010 to 5010 migration! We appreciate your time today and now we will take questions. While you are creating your questions in the chat window, I want to get you thinking about these questions as well.