I am at the Azure Firestarter event in Redmond today and just heard Mark Kottke talk about his experiences as an app development consultant with Microsoft on migrating existing customer apps to Azure.  Here are my notes; slides and sample code are to be posted later and I will update the post with them when they are.

Migrating to Windows Azure - Mark Kottke

  • Helping early adopter customers move to Azure
  • Most were new applications but some were migrations.
  • How to plan a migration
    • What is easy?
    • What is hard?
    • What can you do about it?
  • Why migrate?
    • Flexibility to scale up and down easily
    • Cost
  • Is it better to start over or just migrate existing code?
    • Migration "seems" easier - code already written, tested, no users to train, …
    • But…
  • Six customers
    • Kelley Blue Book
      • Now in two data centers and costs quite a bit to keep up the second data center
      • ASP.Net MVC app with SQL Server
      • Migrated pretty quickly
      • Use Azure as a third data center (in addition to their two existing data centers)
    • Ad Slot
      • Migrated storage to Azure tables.
      • Biggest change because of difference from SQL
      • Similar data architecture to the BidNow application.
    • Ticket Direct
      • New Zealand's ticket master
      • Used SQL Azure
    • RiskMetrics
      • Pushed the scaling the most of the case studies.
      • It had scaled to 2000 nodes by the time of PDC 2009
      • Do Monte Carlo analysis for financial applications. The more trials they can run, the better the results.
      • Their key IP is a 32-bit DLL that does this - they were able to move that without rewriting it.
    • CSC - Legal Solutions Suite
      • ASP.Net application like Kelley Blue Book
    • CCH Wolters Kluwer
      • Financial Services ISV
      • Sales tax engine to integrate with ERP systems. Currently sold as an on-premises solution with regular updates for the sales tax rate changes.
      • Moving to the cloud made it easier for customers - no need to do updates or manage software on-site.
      • Sales Tax engine was written in a 4GL from CA called FLEX that generates .NET code but it worked fine.
  • Typical apps are comprised of n-tiers: presentation, services, business logic, data. First thought is to migrate everything - but could migrate just part of it.
    • e.g. Could migrate just the presentation layer - avoids dealing with all the security issues.
      • Benefit is get development team up to speed on Cloud, processes modified to include Cloud, …
  • Q: Could you upload a BLG file (Binary Log File) that shows what RAM usage, what transactions, etc. and have the Azure ROI tool estimate the cost of running this service on Azure?
  • Q: How about if you put the cost of your demo apps on the apps - just knowing what the cost of a demo app would be helpful.
    • A: Good idea.
  • Data Storage Options
    • Have MemCacheD, MySQL in addition to other options discussed (SQL Azure, Azure Tables, etc.)
    • To migrate a DB to SQL Azure…
      • Using SQL Server Save or Publish Scripts, extract all the information about the local DB.
      • Using Management Studio connected to SQL Azure, create a new DB.
      • Open the script file created from the existing local DB
      • Execute it against the SQL instance.
      • Can use SQL Azure Migration Wizard (http://sqlazuremw.codeplex.com/)
    • Q: Will the database automatically scale up from 1 GB -> 10 GB?
      • A: No, but you can use the portal to modify it.
  • Caching / State Management
    • Velocity - not yet available for Windows Azure
    • Can use ASP.NET cache but not shared across instances.
    • Can use ASP.NET membership / profile providers - on Codeplex there is one that uses SQL Azure.
    • Can use Memcached. Pretty straightforward to use for caching session state.
    • Cookies, hidden fields - any client-side providers basically work fine.
  • For app.config and web.config - how much of your state needs to be able to be changed when the app is deployed
    • Move to ServiceConfiguration.cscfg to allow for run-time update.
    • Leverage RoleEnvironmentChanging and RoleEnvironmentChanged events if you want to be able to change default behavior of recycling the role on any config change.
    • Use RoleEnvironment.IsAvailable to determine whether you are running in the cloud or on premises.
  • Using WCF Service endpoints that are exposed only within the role - not exposed to the Internet, not load balanced.
    • Need to call Windows Azure APIs to discover the services and wire up once the server is running.
    • Important for Memcached to share caching.
    • WCF Azure samples: http://code.msdn.microsoft.com/wcfazure
  • Legacy DLLs
    • To call a 32-bit DLL use a WCF host process
    • For external processes (EXEs)
      • Host in a worker Role
  • Can deploy to staging and then flip to production - the staging has a GUID.
    • No requirement to use staging but it is a good practice to test.
    • Sometimes need to change configuration changes between staging (test) and production
  • Start with development fabric / development storage
    • But if using SQL Azure - better to use SQL Azure in the cloud because there are a enough differences between the local SQL and SQL Azure that it's worth testing against the cloud SQL
  • Then test development fabric / cloud storage
  • Then cloud fabric / cloud storage