Yousef A. Khalidi Distinguished Engineer Windows Azure ES02.

Architecting Services For Windows Azure

Yousef A. KhalidiDistinguished EngineerWindows Azure

ES02

Main Takeaways

Cloud services have specific design considerations Always on, distributed state,

large scale, and failure handling Windows Azure is an operating system

for the cloud Scale out, dynamic, and on-demand

Windows Azure manages services not just servers Tell it what you want, and it

will help automate the details Windows Azure frees developers

from many platform issues Developers concentrate on application

logic instead of platform issues

Overview Of Talk

Describe how to architect Windows Azure services

Describe service life cycle management Show how Windows Azure’s

architecture enables automation Show how developers are

freed from many platform issues

Scale-out not scale-up Add and remove capacity on demand Pay for what you use as you go Automation is key to reducing costs

Characteristics Of Cloud Computing

Cloud Services Design Considerations

Failure of any given node is expected View each node as a cache State has to be replicated

No one-time install step Applications need to reinitialize on restarts Do not assume previous local state is available

Configuration changes due to load or failures Handle dynamic configuration changes

Design Considerations

Services are always running Service rolling upgrades/downgrades Services must handle data schema changes

Services are built using multiple nodes/roles Document service architecture Document communication paths of elements

Services can grow very large Careful state management at scale is needed

Windows Azure manages services not just servers Tell it what you want, and it will automate the details System manages services, nodes, and network

Automates service life-cycle management Model-driven automation Allocation, deployment, and service-level management

Turns pool of physical resources into shared compute fabric Pay for what you use Platform insures service isolation

Benefits Of Adhering To Windows Azure Design Point

Windows Azure Service LifecycleGoal is to automate life cycle as much as possible

AutomatedAutomatedDeveloper Developer/Deployer

Coding and Modeling

New services and updates

Provisioning

Desired configuration

Deployment

Mapping and deploying to actual hardware

Network configuration

Maintain goal state

Monitor React to

events

Service Model Guides Automation

Describes service as distributed entities Authored by service developer Configured by service deployer

Logical description of the services Same model used for testing and production Mapped to actual hardware

at deployment time Powerful declarative composition language

Can describe simple to very complex services

Windows Azure Service Model Elements

Service

Set of roles, groups, and channels

Role

Program, execution entity Group

Set of other groups, roles and channels

Endpoint

Communication end point exported by role

Channel

Logical load-balancers and switches

Interface

Exposed by services Configuration settings

Developer settingsSystem settings

Public Internet

Modeling Simple Services

Fundamental Services

Load Balancer

FrontendWeb Role

Background Process Role

Template automatically maps to service model

Load Balancer Channel

Endpoint

Interface

Directory Resource

Modeling Complex Services

Example of high scale video conferencing service

Require high performance, reliability

Needs ability to automatically adjust scale

ExampleVideo Conferencing Service

Fault Domains

Purpose: Avoid single points of failures

Unit of a failure Examples: Compute node,

a rack of machines System considers

fault domains when allocating service roles Example: Don’t put

all roles in same rack Service owner assigns

number required by each role Example: 10 front-ends,

across 2 fault domains

Allocation is across fault domains

Fault domains

Update Domains

Purpose: ensure service stays up while updating

Unit of software/configuration update Example: set of nodes to

update Used when rolling forward

or backward Developer assigns number

required by each role Example: 10 front-ends,

across 5 update domains

Allocation is across update domains

Update domains

Dynamic Configuration Settings

Purpose: Communicate settings to service roles There is no “registry” for services

Application configuration settings Declared by developer Set by deployer

System configuration settings Pre-declared, same kinds for all roles

Instance Id, Fault Domain Id, and Update Domain Id Assigned by the system

In both cases, settings accessible at run time Via call-backs when values change

Windows Azure Automation

Fabric Controller (FC) Maps declarative

service specifications to available resources

Manages service life cycle starting from bare metal

Maintains system health and satisfies SLA

What’s special about it Model-driven service

management Enables utility-model

shared fabric Automates hardware

management

Fabric Controller

“What” is needed

Make it happen

Load-balancers Switches

Fabric

Windows Azure Push-button Deployment

Step 1: Allocate nodes Across fault domains Across update domains Step 2: Place OS and role

images on nodes Step 3: Configure settings Step 4: Start Roles Step 5: Configure load-balancers Step 6: Maintain desired

number of roles Failed roles

automatically restarted Node failure results in new

nodes automatically allocated

Allocation across fault and update domains

Load-balancers

Managing Running Services

Adding capacity Push-button Steps from previous slide

performed to running service Removing capacity

Push-button Steps reversed

Rolling service upgrades Push-button Performed one update domain at a time

Rapid Reliable Software Provisioning

Image-based multicast deployment Scalable and reliable

Separate OS and services images Images are copied, not installed Same images used for

physical machines and VMs Multiple images are cached

Version caching allows quick updates and rollback

Monitoring And Events

Log collection Alerts Usage metering Data available through portal

Service Isolation And Security

Your services are isolated from other services Can access resources

declared in model only Local node resources –

temp storage Network end-points

Isolation using multiple mechanisms

Automatic application of Windows security patches Rolling OS

image upgrades

Managed code

Restriction of privileges

Firewall

Virtual Machine

IP filtering

Windows Azure Is Highly Available

Network has redundancy built in Switches, load-balancers, and access routers

Services are deployed across fault domains Load balancers route

traffic to active nodes only Fabric controller state check-pointed

Can roll-back to previous checkpoints Guards against corrupted or loss of FC state Stored across fault domains

Windows Azure Automates Data Center Management

Provisioning and monitoring of hardware elements Includes TOR and L2 switches, LBs, and access routers

Hardware life cycle management Burn-in tests, diagnostics, and repair Failed hardware taken out of pool

Application of automatic diagnostics Physical replacement of failed hardware

Capacity planning On-going node and network utilization measurements Proven process for bringing new hardware capacity on-line

Internal security measures Data center security Internal authentication and auditing

Roadmap

Supported Life-Cycle Automation

Windows Azure PDC release Automated service deployment from bare metal Subset of service model –

simple set of service templates Support for changing number of running instances Simple service upgrades/downgrades Automated service failure discovery and recovery Automated hardware management

Include automated network load-balancer management In calendar year 2009

Expose more of underlying service model Richer service life-cycle management

Supported Services

Windows Azure PDC release Managed code/ASP.net Running in fixed-sized VM instances External virtual IP address per service Service network isolation enforcement

In calendar year 2009 Native code support Richer network support

Also, in 2009 will be in multiple data centers

Summary

Cloud services have specific design considerations Always on, distributed state,

large scale, and failure handling Windows Azure is an

operating system for the cloud Scale out, dynamic, and on-demand

Windows Azure manages services not just servers Tell it what you want, and it

will help automate the details Windows Azure frees developers

from many platform issues Allows developers to concentrate on

application logic instead of platform issues

Related Content

Upcoming related PDC sessions Showcase: Cloud Computing Platform Enables

Publishing Services, Wed 10/29, 10:30 AM-11:45 AM

A Day in the Life of a Cloud Service Developer, Wed 10/29, 3:00 PM-4:15 PM

Under the Hood: Inside the Cloud Computing Hosting Environment, Thu 10/30, 10:15 AM-11:30 AM

http://www.azure.com/windows

Evals & Recordings

Please fill

out your

evaluation for

this session at:

This session will be available as a recording at:

www.microsoftpdc.com

Please use the microphones provided

Q&A

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.