Getting to Know Azure Mobile App Cont.

Microsoft Azure Mobile App has recently gone GA (General Availability) and has definitely captured my attention. Mobile App is a tremendous accelerator that enables us to go from an idea to a functional prototype quickly. Then, we can continue to build on that initial investment to create a robust production ready app. Finally, this post is all about using Visual Studio Team Services (VSTS) to build and publish apps to HockeyApp, so that we can test and assess quality before our apps make it to our favorite app Stores.

Refreshing Authentication Tokens

Authentication Tokens are short-lived and having users login to the App frequently can cause friction. This is definitely undesirable and can be dealt with by identifying when a Token is no longer valid. When this condition is met, we can attempt to refresh the Authentication Token by calling the Azure App Service Token Store APIs.

Getting to Know Azure Mobile App

Microsoft Azure Mobile App has recently gone GA (General Availability) and has definitely captured my attention. Mobile App is a tremendous accelerator that enables us to go from an idea to a functional prototype quickly. Then, we can continue to build on that initial investment to create a robust production ready app. Finally, using Visual Studio Team Services and Release Management, we can publish our apps to our favorite app Stores.

Why Mobile App

These are reasons why you should consider Mobile App on your next project. They certainly contributed to my agility throughout my adventure.

• Build native and cross platform apps
• Connect to your enterprise systems
• Connect to SaaS APIs easily
• Build offline-ready apps with sync
• Push Notifications to millions in seconds
• Automatically scale-out to handle any incoming customer load.
• Build low friction server-side REST services.
• Benefit from a simplified data access layer.
• Deliver functional prototypes with minimal effort.

The underlying connection was closed

For the past weeks I’ve used PowerShell to test REST APIs exposed over HTTPS. Everything was wonderful until I had to execute my script against a local instance of the service. My machine is not setup with proper certificates and PowerShell doesn’t see to like that. When ever I execute an Invoke-RestMethod command I get the following error message:

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

Looking around I was fortunate to find this one-liner that fixes everything!

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

By turning off certificate validation you are disabling security. Beware that this one-liner is a patch, and should not be used for anything else than development purposes.

Meet DocumentDB

These days I’m all about automation. As most of us are focused on Python, C# JavaScipt and Node I’m taking a different approach to Azure DocumentDB. This experiment’s goal is to facilitate the creation and seeding of DocumentDBs with very little effort from JSON documents stored an Azure Blob Storage container.

Azure DocumentDB is a NoSQL document database service designed from the ground up to natively support JSON and JavaScript directly inside the database engine. It’s the right solution for web and mobile applications when predictable throughput, low latency, and flexible query are key. Microsoft consumer applications like OneNote already use DocumentDB in production to support millions of users.

What is Azure API Management

Microsoft Azure API Management is a service that helps protect your mission critical systems with authentication, rate limiting, quotas and caching to ease load under pressure. Rest easy knowing that only the partners, developers and applications you’ve authorized have access to your APIs and that those groups are acting in accordance with your policies. Find out more on Azure.com

REST APIs

Like many services on Azure, API Management provides us with a comprehensive REST API. This API allows us to manage Users, Groups, Products and Subscriptions.

Working on a multi-region solution, I was really happy to see these APIs. One of the recurring challenges I face everyday, is to replicate my efforts across multiple deployments sprawled over many Azure regions. Now the only way to do this effectively is to automating everything!

As of August 2014 API Management is still in public preview and is going through constant evolution. New features make their way to production and pieces fall together. The newly released REST APIs are just that, a piece that was missing. Wanting to reduce my workload I decided to create a PowerShell Module to help automate some of my repetitive tasks.

Note: The API does not allow you to define APIs, Representations. The Developer Portal CMS is not accessible through these APIs. Although these are things I would love to interact with through the REST API, I’m hopeful that something will come along.

Before we start, there are a couple things we need to do. First we need to activate the Management APIs on our API Management service. Then we need to generate an access token. I opted for the manual process which you can follow on the Azure API Management REST API Authentication page.

Using PowerShell to Authenticate Against OAuth

From development to deployment, PowerShell is becoming the ‘go to’ automation technology on Microsoft Azure. So, I decided to use PowerShell to perform automated tests against a Web API (a.k.a REST service). These tests are built to run during the execution of a Continuous Release cycle and confirm that the API is responding as expected.

Getting Acquainted With #Azure Service Bus Event Hubs

The Microsoft Azure ecosystem just keeps growing. This week Microsoft unveiled a very welcomed addition to the Microsoft Azure Service Bus. Event Hubs join ranks with Queues, Topics and Relays to offer options adapted to your needs.

Contrasting available Service Bus Flavors?

• Relays – are used to bridge communications over the cloud in a secure and transparent manner.
• Queues – are pipes that allow for many publishes and many consumers to communicate over a single channel. This is great for Competing Consumers and for Queue-based Load Leveling.
• Topics – are pipes that allow fan out scenarios, where each consumer gets his own copy of the inbound queue. It also has some handy features like filters. Use this flavor to implement Pipes and Filters.
• Event Hubs – are a bit more complex. Event Hubs enable the collection of event streams at high throughput, from a diverse set of devices and services. In other words, they help us deal with the 3 Vs.
  • Volume (amount of data)
  • Velocity (speed of data in and out)
  • Variety (range of data types and sources).

Microsoft Azure Service Bus Event Hubs

Event Hub join ranks with Queues, Topics and Relays to offer options adapted to your needs. They province the mechanisms necessary to collection of event streams at high throughput, from a diverse set of devices and services. They are composed of a Published Policy, of Consumer Groups and of Partitions.

Event Hubs support the following scenarios:

• Collecting event streams at high throughput from devices/services for use in real-time and batch processing.
• Connecting millions of devices from diverse platforms for sending data (with individual authentication and flow control).
• Process event streams per device “in order” using several backend services (publish/subscribe).

Considerations Prior to Creating an Event Hub

You must put some effort in capacity planning before you create an Event Hub. In order to make the right decisions let’s go over a couple details about Event Hubs.

HTTP/1.1 503 Service Unavailable

On Azure we must design with cost of operation and service constraints. I recently had an interesting event where my REST Service, deployed on a small (A1) cloud service instance, started to respond with HTTP Status Code 503 Service Unavailable.

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. [Source: HTTP Status Code Definitions]

Faced with this interesting challenged I started looking in the usual places, which include SQL Database metrics, Azure Storage Metrics, application logs and performance counters.

Throughout my investigation, I noticed that the service was hit on average 1.5 million times a day. Then, I noticed that the open socket count was quite high. Trying to make some sense out of the situation, I started identifying resource contentions.

Looking at the application logs didn’t yield much information about why the network requests were piling up, but it did hint at internal process slowdowns following peak loads.

Working on extracting logs from Azure Table Storage I finally got a break. I noticed that the service was generating 5 to 10 megabytes of application logs per minute. To put this into perspective, the service requires enough IO to respond to consumer requests, to push performance counter data to Azure storage, to persist application logs to Azure storage and enough IO capacity to satisfy the application’s need to interact with external resources.

Base on my observations I came to the conclusion that my resource contention was around IO. Now, I rarely recommend scaling up, but in this case it made sense because the service move lots of data around. One solution would have been to turn off telemetry. But doing so would have made me as comfortable as if I were flying a jumbo jet with a blindfold on. In other words, this isn’t something I want to consider because I believe that telemetry is crucial when it comes to understanding how an application behaves on the cloud.

Just to be clear, scaling up worked in this situation, but it may not resolve all your issues. There are times when we need to tweak IIS configurations to make better use of resources and to handle large amounts of requests.Scaling up should remain the last option of your list.

Related Posts

• Lessons Learned – On #Azure, Log Everything!
• Choosing The Right Compute Virtual Machine Size

 

Getting to Know OAuth 2.0

A couple months ago I was asked to explain OAuth and I really did a horrible job at it. To be honest, I had used it without really digging into details. Following tutorials, using existing SDKs and NuGet packages I got by pretty well, but I wasn’t able to describe how it all worked.

OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

Recently, a requirement came up about authentication and authorization for a semi-public API. Remembering how I failed to answer the question the first time, I decided to get my hands on a short book that would bring me up to speed.

I bought "Getting Started with OAuth 2.0" by Ryan Boyd. In my opinion, it’s really a good place to start learning about OAuth 2.0. The book is short and to the point. It gives you a pretty good overview of the possible OAuth Flows, when to use them and which major OAuth provider currently supports them. The book is a little dated so you might want to refer to each of the provider’s documentation.

The OAuth 2.0 Authorization Framework enables a third-party application to obtain limited access to an HTTP service.

OAuth Flows Covered in This Book

• Server-Side Web Application Flow
• Client-Side Web Application Flow
• Resource Owner Password Flow
• Client Credentials Flow

The book also introduces OpenID Connect, which is a simple identity layer on top of OAuth 2.0. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

Have you read this book? Let me know if it satisfied your expectations.

More

• The OAuth 2.0 Authorization Framework Specification – RFC 6749
• The OAuth 1.0 Protocol Specification – RFC 5849 (the final version of the OAuth 1.0 specification)
• The OAuth Community Site
• OAuth Code & Libraries
• Community-driven support FAQ.
• OpenID Connect

Consider Using UTC (Coordinated Universal Time) When Designing REST APIs

With an ecosystem of devices that is constantly evolving, it’s hard to predict who will consume your REST APIs and how they will consume them. Devices as we know them are changing shape, consequently applications are constantly adapting to new platforms.

Lets face it, mobile apps are the norm and shouldn’t be ignored. They travel and shouldn’t be considered as sedentary.

Imagine a scenario where you are on a business trip and try to fetch today’s news from a different continent. Your device formulates a URI with a date and calls a service… no results…
That’s weird! Its 10 PM and I should get results for today’s news. This is probably the moment where you realize that you aren’t in your normal time zone… your phone has adapted to your new geographic location but the APIs the app is calling has not!