Doodle Graphics

PDC201: A Lap Around Cloud Services

Windows Adger Azure - a British Microsoftie who can actually pronounce Azure.

So, it's an OS for the cloud, it provides:

• Hardware abstraction across many servers.
• Storage: Distributed, scalable and durable.
• Monitoring and Maintenance: CPU, disk, memory, bandwidth, etc - basically anything that they might bill you for - and alerting via Live Alerts (SMS, Email, etc).
• Currently it's all .Net, but they are looking into other options such as PHP, unmanaged code, etc.

When writing for the platform, beware that you're not running in complete Medium Trust - for example while you can open sockets, you can't connect to SQL Server

The two main roles on the platform:

1. Web Role - sites and services.
2. Worker Role - actually does work on things. Inbound requests come over HTTP(s).

The web role writes messages to the queue; the worker role watches the queue for jobs to work on.

Three main types of storage accessed via a REST based interface:

1. Queues - but these are not MSMQ. They are deleted after about 2 weeks - so no using them for cheap storage. When a message is read, it is hidden from the queue while the worker role processes it, but will be restored later if you don't clean it up - this allows for some level of guarantee that the message will be processed, but you need to be aware that a message might have already been started.
2. Tables - persistent storage for entities, but there's no relational features: joins, etc are not supported. Using a Partition Key allows MS to scale out your data easily, and using a partition key in your queries will limit the search scope nicely. You can also run parallel queries using the partition key.
3. Blobs - A file system in the cloud.

The SDK provides all you need to develop services - a local environment that will host a cloud service on Vista or Windows Server 2008, complete with mock storage (basically contained in a SQL Express instance), and a managed API, including Logging, Storage, Config.

Currently the logging is all stored in the cloud, and is the only way to get any reporting about the internal state of your application out of it when it's deployed. Currently you have to download these logs to read them. When you are developing locally, logging is per instance - in the cloud it is per application.

The config has a number of settings that define the application - some of which can be changed while the application is running (e.g. Number of Servers).

Local storage is isolated so it's not shared between servers, it's not session based, and can be blown away at any time, so don't expect it to be there when you come back twenty minutes later.

Currently there's one data centre in the US, but they are looking at adding more in different countries - especially for compliance, but also for failover. When you deploy to multiple servers the deployment is fault aware, and so will ensure at least some of your servers are in separate racks, etc.

Last note on debugging these locally - sometimes the storage system can start up and report that it's ready before it really is ready - usually just restarting the debug session will resolve this - this is mostly a problem when you a worker role that starts up and attempts to read from a queue that hasn't spooled up properly yet.

MSDN Ramp Up - myrampup.com or www.msdn.com/rampup - this is a great free resource on Microsoft Learning, providing you with a whole bunch of revision material around a few of the MS exams - I spent an hour going over a few of the items on here in preparation for:

MS Exam 070-536: Microsoft .Net Framework - Application Development Foundation

I passed! Woo-hoo! The only thing I guess I didn't really like was the whole "now spend some time telling us what you thought about each question in the exam" - I didn't know whether I'd passed or failed at this point, let alone which questions I'd messed up, so didn't feel I could comment properly… Also, in the Prometric survey, I wasn't sure what I should put for the "How far did you travel to get to the test centre today?" question - "Less than five miles", because I'd wandered up to the top floor from the exhibition hall, or "More than 60 miles", because I was in Spain, not London?

Overall highlights: I can build services, and apparently know about threading and application domains, but need to work on serialization - oh and if they'd actually asked me any questions on mailing, I'd probably have done better in the "Interoperability, Reflection and Mailing" section than I did.

SOA304: Building RESTful Services using Windows Communication Foundation

REpresentational State Transfer provides us with a uniform interface to interact with services:

• POST: Creates data
• GET: Retrieve data
• PUT: Updates data
• DELETE: Deletes data
• GET operations can be cached - there should be no side effects to a get.

PUT and DELETE are idempotent actions - it doesn't matter how many times you call them, the same thing will happen each time.

With WCF you can map methods to URIs and verbs, using the new attribute WebGet() - e.g. WebGet(UriTemplate = "/{id}") decorating the method GetOne(string id)

PUT, DELETE and POST need to use the WebInvoke(UriTemplate = "…", Method = "POST")

The REST toolkit for WCF is now available.

WUX405: Common ASP.Net Production Issues and How to Avoid Them

Go visit Tess's website for all the goodies.

The main topics covered where:

Performance issues:

• Low CPU - you're waiting on an external resource or you have a lock.
• High CPU - Busy server, infinite loops, etc.

Crashes:

• Recycling server - By default this happens are 20 minutes of idle time or 1700 minutes (29 hours), when the web.confg changes, a directory is renamed, or about 15 aspx files have been changed - check your Antivirus activity
• Exceptions - in timers or finalisers will bring down the process
• Stack Overflow - This is the end of the line, you can't do anything further here.
• Fatal Execution Engine Exception - the address details in the log are useful - basically your code has managed to get somewhere it shouldn't be able to go - either a bug in the CLR or a managed heap corruption - native code writing out of the buffer.
• Out Of Memory - Again, the application can't recover as there's no more space to recover into - on a 32bit server you'll start hitting OOM when you have about 800MB in Private Bytes or 1.4GB in Virtual Bytes.

You can (and probably should) also log the Application Lifetime Events to get more information on app restarts.

Once again: Do not prematurely optimize - test, monitor, trace, etc to find out where your issues are.

Session State - be aware that this is retrieved on every page request even if you don't use it - so if you're storing a large object in the session, and you're using SQL Session State, you're now serialising and de-serialising this large object on every page request, even if you're not using it on that page.

On this topic, take care with what you are serialising - a 1MB dataset takes about 15-20MB during serialisation! So look at using a dataset surrogate - derive from dataset, override the Serialize methods, and store what you need.

Filed under: Conferences, Tech.Ed