architecting for the cloud

© 2009 RoCk SOLid KnOwledge 1

RoCkKnOwledge

SOLiDhttp://www.rocksolidknowledge.com

Architecting for the CloudRichard Blewett


Agenda

The Problem Space

Managing State

Architect for Change

Dealing with Failure


ScalingMainframe Approach


ScalingCloud Approach


Effects of scaling

Applications run on many machines concurrently

Every request may hit a different machine

Hardware fails


Statelessness is King

Statelessness: Local state of any kind is unreliable

Store critical state in Azure Storage or SQL Azure

See Eric Nelson’s talk for more details


.NET Services Service Bus


Don’t be Scared of the Service Bus

Messaging backbone for the cloud

User Service Bus to bridge in-flight cloud data to full data on premise

Enables rich message exchange patterns


Prefer Asynchrony

Connect components using queuesAzure queue storage

Synchrony is a form of coupling


Asynchrony = Load Levelling


Asynchrony = Scalability


Its OK to Degrade

Some functionality is mission critical

Other functionality can wait

Degrade service to maintain mission critical functionality

You can do everything else later


Not Everyone Needs Perfect Consistency

Many services move though “inconsistent” states

EmailIMSMS


Update is Hard

Difficult to update and remain available

Design for rolling updateAzure supports two concurrent deployed versionsAzure will support update groups

Update Group 1 Update Group 2 Update Group 3


Update Code *or* Data

Do not update code and data at the same time

Design data to handle multiple code versionsDesign code to handle multiple data versions


Maintain Compatibility

Make sure that you can roll back change without breaking everything


Timing of Update can be Hard

Depends on location of users

Depends on work pattern of users

Don’t forget the Pacific Ocean is big with a low population


Change is Inevitable

Expect things to changeDon’t hard-code valuesUse azure config

string val = RoleManager.GetConfigurationSetting("LoggingLevel");


Azure configuration

<ServiceConfiguration serviceName="PhotoGallery"> <Role name="WebRole"> <Instances count="1"/> <ConfigurationSettings> <Setting name="LoggingLevel" value="Error"/> </ConfigurationSettings> </Role></ServiceConfiguration>

<ServiceDefinition name="PhotoGallery"> <WebRole name="WebRole"> ... <ConfigurationSettings> <Setting name="LoggingLevel" /> </ConfigurationSettings> </WebRole></ServiceDefinition>

.csdef

.cscfg


What Just Happened?

Debugging and Diagnostics non-trivial

Use local fabric for testingTest against local storageTest against cloud storage


Tracing is Key

Add trace statements in codeCan be filtered on log level from configCritical errors raised as alerts

if( RoleManager.GetConfigurationSetting("LoggingLevel") == "Verbose"){ RoleManager.WriteToLog("Information", "Product Purchased");}


Failures Often Transient

Build retry logic into your code

Remember to stop retrying eventually


Failures Can be “Catastrophic”

Don’t assume your “shutdown” logic will be executed

Try to keep state consistent enough at all times

Think about sanity checking on start


Fault Domains

Fault domains allow you divide application for fault tolerance

Not available yet

Fault Domain 1 Fault Domain 2 Fault Domain 3


The Challenges are Not Just Technical

CostEstimatingActual

Lock-inVendors have vested interest

LegalWhere is my data?


RoCkKnOwledge

SOLiDhttp://www.rocksolidknowledge.com

Q & AThanks for coming

[email protected]://rocksolidknowledge.com/blogs

architecting for the cloud

Documents