Notes from ES 16: A lap around Windows Azure
Windows Azure is an OS system for the cloud
"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
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.
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.
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