Meeting #1 of Boston Azure User Group!
Keynote speaker: Brian Lambert of Microsoft
Meeting was held Thursday October 22, 2009 at Microsoft NERD in Cambridge, MA
Mike Werner (Microsoft evangelist for Azure in the Northeast) introduced the user group at this innaugural meeting, plugged the upcoming Microsoft PDC, then introduced Bill Wilder, the guy who started the Boston Azure User Group.
Bill Wilder provided an overview of the group (powerpoint slides):
- All meetings will have Windows Azure focus
- Any technology or business concept – cloud models, Microsoft dev technologies, tools, and so forth – is fair game, but must be presented with appropriate Azure slant: they need to be related back to Azure or else they are not appropriate for Boston Azure User Group meetings
Brian Lambert spoke on how to build applications for Windows Azure.
Bill’s raw notes from Brian’s talk:
- Can call unmanaged DLLs through Full Trust
- “Fabric Controller worries about the “shape” of your app”
- Background processing – utility computing
- May communicate with outside services
- Not externally visible to client
- Queues ~ how we communicate to a Worker Role ~ since both Worker Roles and Web Roles can talk to storage (like Queues), this is a good medium
There are public and private containers in blog storage. Public is the only accessible to clients (w/o keys that is).
Partitioned for scale
Blobs = ? “cloud files”
- Up to 50 GB / blob + 8k of metadata
Azure Dev Workflow:
- Add some Web Role(s)
- Add 0+ Worker roles
- Add Service Configuration
- Add Service Package
- Upload to Windows Azure Management Portal
- Deploy to Windows Azure Fabric Controller
- Provision / Run the roles and storage needs; monitors the health
Sticky Storage ?
Azure Tools + Azure SDK
For “dev” + “test” + “etc.” – may want to use REAL azure accounts – not just the “other account” you have in your main production account
Need to handle the “at least one worker role will work on it” contract – your application needs to be designed for this…
“poison message” – due to bug or oversight or bad data, a message from the queue will NEVER be successfully handled. App needs to handle this currently.
Queue timeouts can have different values – could be, say, different for different message types.
Worker Role => a class that inherits from WorkerRoleMain (what was this class name??)
Fabric occassionally calls GetHealthStatus() which returns a RoleStatus. If you tell the Fabric you are Unhealthy, the Fabric may slay you? Maybe your NIC card is flakey, so your performance to external web services is too slow?
Public container for blob – for actual image (full size) linked to from the thumb.
“Fiddler is your friend when you’re working … watch your requests.”
Dev Fabric + Cloud Storage is an excellent mode to run in for effective debugging – can watch the message traffic with Fiddler.
“There is no debugging in the cloud. There’s logging.”
RoleManager can also write to “local storage” [[more interesting access / features coming soon!]] – then can go to Portal and use “configuration” button to update your config file to “copy logs” (did they move it?)
can even bring web site up with http://localhost:8020
WorkerRole is very simple to just run it in a process
Use Test Running to fire up a WorkerRole
- Tight dev cycle
- Can also now run a performance profile
Tricks: log in “real fabric”, write to console in “dev fabric”