Shifting Responsibility Patterns
For our next test we made more considerable changes to the architecture. We moved parts of the on-premises application to the cloud, thereby placing the responsibility for data access closer to table storage. We were still ordering the work from the on-premises part, but much of the real operations now took place in a Windows Azure Worker Role in the cloud. That allowed us to make the conversation pattern even more coarse-grained. We kept using the slow connection, because that was more interesting than using the fast one. If we had used the fast connection only, questions about performance on a more commonly used and slower connection would still remain.

The result was amazing. The entire job was now completed in 1 minute and 26 seconds, representing an 88 % improvement in relation to the original about 12 minutes.

You must keep your Worker Roles Stateless
We ...

For the last months Per and I have been incredibly busy creating content for Microsoft’s Windows Azure Architect training program. It’s a Microsoft program, but we have the main responsibility for development and administration of the program.

Some time ago Per and I had an interesting experience. We were benchmarking a hybrid application, changing its bandwidth resources and modifying its architectural design between test runs. It was a hybrid application, because part of it was running on-premises and part of it in the cloud.

The purpose of the application was to create and populate a number of example Windows Azure Tables for the program, deployed in Microsoft’s Northern Europe Data Center. It generated a number of person, organization, employment, product, lead and lead subject entities, saving them in different tables in Windows Azure Storage.

Fine-Grained (Typical) Architectural Design – Slow Connection
The first test run was designed the way I ...