Notes from ES 16: A lap around Windows Azure

Windows Azure is an OS system for the cloud

Background

"What is the cloud" it is a set of connected servers on which developers can

  • Install and run services
  • Store & retrieve data

To put it into perspective. Right now if you want to go build and run a desktop app.

  • Need to select hardware, find device drivers, write a file system
  • Write a job scheduler
  • Write an application installer
  • Etc.

Why are we all doubling up on this? We're also replicating the same stuff with cloud services today.

  • We need to respond to hardware failures,
  • handle increases in traffic
  • Increase storage
  • Apply OS patches
  • Perform live upgrade on our service
  • And want to expand

Then we finally write some logic on top of all of this

On the desktop an OS helps abstract some of this away

Windows Azure is an OS in the cloud to help us just concentrate on writing business logic and not how to handle all the other stuff

What does Azure provide?

  • Abstracts the execution environment
  • Shared file system
  • Resource allocation
  • Programming environments
  • 24/7 operation
  • Pay for what you us

It is a shared model. So as you need more, you just pay for more. We don't care which server our code runs on, we just chuck it up there and they worry about which computers it is executing on.

Main features

Automated service management: Write the code, define the rules and click go. Azure will auto setup all the load balancers, spin up the machines, etc.

Scalable storage: blobs, tables, queues

A RICH familiar dev experience. They built a complete simulation of the cloud on your desktop.

An example: interact with the web role, the user inserts some data through the web role and it is placed into cloud storage onto the queue. Then the worker role can read them off the queue and process.

When we run it the developer fabric spins up the web and worker roles for us. So we can check concurrency issues locally instead of waiting till we deploy it.

Automated service management

First we develop our code and create a model

The model has: Service topology and size. What does it look like, do we have front end roles, back end roles, do we use storage, etc.

What does it mean for our app to be healthy? We spin up 20 frontends, 5 go down. We need an alert

What things do we want to change at runtime so that we don't have to redeploy our code to Azure?

Then we deploy and run

Then have to maintain the service health

Once the service is up and running, as things fail (code fails, we upgrade, etc.) our customer should not know or care.

We need to detect failures and notify us when things are not healthy.

MS can transparently fix some issues. If a frontend goes down, they can just start up a new frontend.

So we declare logically how many resources we need. APIs map these logical resources to physical resources (server instances)

So abstraction helps to keep things manageable

Has been designed to handle a full range of scenarios from hobbyist to enterprise

In raw mode you can build your own VM and deploy the bits and manage the service yourself. But MS can't auto do things

Scalable cloud storage

Simple storage abstractions

Large items of user data: blobs, (file streams coming soon)

Service state: tables, (caches coming soon)

Service communication: queues, (locks coming soon)

It is MASSIVELY scalable 1000s of tables, etc. with geo-distribution and geo-replication

But this is not a database in the cloud, use SQL data services for larger scale things. This is only for simple tables

Familiar dev experience

A simulated cloud environment on the desktop

Supports ASP.Net, .Net languages, (native code and PHP coming later)

Integration with Visual studio & eclipse(coming soon)

MSDN, etc. (since it is just usual .net)

Can use logging & alerts to monitor how things are going. (tracing coming later)

Putting it all together

Using a simple architecture for scalability

A bunch of web roles load balancing the client requests. The requests are dumped into the cloud storage. Worker roles pick the requests off the queue and process.

clip_image001

Commercial release notes

2009 will be the commercial release.

Consumption based billing

They have strict SLAs with FINANCIAL guarantees

Geo-distribution, can say where in the world you want to host it for latency

They have done an initial release

They are going to frequently release more and more features, once we all say that there are enough features, they will release the commercial release

By David Burela