Everything you need to know about Windows Azure queue storage to build disconnected and reliable systems

In my attempt to cover most of the features of the Microsoft Cloud Computing  platform Windows Azure, I’ve been recently covering Windows Azure blob and table storage. Today I’m reviewing the Windows Azure queue storage, which is often used to build disconnected and reliable systems:

Windows Azure Service Bus messaging with Publish/ Subscribe pattern with topic and subscription

The information about Windows Azure Blob storage:
Everything you need to know about Windows Azure Blob Storage including permissions, signatures, concurrency

The information about Windows Azure Table storage:
Everything you need to know about Windows Azure Table Storage to use a scalable non-relational structured data store 

Why using Windows Azure storage:

  • Fault-tolerance: Windows Azure Blobs, Tables and Queues stored on Windows Azure are replicated three times in the same data center for resiliency against hardware failure. No matter which storage service you use, your data will be replicated across different fault domains to increase availability
  • Geo-replication: Windows Azure Blobs and Tables are also geo-replicated between two data centers 100s of miles apart from each other on the same continent, to provide additional data durability in the case of a major disaster, at no additional cost.
  • REST and availability: In addition to using Storage services for your applications running on Windows Azure, your data is accessible from virtually anywhere, anytime.
  • Content Delivery Network: With one-click, the Windows Azure CDN (Content Delivery Network) dramatically boosts performance by automatically caching content near your customers or users.
  • Price: It’s insanely cheap storage

The only reason you would not be interested in the Windows Azure storage platform would be if you’re called Chuck Norris …
Now if you are still reading this line it means you aren’t Chuck Norris, so let’s get on with it.

Continue reading

Advertisements

Everything you need to know about Windows Azure Table Storage to use a scalable non-relational structured data store

In my attempt to cover most of the features of the Microsoft Cloud Computing  platform Windows Azure, I’ll be covering Windows Azure storage in the next few posts.

You can find the Windows Azure Blog Storage post here:
Everything you need to know about Windows Azure Blob Storage including permissions, signatures, concurrency, … 

Why using Windows Azure storage:

  • Fault-tolerance: Windows Azure Blobs, Tables and Queues stored on Windows Azure are replicated three times in the same data center for resiliency against hardware failure. No matter which storage service you use, your data will be replicated across different fault domains to increase availability
  • Geo-replication: Windows Azure Blobs and Tables are also geo-replicated between two data centers 100s of miles apart from each other on the same continent, to provide additional data durability in the case of a major disaster, at no additional cost.
  • REST and availability: In addition to using Storage services for your applications running on Windows Azure, your data is accessible from virtually anywhere, anytime.
  • Content Delivery Network: With one-click, the Windows Azure CDN (Content Delivery Network) dramatically boosts performance by automatically caching content near your customers or users.
  • Price: It’s insanely cheap storage

The only reason you would not be interested in the Windows Azure storage platform would be if you’re called Chuck Norris …
Now if you are still reading this line it means you aren’t Chuck Norris, so let’s get on with it.

The Windows Azure Table storage service stores large amounts of structured data. The service is a NoSQL datastore which accepts authenticated calls from inside and outside the Azure cloud. Azure tables are ideal for storing structured, non-relational data. Common uses of the Table service include:

  • Storing TBs of structured data capable of serving web scale applications
  • Storing datasets that don’t require complex joins, foreign keys, or stored procedures and can be denormalized for fast access
  • Quickly querying data using a clustered index
  • Accessing data using the OData protocol and LINQ queries with WCF Data Service .NET Libraries

You can use the table storage service to store and query huge sets of structured, non-relational data, and your tables will scale as demand increases.

If you do not know the OData protocol is and what is used for, you can find more information about it in this post:
WCF REST service with ODATA and Entity Framework with client context, custom operations and operation interceptors

The concept behind the Windows Azure table storage is as following:

Windows Azure Table Storage, a scalable NoSQL data store with OData support

There are 3 things you need to know about to use Windows Azure Table storage:

  1. Account: All access to Windows Azure Storage is done through a storage account. The total size of blob, table, and queue contents in a storage account cannot exceed 100TB.
  2. Table: A table is a collection of entities. Tables don’t enforce a schema on entities, which means a single table can contain entities that have different sets of properties. An account can contain many tables, the size of which is only limited by the 100TB storage account limit.
  3. Entity: An entity is a set of properties, similar to a database row. An entity can be up to 1MB in size

Everything you need to know about Windows Azure Blob Storage including permissions, signatures, concurrency, …

In my attempt to cover most of the features of the Microsoft Cloud Computing Windows Azure, I’ll be covering Windows Azure storage in the next few posts.

Why using Windows Azure storage:

  • Fault-tolerance: Windows Azure Blobs, Tables and Queues stored on Windows Azure are replicated three times in the same data center for resiliency against hardware failure. No matter which storage service you use, your data will be replicated across different fault domains to increase availability
  • Geo-replication: Windows Azure Blobs and Tables are also geo-replicated between two data centers 100s of miles apart from each other on the same continent, to provide additional data durability in the case of a major disaster, at no additional cost.
  • REST and availability: In addition to using Storage services for your applications running on Windows Azure, your data is accessible from virtually anywhere, anytime.
  • Content Delivery Network: With one-click, the Windows Azure CDN (Content Delivery Network) dramatically boosts performance by automatically caching content near your customers or users.
  • Price: It’s insanely cheap storage

The only reason you would not be interested in the Windows Azure storage platform would be if you’re called Chuck Norris …
Now if you are still reading this line it means you aren’t Chuck Norris, so let’s get on with it, as long as it is serializable.

In this post we will cover Windows Azure Blob Storage, one of the storage services provided by the Microsoft cloud computing platform. Blob storage is the simplest way to store large amounts of unstructured text or binary data such as video, audio and images, but you can save about anything in it.

The concept behind the Windows Azure Blog storage is as following:

Storing and retrieving data with Windows Azure Blob Storage

There are 3 things you need to know about to use Windows Azure Blob storage:

  1. Account: Windows Azure storage account, which is the account, containing blob, table and queue storage. The storage account blob storage can contain multiple containers.
  2. Container: blob storage container, which behaves like a folder in which we store items
  3. Blob: Binary Large Object, which is the actual item we want to store in the blob storage

Everything you need to know about Windows Azure caching service to improve performance for your cloud services

One of the features that are provided with the Windows Azure cloud computing platform, is the Windows Azure caching service, of which we will cover the basics in this post and show you how to set up the Windows Azure cache cluster.

1. Using memory caching to improve performance

By caching the information in memory and retrieving it from memory on subsequent request, we enhance performance greatly because we do not have to retrieve the information from disk every time, which is a lot slower then retrieving it from memory. Data that is being requested often and is not subject to fast change, is ideal to be cached in memory. The first retrieval the information is being retrieved from disk or database and after first retrieval we store the data in the memory cache. On the next request, we look if the data is available in cache and if it is, we serve it directly from the memory which is a lot faster.

You can get an idea of how big the difference in some cases could be by using memory retrieval instead of using disk retrieval.

Windows Azure Caching Service to improve performance with a cloud computing

Continue reading

Using Windows Azure Access Control Service to provide a single sign-on experience with popular identity providers

One of the services provided by the Windows Azure cloud computing platform is the Windows Azure Access Control Service. The Windows Azure Access Control Service is a hosted service that provides federated authentication and rules-driven, claims-based authorization

Quoted directly from MSDN:

Windows Azure Access Control Service (ACS) is a cloud-based service that provides an easy way of authenticating and authorizing users to gain access to your web applications and services while allowing the features of authentication and authorization to be factored out of your code. Instead of implementing an authentication system with user accounts that are specific to your application, you can let ACS orchestrate the authentication and much of the authorization of your users. ACS integrates with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID, Google, Yahoo!, and Facebook.

Available features on the Windows Azure Access Control Service:

  • Integration with Windows Identity Foundation (WIF)
  • Out-of-the-box support for popular web identity providers including Windows Live ID, Google, Yahoo, and Facebook
  • Out-of-the-box support for Active Directory Federation Services (AD FS) 2.0
  • Support for OAuth 2.0 (draft 10), WS-Trust, and WS-Federation protocols
  • Support for the SAML 1.1, SAML 2.0, and Simple Web Token (SWT) token formats
  • Integrated and customizable Home Realm Discovery that allows users to choose their identity provider
  • An Open Data Protocol (OData)-based management service that provides programmatic access to the ACS configuration
  • A browser-based management portal that allows administrative access to the ACS configuration

Now there is quite some stuff in the list above that I have no knowledge about. And to be honest, Security and Active Directory and so forth are not really my biggest interests. Security is a very important aspect, but I prefer to leave the hardcore stuff to the security people.

However that being said, integrating a website with the ACS to authenticate users against an identity provider like Windows Live ID, Google or Facebook is quite interesting. I know many of us have written websites before and using our own custom user store or a membership provider. We are holding sensitive data which is always a possible security leak. Integrating with an identity provider like Windows Live ID, Google or Facebook provides our users to experience the single sing-on experience and we do not have to worry about storing the sensitive data.

How many times have you not registered on some random website with a username and password that you can not remember anymore later ? Would it not be easier to identify yourself to all those websites with your Google or Facebook identity. It removes you from the hassle to remember all your different users and password and it lowers the risk of your credentials being exposed since your credentials will only be stored at identity providers such as Google or Facebook.

Continue reading

Windows Azure service bus messaging with publish/subscribe pattern using topics and subscriptions

In this post we will look into the publish/subscribe pattern with the Windows Azure Service Bus, which is a messaging platform in the cloud. One of the common use to build disconnected and reliable systems is the use of queues:

Windows Azure Service Bus messaging with Publish/ Subscribe pattern with topic and subscription

The Windows Azure Service Bus allows messaging using the publish/subscribe pattern, which looks like this:

Windows Azure Service Bus messaging with Publish/ Subscribe pattern with topic and subscription

The sender sends a message to a topic and anyone who could be interested in one of those messages, could subscribe to the topic. They could subscribe to receive any message, but they can also apply filters on the incoming messages to only receive certain messages that comply to the defined filter.

Continue reading

Windows Azure Data Sync with SQL Azure database hub, synchronization group and client sync agent

Windows Azure is the public cloud computing platform Microsoft provides. With the Windows Azure platform, they also provide a set of a tools to work on the platform and to integrate with on-premise solutions.

Windows Azure Data Sync

One of integration features provided with the Windows Azure platform is Windows Azure Data Sync

Gotten for the Azure Data Sync on MSDN:

SQL Azure Data Sync is an Azure service that enables you to easily synchronize geographically disbursed SQL Server and SQL Azure databases. Data Sync provides an intuitive UI with optional tutorials that guide you through the process of creating database groupings (sync groups) that are synchronized together. You define exactly what data from each sync group is synchronized – tables, columns and rows (using row filters), as well as how frequently the synchronization jobs are performed.

SQL Azure Data Sync uses a hub-spoke topology with the hub always being a SQL Azure database.

Our company has three departments around the world and each of these work with their own database, since connecting to a central database would issue too much latency for the departments. For that reason, they all use an identical database, but it is local to the department and it contains the information related to the department. Now the departments want to share the information between departments, but they want to keep their database local for latency issues. This means we can not set up a central database to which the departments will connect to, so we need to set up a synchronization mechanism. There are multiple synchronization mechanisms like for example SQL Server replication and so forth. We want to use the Windows Azure Data Sync service to synchronize the information between the different departments, on a 1 hour base. One of the good things about Windows Azure Data Sync is that we do not have to do any coding, we do not have to set up any synchronization agent and so forth, we just have to set up the Data Synchronization in the Windows Azure portal.

To use Windows Azure or Windows Azure Services you will need an active Windows Azure subscription. Windows Azure Data Sync can be found in the portal:

Windows Azure Data Sync

Continue reading

Windows Azure inner-role communication on internal endpoint with a WCF service hosted outside of RoleEntrypoint

At some point, you might experience some issues if you try to consume a service that is hosted on another role instance that is not being hosted in the default workerrole process.

Scenario:
We host a WCF Service in a windows service that is being installed on the azure role instance by a startup Task. This means the WCF service is not being hosted inside of the workerrole, which derives from the RoleEntryPoint.
We want to consume this service from another role instance.

Setup:
For the first role instance where we host the WCF service in a windows service, we need to define an internal endpoint, which we will use for the WCF service to listen on.

This endpoint is only used for communication between both the role instances, thus making it an internal endpoint.

InternalEndpoint

The required binaries of the windows service get copied to the windows azure instance by

Windows Azure Contents copy

We also have a startup task defined, which triggers the install of the windows service on the azure instance.  This startup task startup.cmd has been copied to the azure instance at the approot/definedfolder/ by the contents copy, together with the necessary windows service binaries.

Windows Azure startup task

Continue reading