(re)-Architecting cloud applications on the

windows Azure platform

CLAEYS KurtTechnology Solution ProfessionalMicrosoft EMEA

If you want to use the benefits of Azure ...Benefis are :

Elastic Scalability High Availablity (SLA)Reduced costsMass storageAssync architecture

Yes !Even if the benefits are not really important ...

You are just looking for a hosting platform ...Yes !

For Azure ... applications should be stateless.To avoid failures.

Do you need to re-Architect ?

Azure apps are loadbalancedNo sticky sessions.No server affinity.

Azure is a public PAASIt’s public, some of the resources are shared.It’s a Platform, delivers generic building blocks to implement a solution.

Azure compute is a scale out environmentAdding more instances of the same power instead of adding more power to a single instance.

Azure is a OPEX environmentThe code (you architect) decides how much you pay.

Azure Basics

Azure Compute SLAWindows Azure has separate SLA’s for compute and storage. For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains your Internet facing roles will have external connectivity at least 99.95% of the time. Additionally, we will monitor all of your individual role instances and guarantee that 99.9% of the time we will detect when a role instance’s process is not running and initiate corrective action.

http://www.microsoft.com/windowsazure/sla

Azure Solution Architecture

Internet

Windows Azure Service

Your Service

Web Site(ASPX, ASMX,

WCF)

Web Site(ASPX, ASMX,

WCF)Web Role

(ASPX, WCF)

Worker Service

Worker Role

Your StorageTables Blobs

Queues

NL B

SQL Data

SQL

SQL

SQL

Azure Network Load Balancer

webrole

Instance 1

Instance 2

Instance 3

NLB

Azure Network Load Balancer

webrole

Instance 1

Instance 2

Instance 3

NLB

Azure Network Load Balancer

webrole

Instance 1

Instance 2

Instance 3

NLB

“round robin”no sticky sessions !

No sticky sessionsAvoid use session variablesStore state in ASP.NET viewstate

More bandwidth neededNot compatible with MVC pattern

Store state in SQL AzureYou could redirect sessions state to SQL Azure, Azure Storage or AppFabric Caching

No server affinityDo not write data to the local filesystemWrite data to Azure storageYou could use Azure Blob drives (in single instance setup)

Developing for a load balancer

Scaling engine

AppApp

running on 2 instances

performance metrics

Local DB

Scaling enginedefines on metrics and polling intervals interprete metrics

Configurationchanges the configuration

App

3

Scaling should done in units. A unit-of-scale is a combination of components in multiple layers. Example: application instances and the database together should be considered as the unit-of-scale. If you add application instances you should also add databases. Not necessary 1-to-1, but you should know how many instances a database can handle and add them if needed. Consider all mechanisms that have different scaling behavior like queues, storage, blob drive IO, bandwidth...

Unit of Scale pattern

Azure Storage support huge volume tables Tableschema is part of your applicationHuge capacity

100TB of storage per storage account1 subscription can have 5 storage accounts

Need to partition your tables to have a good response timeAzure will move hot partitions to separate nodes to achieve SLA’s

Scaling storage

Azure Storage Tables

table

partition key

row key

timestamp

field1

field2

field3

Tables are partitioned to support load balancing across storage nodes unique

Table Partioning

A 123 foo bar etcA 124 foo bar etcB 123 foo bar etc

Partition key Row key Data

A 123 foo bar etcA 124 foo bar etc

Partition “A”

Storage node 1

B 123 foo bar etc

Partition “B”

Storage node 2

All cities in world (7.500.000)

All cities in world (7.500.000)

Sharing a SQL Server node means throttling to protect the other customers.Throttling means : a connection to SQL Azure could be dropped unexpectedly.Solution : Before issuing a command against a connection check if is still open, re-open it if SQL Azure has closed it.

SQL Azure throttling/retry logic

using (ReliableSqlConnection conn = new ReliableSqlConnection(connString)) {

// Attempt to open a connection using the specified retry policy.

conn.Open(sqlAzureRetryPolicy); // ... execute SQL queries against this connection ...

}

Service

Azure Queues

webrole

Instance 1

Instance 2

Instance 3

workerrole

Instance 1

Instance 2

Instance 3

busy

free

busy

Putmessage

Azure Queues

webrole

Instance 1

Instance 2

Instance 3

workerrole

Instance 1

Instance 2

Instance 3

busy

free

busy

Getmessage

one (and only one) free instance of the workerrole gets the message

Service

Working with Queues

CloudQueueMessage cloudQueueMessage;cloudQueueMessage = cloudQueue.GetMessage();//process single message

List<CloudQueueMessage> cloudQueueMessages;cloudQueueMessages = cloudQueue.GetMessages(32).ToList();//process all messages on multiple threads

Workerroles read messages from queue to start a job assync. GetMessage = 1 REST call, GetMessages(32) = 1 REST call

Working with Queues

while (true){

System.Threading.Thread.Sleep(timeToSleep);CloudQueueMessage cloudQueueMessage;cloudQueueMessage = cloudQueue.GetMessage();if(cloudQueueMessage!=null){

//process single message}

}

Watch out for trying to read messages to often.

1 year, 24 h/day every second 10 GetMessage calls

= $315,36

1 year, 24 h/day, every minute 1 GetMessageCall

= $0,52

Operational costs

Costs multiplied by 600 !!

Re-architecting is needed.Just moving app to cloud is easy but does not give you all benefits.Need some design patterns to reach the benefits :

Scalibilty – Unit of ScaleStateless applicationsData partitioningRetry Logic vs ThrottlingAssync architectures using queuesCost effective coding

Summary