Yousef A. Khalidi, Distinguished Engineer Windows Azure presents.

Main Takeaways

• Cloud Services have specific design considerations : always on, distributed state, large scale, failure handling (you should expect failures and you should handle them)
• Windows Azure is an OS for the Cloud : scale out, dynamic, and on-demand. Each machine runs its own layer, but together this makes an OS
• Windows Azure manages services not just servers : tell it what you want, it will help automate the details
• Windows Azure frees developers from many platform issues : you concentrate on application logic instead of platform issues

How to architect Windows Azure Services ?

Cloud Computing is based on Scale-Out not scale-up. You can add / remove capacity on demand. Pay for what you use as you go. Automation is key to reducing costs.

Design considerations

Failure of any given node (or role) should be expected : view each node (or role) as a cache, state has to be replicated (don’t assume your state is safe)

No one-time install step : applications need to reinitialize on restarts. Do not assumre previous local state is available (If a node fails, we will try to restart you)

Configuration changes due to load or failures : handle dynamic configuration changes

Services are always running (there is no maintenance window) : your code has to handle upgrades or downgrades + your code 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 : state management will become difficult

=> Those issues are not new : you have tried to be as stateless as possible.

If you have good design, Windows Azure will manage your services, nodes and network. Windows Azure automates life cycle management (Model Driven Automation).

Service Lifecycle Management

Process :

1. Coding and Modeling,
2. Provisionning (desired configuration),
3. Deployment (Mapping and deploying to actual hardware (boot VMs), network configuration),
4. Maintain goal state (Monitor, React to events). If you asked for 10 front ends, we will try to maintain them.

How do we do it ? through a Service Model which describes services as distributed entities (authored by the service developer and configured by service deployer). It is a logical description in a declarative language.

Models Elements

• Service : a set of roles, groups and channels
• Role : it is your code, it can be instantiated multiple times, your business logic
• Group : set of groups, roles and channels
• EndPoint : communication endpoint exported by the role
• Channels : logical load balancers and switches
• Interface : exposed by services
• Configuration settings :  Developper and System settings

Modeling Simple Services

In the CTP, we have a few templates which map to a service model. It is the assembly language we consume.

It is possible to model complex services : see conference ES25 during lunch time tommorow. Video Conferencing Service. The Windows Azure Storage service is dogfodding.

Fault Domains

You should avoid single points of failure. A fault domain can be a compute node, a rack of machines. If you ask for 10 nodes on 2 domains, we will put 5 in each domain.

Update Domains

Ensure service stays up while updating. Allocation is across update domains.

This concepts are hidden from you, yet, you need to be conscious if you want to do complex scenarios.

Dynamic Configuration Settings

In the cloud there is not registry.The dynamic configuration settings communicate settings to service roles. Application configuration settings and System configuration settings (pre-declared, same kinds for all roles : instand id, fault domain id, update domain id.

Settings are accessible at run time

Windows Azure Automation

The Fabrik Controller (FC) is the brain of the system. It is the entity responsible for monitoring and ensuring your goals.

Windows Azure push button deployment

1. Allocate nodes : across fault domains and across update domains
2. Place OS and role images on nodes
3. Configure settings
4. Start roles
5. Configure load-balancers
6. Maintain desired number of roles : failed roles are restarted, node faiulure result in new node allocated

Managing Runnning Services

Adding Capacity, removing capacity, rolling services upgrades / downgrades

Behind the cover, we do a lot of things : we distribute the software through VM (multi-cast deployment), separate OS and service images. Boot from a VM image. Images are copied not installed. Multiple images are cached (version caching allows quick updates).

Monitoring and events

log collection, alerts, usage metering, data available through portal

Isloation and security

Your services can access resources that are delcared in its model, local node resources / temporary storage, network end-points declared.

Isolation is ensured using multiple

• Managed code with Medium trust
• Processes with priviledge restrictions
• Firewall
• Virtual Machine
• IP filtering

Automatic windows update

Data Center Management

Provisionning, monitoring, hardware lifecycle management, capacity planning, internal security measures

Roadmap

TO DO : incomplete

CTP

• Subset of the service model (look at the SDK)
• Support changing number of running instances
• Simple service upgrades / downgrades
• Automated service falure discovery and

• Managed code / ASP.Net
• running in fixed sized VM instances
• External virutal IP address per service
• Service network isolation enforcement

2009

• Expose more of underlying service model
• Richer service model management

FAQ

Q : Is it possible to provision automatically ?

A : not in CTP, will come later may be.

Q : Can we get automatic adaptation to load ? I do not want to define a precise configuration but limit (minimum / maximum). You talked about capacity planning.

A : not exposed by CTP

Q : Which version of windows is it ? and .Net ? Can I add SDK’s ?

A : Windows Server 2008, .Net 3.5 SP1, not provisioning of .Net SDK is exposed. Should come later.