Avoiding Cloud Fail: Learning from the Mistakes of Azure with Mark Russinovich

Download this episode

Download Video

Download captions

Download Captions

Description

Mark will cover the lessons on what we’ve learned in Azure to help developers avoid making the same mistakes and build great apps using IaaS, PaaS or both. This will include some Azure internals information as well.

For more information, check out this course on Microsoft Virtual Academy:

Tag:

Azure

Day:

2

Code:

3-615

Room:

Hall 1B

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      JeNeSuisPas​Dave

      Update: this problem is now fixed. Thanks.

      Wrong video for this site. Wanted "Avoiding Cloud Fail" but got "Go Mobile with C# and Xamarin".

       

      :(

    • User profile image
      Paul Batum

      Its fixed now.

    • User profile image
      Ameer

      Wonderful talk, really refreshing to see this level of transparency versus others in the industry.

      That issue with the ceriticate failure; the public report suggested the following certs failed:

      *.blob.core.windows.net
      *.queue.core.windows.net
      *.table.core.windows.net

      Now, one issue this failure highlights is that the entire global storage namespace has a common URL, which is (for tablestorage, for example):

      <storage-account>.table.core.windows.net

      If the URL was instead:

      <storage-account>.<region>.table.core.windows.net

      For e.g.

      useast.table.core.windows.net
      usnorthcentral.table.core.windows.net
      ussouthcentral.table.core.windows.net
      uswebst.table.core.windows.net

      Which is analogous to how AWS does it, for instance, for S3, they have:

      (Refer to: http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region)

       

      s3-us-west-2.amazonaws.com
      s3-us-west-1.amazonaws.com
      s3-eu-west-1.amazonaws.com
      s3-ap-southeast-1.amazonaws.com
      s3-ap-southeast-2.amazonaws.com
      s3-ap-northeast-1.amazonaws.com
      s3-sa-east-1.amazonaws.com

      You would then have the ability to assign separate SSL certs per region. As long as you have a separate cert per region and ensure that all these certs expire on different dates, this would have been an incident isolated to a region and not global. True that time is a single point for failure. Might be possible, however, to potentially spread this risk over several slices of time.

       

    • User profile image
      Will

      Superb! So much of MS' current struggles with hanging on to its (dwindling?) developer corps is down to a terrible lack of honesty and straight-talking, particularly over the last few years.

      This kind of stuff is just fantastic - no real engineer thinks anything other than "there but for the grace of God go I" on seeing it. Those of us who are wary of cloud stuff because we suspect we're going to be lied to (in annoying MS-VP-speak, just to rub salt in the wounds) at every stage, on everything from resource provision through privacy through failure post-mortem cannot fail to be positively impressed.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.