October 2009 Boston Azure User Group Meeting Notes

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”

Worker Roles

  • 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”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s