Connecting to Azure Redis Cache Service from Python

Recently I had someone ask me how to connect to the Microsoft Azure Redis Cache Service from Python. I figured it would be easy considering how simple python is to learn. It turned out to be a little trickier than expected but still not too hard nonetheless.

Below is the sample code, then I’ll explain what each part is doing.

import redis
 
r = redis.StrictRedis(host='[cache-name].redis.cache.windows.net', port=6380, db=0, password='[access-key]', ssl=True)
r.set('foo','bar')
result = r.get('foo')
 
print result 

To start you will need to install redis-py (or a redis client of your choice) from your favourite package installer, I’m using pip.

pip install redis

There are three things you need to be aware of when connecting to Redis on Azure:

  1. SSL
  2. Password
  3. Port

Most of the time when you connect to a redis server it will be on your local machine which is fairly secure because there is no need for an outbound connection to the internet. When connecting to a Cloud Server there are many things that could go wrong in the security department so the Microsoft Azure Redis Cache uses a few things to avoid security issues.

First is a secure connection (SSL), when you connect to Azure you want to ensure that the data going across the wire is encrypted. Second a Password is used to authenticate access with the cache. Finally, the port number has been changed from the default due to the secure connection.

The key when using any Redis library is to ensure that it supports these three things, then once you know that the client supports them, it may still take some investigating to ensure that they are properly enabled when attempting to connect.

When looking at the connection object in python, you’ll notice that SSL is explicitly set to True this is required or you will receive an exception: ConnectionError: Error while reading from socket: (10054, ‘An existing connection was forcibly closed by the remote host’).

Happy Clouding!

Windows Azure SDK for PHP – ‘PartitionKey’ property value must satisfy is_string.

When building out an application there are many factors you need to consider, these considerations boil down to functional and non-functional requirements that you as a developer or architect are set out to achieve. In many circumstances, if not all, we are accepting data as an input from a user or other medium, transforming or normalizing that data into something that will help fulfill other requirements of an application.

In order to fulfill scalability goals it may be necessary to find alternative means to traditional storage, something that was designed with scalability in mind. One such service is Windows Azure Table Storage which is defined as:

[Windows Azure Storage] Tables offer NoSQL capabilities for applications that require storage of large amounts of unstructured data. Tables are an ISO 27001 certified managed service which can auto scale to meet massive volume of up to 100 terabytes and throughput and accessible from virtually anywhere via REST and managed API’s.

The topic of Windows Azure Storage Abstractions and their scalability targets is some what out of scope of this post, however, keep in mind that it is important to understand the Windows Azure Storage Architecture and more specifically How to get the most out of Windows Azure [Storage] Tables.

Integer values for PartitionKey or RowKey with PHP

If you’ve done your research on designing for scale with Windows Azure Storage and you find that Integer values are what you need for your specific data model, keep in mind that PartitionKey and RowKey values are of type string.

While this doesn’t seem like a foreign concept you may find yourself in a situation where you have an error while attempting to use integers as strings while interacting with the Windows Azure SDK for PHP. The error you will receive is “PartitionKey [or RowKey] property value must satisfy is_string”. In my particular scenario I was loading my tables by iterating through an array of key/value pairs.

My array looked like this:

In which you may expect the key to be treated as a string, which isn’t the case. To understand the reasoning behind this, we’ll go right to the source.

The key can either be an integer or a string. The value can be of any type.

Additionally the following key casts will occur:

  • Strings containing valid integers will be cast to the integer type. E.g. the key "8" will actually be stored under 8. On the other hand "08" will not be cast, as it isn’t a valid decimal integer.
  • Floats are also cast to integers, which means that the fractional part will be truncated. E.g. the key 8.7 will actually be stored under 8.
  • Bools are cast to integers, too, i.e. the key true will actually be stored under 1 and the key false under 0.
  • Null will be cast to the empty string, i.e. the key null will actually be stored under "".
  • Arrays and objects can not be used as keys. Doing so will result in a warning: Illegal offset type.

According to the documentation, you’ll notice that “strings containing valid integers will be cast to integer type”, in order to ensure that the now converted integer is provided to the service proxy as a string, we need to call strval() on the key when providing it as a PartitionKey or RowKey. To provide an example of this consider the following:

Where addEntity() constructs an entity and inserts it into Windows Azure Table Storage.

Conclusion

In this post I clarified a potential issue that may arise when iterating over an array with key/value pairs to push entities into Windows Azure Table Storage.

Stay Cloudy My Friends…