1 / 24

(re)-Architecting cloud applications on the windows Azure platform

(re)-Architecting cloud applications on the windows Azure platform. CLAEYS Kurt Technology Solution Professional Microsoft EMEA. Do you need to re-Architect ?. If you want to use the benefits of Azure ... Benefis are : Elastic Scalability High Availablity (SLA) Reduced costs

cora-collier
Download Presentation

(re)-Architecting cloud applications on the windows Azure platform

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. (re)-Architecting cloud applications on the windows Azure platform CLAEYS Kurt Technology Solution Professional Microsoft EMEA

  2. Do you need to re-Architect ? • If you want to use the benefits of Azure ... • Benefis are : • Elastic Scalability • High Availablity (SLA) • Reduced costs • Mass storage • Assync 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.

  3. Azure Basics • Azure apps are loadbalanced • No sticky sessions. • No server affinity. • Azure is a public PAAS • It’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 environment • Adding more instances of the same power instead of adding more power to a single instance. • Azure is a OPEX environment • The code (you architect) decides how much you pay.

  4. Azure Compute SLA Windows 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

  5. Azure Solution Architecture Windows Azure Service SQL Data Your Service Worker Service NL B Worker Role SQL Internet SQL Your Storage SQL Queues Web Site (ASPX, ASMX, WCF) Web Site (ASPX, ASMX, WCF) Web Role (ASPX, WCF) Tables Blobs

  6. Azure Network Load Balancer webrole NLB Instance 1 Instance 2 Instance 3

  7. Azure Network Load Balancer webrole NLB Instance 1 Instance 2 Instance 3

  8. Azure Network Load Balancer webrole NLB Instance 1 Instance 2 “round robin” no sticky sessions ! Instance 3

  9. Developing for a load balancer • No sticky sessions • Avoid use session variables • Store state in ASP.NET viewstate • More bandwidth needed • Not compatible with MVC pattern • Store state in SQL Azure • You could redirect sessions state to SQL Azure, Azure Storage or AppFabric Caching • No server affinity • Do not write data to the local filesystem • Write data to Azure storage • You could use Azure Blob drives (in single instance setup)

  10. Scaling engine App performance metrics Local DB App App running on 2 instances 3 interprete metrics defines on metrics and polling intervals Scaling engine changes the configuration Configuration

  11. Unit of Scale pattern • 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...

  12. Scaling storage • Azure Storage support huge volume tables • Tableschema is part of your application • Huge capacity • 100TB of storage per storage account • 1 subscription can have 5 storage accounts • Need to partition your tables to have a good response time • Azure will move hot partitions to separate nodes to achieve SLA’s

  13. Azure Storage Tables partition key Tables are partitioned to support load balancing across storage nodes unique row key timestamp table field1 field2 field3

  14. Table Partioning Data Row key Partition key A 123 foo bar etc A 123 foo bar etc A 124 foo bar etc A 124 foo bar etc B B 123 123 foo foo bar bar etc etc Partition “B” Partition “A” Storage node 1 Storage node 2

  15. All cities in world (7.500.000)

  16. All cities in world (7.500.000)

  17. SQL Azure throttling/retry logic • 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. 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 ... }

  18. Azure Queues Service busy free workerrole webrole Instance 1 Instance 1 busy Instance 2 Instance 2 Instance 3 Instance 3 Putmessage

  19. Azure Queues Service busy free Getmessage workerrole webrole Instance 1 Instance 1 busy Instance 2 Instance 2 Instance 3 Instance 3 one (and only one) free instance of the workerrole gets the message

  20. Working with Queues Workerroles read messages from queue to start a job assync. GetMessage = 1 REST call, GetMessages(32) = 1 REST call CloudQueueMessagecloudQueueMessage; cloudQueueMessage = cloudQueue.GetMessage(); //process single message List<CloudQueueMessage> cloudQueueMessages; cloudQueueMessages = cloudQueue.GetMessages(32).ToList(); //process all messages on multiple threads

  21. Working with Queues Watch out for trying to read messages to often. while (true) { System.Threading.Thread.Sleep(timeToSleep); CloudQueueMessagecloudQueueMessage; cloudQueueMessage = cloudQueue.GetMessage(); if(cloudQueueMessage!=null) { //process single message } }

  22. Operational costs 1 year, 24 h/day every second 10 GetMessage calls =$315,36 1 year, 24 h/day, every minute 1 GetMessageCall = $0,52 Costs multiplied by 600 !!

  23. Summary • 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 Scale • Stateless applications • Data partitioning • Retry Logic vs Throttling • Assync architectures using queues • Cost effective coding

More Related