My photo
Auckland, New Zealand
Smurf sized geeky person with a penchant for IT, gaming, music and books. Half of industrial duo 'the craze jones'. Loves data, learning new things, teaching new things and being enthusiastic.

Tuesday, 15 September 2009

Overview of Azure

Notes from Chris Auld's presentation at TechEd 09. Again, as with the other TechEd blogs, these are just notes that I can use to find out further information when more time is available. :)

  • High scale application architecture
  • Consolidate traditional IT to the cloud
  • Move servers and apps out-house
  • Reliable hardware in the cloud
  • Virtualize to the cloud
  • Manage explosive growth (scale out cloud)
  • Scale out clouds are built around disposable hardware
  • Reliability is built using software
  • Scale out cloud is load balanced by default
  • Greeness - PUE (power usage effectiveness) = Total Facility Power / IT Equipment Power. Google and Microsoft are getting around 1.10 to 1.25 PUE. Intergen server room is running at about 1.6 PUE.
  • MS cloud offering = Windows Azure, .NET Services, SQL Azure
  • Azure sits you above the abstraction layer (IMAGE TO GO IN HERE)
  • Compute source (IMAGE TO GO IN HERE)
  • Load balancer is key part of Windows Azure
  • RoleEntryPointStart() has no return value. Always while True.
  • VMs are cloud optimised
  • VMs are running 64 bit Windows Server 2008
  • Each VM has one to one relationship with processor core
  • Developers have a desktop environment available that simulates the cloud locally
Storage in the cloud
  • HTTP(S) via REST services into cloud storage
  • Scales out across server farms consistently
  • Blobs are addressable as URLs
  • Tables are persistent dictionary, not relational
  • Queues link worker role and web app role
  • Can access Azure storage from any app that can get through using HTTPS via port 443
  • Only port 443 at the moment
  • Horizontal data partitioning
  • Have to nominate a partition key
  • Items with same partition key stored on same partition
  • Items with different partition keys MAY be stored on different partitions
  • MUST access via REST, can't use ADO.NET
  • SDK provides some useful tools
  • No SQL - no real joins/aggregates; limited indexes; no schemas; no referential integrity
  • Can't easily move relational database to the cloud
  • Will scale out MASSIVELY
  • Don't need prior knowledge of how many partitions will be required
  • Queue - receive work in to the web role, it then writes message to the queue, worker role processes the message and then deletes it. If message not done, it is re-added to the queue and processed again. Need to watch out for messages being duplicated.
  • May only need 10 instances for 24/7/365, but it's easy to switch to 1000 instances for the 5 days a year that you may need that many.
  • Great for start up businesses as there are no requirements to buy server hardware anymore, you can get up and running very quickly in the cloud
SQL Azure
  • True relational database management source
  • Pared back, so missing some things, i.e. SSAS, SSRS
  • "Huron'' data hub
  • Accessed via port 1433 using tabular data stream
  • Sticky, stateful load balancer
  • Database spread across a minimum of 3 servers
  • 10GB is currently the largest database size in the cloud
  • If you put too much load you'll get errors - so if you have a large DB, partition it.
  • Need to deal with partition code inside your application
.NET Services
  • Inter application message broker
  • Provides access control service / claim mapping
  • Provides service bus
  • Cloud based intermediary between clients and internal applications
  • Provides service registry that finds services
  • Quickly establish bi-directional communication
  • Direct connectivity libraries with NAT probing
  • Access control service implements security token service (STS) in the cloud. Accepts new token and issues another as claims outgoing may be different to incoming claims.
  • Admin can define rules for claim transformations.
What others are doing
  • Amazon/Mosso - pay as you go - you have to set up and maintain your own servers in the cloud.
  • Microsoft/Google/SalesForce - pay as you go - vertically integrated, no server setup/maintenance required
  • VMWare/Appistry - Buy up front - set up and maintain your own servers
  • Amazon are currently the market leaders
  • Amazon use the Elastic Compute Cloud (EC2)
  • Amazon - VMs that let you run Linux or Windows, have to patch/maintain your own servers in the cloud
  • Amazon's cloud offering is highly flexible
  • Google app engine supports Java/Python only
  • Google you can only execute code for 30 seconds at a time
  • Google uses non-relational, scale out storage
  • Salesforce (SFDC) uses the SFDC defined language
  • SFDC is used for data driven apps
  • SFDC uses non-relational, scale out storage
  • SFDC has no dedicated processor instance
  • Windows Azure + SQL Azure = cheapest HA offering available at the moment
Before moving to the cloud:
  • Think about how you'd partition your data
  • Follow high scale application architecture guidelines

No comments: