(re)-Architecting cloud applications on the windows Azure platform CLAEYS Kurt Technology Solution Professional Microsoft EMEA
Jan 20, 2018
(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