1 / 32

Lessons Learned: Building Multitenant Applications with the Windows Azure Platform

SVC33. Lessons Learned: Building Multitenant Applications with the Windows Azure Platform. Ben Riga benriga@microsoft.com. Phil Calvin CTO Sitemasher Corporation. Stephan Friedl Chief Architect Quark, Inc. A Definition. For our purposes:

omer
Télécharger la présentation

Lessons Learned: Building Multitenant Applications with the Windows Azure Platform

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SVC33 Lessons Learned: Building Multitenant Applications with the Windows Azure Platform Ben Riga benriga@microsoft.com Phil Calvin CTO Sitemasher Corporation Stephan Friedl Chief Architect Quark, Inc.

  2. A Definition • For our purposes: • Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations(tenants). • Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. • Different Approaches to Data Isolation • Separate/Shared DBs, Separate/Shared Schemas Source: Wikipedia: http://en.wikipedia.org/wiki/Multitenancy

  3. Sitemasher www.sitemasher.com Phil Calvin CTO Sitemasher Corporation

  4. Sitemasher website platform • Website Infrastructure platform built on ASP.NET in C# • Initial Development began late 2006 • Running live on private cloud since 2008 • ASP.NET 3.5SP1, Server 2008, SQL 2008 • Launching Azure version at PDC • “Shared Everything” multitenancy model • 2 Axis – Service Providers and Individual Sites • Try it: http://www.sitemasheronazure.com

  5. Multitenant Model

  6. Request/Response General Model Browser Application (Azure Web Role) Caching (Worker Role) • Same model for all request types • AJAX Requests in Development • Page Requests in Production • Asset Requests within Pages SQL Azure Database Servers

  7. Request/Response Lifecycle Application (Azure Web Role) • Determine Current Site and Service Provider • Determine SQL Connections • Content • Membership Provider • Check Access • Process Request

  8. Web front end architecture • Key design requirement – eliminate any per-web-server configuration. • No service-provider specific features or UI • No site specific features or UI • Built the notion of “Pageless” webservers • ASP.NET and markup built dynamically from component model • Web Services used to create design studio • Any request for any site – automatically • Caching architecture critical for performance

  9. Sitemasher Component Architecture • Self-similar component architecture for sites • Sites, URLs • Pages, Page Items, Stylesheets, Style Items • Actions and Events • Database Tables, Columns, Queries • External Data Sources • Lots of small independent blobs that can be manipulated independently

  10. Display Published Page • Code walk through – page request • Request – (http://www.sitename.com/page) • Code walk through – asset request • Request – http://www.sitename.com/image.jpg) • Code walk-through – development studio • Browser - WebService - Component -Returned JSON • Code walk-through • membership providers

  11. Common Themes • In all three of these cases there is a pattern that is worth explaining – because it is fairly core to our system • Minimal component access – not normally an issue on traditional website deployments because they are page based • For Sitemasher, we need to demand load components of a page as required • Caching and SQL Access critical • PROFILE with remote database often to expose bottlenecks

  12. Lessons Learned • HttpRuntime.Cache an enemy • Not distributed – leads to invalid state • Don’t develop against local SQL Servers • Put network distance between application code and database – quick way to locate bottlenecks • Test and debug extensively under freely load balanced local environments • Upgrading your system – that means you are upgrading every one of your customers.

  13. Quark Promote http://quarkpromote.quark.com/ Stephan Friedl Chief Architect Quark, Inc.

  14. Quark, Inc. • Primary Product: Quark XPress • Defined Desktop Publishing Market • Also Has Line of Enterprise Products • Quark Publishing System (QPS) • Quark XPress Server • XML Author • MS Word Plug-In for editing XML

  15. Quark Promote • New Service for SMB Market • Allows users to create high quality marketing collateral from professionally designed templates • Professional printing provided by mail –or- through a network of neighborhood print partners • Composed of 4 Principal Components • Content: Hundreds of professionally designed templates • Website: Allows browsing of template content • Lightweight Design Tool: .NET Application for Template customization • Back Office Services: Catalog mgmt, billing, fulfillment

  16. Quark Promote demo Stephan Friedl Chief Architect Quark, Inc.

  17. Initial Promote Architecture

  18. Business Opportunity: Multi-Tenancy • During discussions with print partners, a number expressed great interest in white labeling Promote for their business • Engineering challenge to support business development with a Multi-Tenant solution • Extensive branding • Solid data partitioning • Cost-effective development , QA and hosting • We examined a number of cloud platforms and Azure was the obvious business enabler

  19. Multi-Tenancy Model • ‘Hybrid’ Multi-Tenant model • Single-Instance, shared Core Services • Utilize Azure compute elasticity to manage loading • DB Partitioned along tenant boundaries • Utilize separate SQL Azure instances per tenant • Logical separation of all tenant transactional data • Separate ASP .NET web site per tenant • Maximal branding and customization per tenant • Combination of divide-the-cloud and grow-in-the-cloud multi-tenancy models

  20. Architectural Considerations • Why this model? • Primarily Cost Driven in Several Dimensions • Ongoing development/QA/management cost containment • Single-instance core services; multi-instance DB • No changes required to DB schema • Minor changes to Core Services • No changes to any SQL statements or ORM bindings • ‘Defensive Design’ - risk of accidental disclosure of one tenant’s data to a second is minimized • Minimizes scope of testing for coupling between tenants • Multi-instance tenant websites permit ‘gratuitous flexibility’ in branding and integration to tenant’s IT • Changes to one tenant website will not impact others • Modifications to carved-off deployments could be handled by SIs or a partner’s IT staff

  21. Implementation • Speed to market without impacting main-line development was critical • Design choice was to use a custom SOAP header to transmit tenant ID • Inject an tenant ID into custom SOAP header • Extract tenant ID in services, store in TSS • DB connection factory returns tenant specific SQL Azure connection • Required about 1 engineer week

  22. Slide for Developer’s Software Code • Show Thread-Local Request Context Object • Show WCF Override for Org ID Injection custom HTTP/SOAP Header • Show WCF Override to Get Org ID from Header • Show DB Connection Factory

  23. Multi-Tenant Promote on Azure

  24. Multi-Tenant Quark Promote demo Stephan Friedl Chief Architect Quark, Inc.

  25. Next Steps • Replace ASP .NET Membership with .NET Services Access Control • Refactor some database code to reduce number of SQL selects issued • Create a solution specific monitoring and management console • Utilize Azure Service Management API and monitoring APIs

  26. Lessons Learned • Designing and implementing with cutting-edge .NET frameworks pays big dividends • Makes transition to Azure very, very smooth • Start using WCF now to avoid headaches later • Be prepared for some SQL Azure tuning • Existing schema support is very good, but not complete • SQL Azure is a shared, hosted DB environment • Slightly different performance profile than standard SQL Server • Expect slightly higher latency per DB operation • SQL Azure ‘Slowness’ could be many small queries in code • Tooling is still maturing • Expect to have a lot of trace logging in your app

  27. Conclusion • Azure is an excellent fit, economically and operationally for Quark’s new service • High availability is baked into the platform • Our initial port to the Azure environment required only 8 engineer-weeks • Platform and tooling maturity will drive this effort down • Azure Platform is a key enabler for multi-tenancy in our application • Inexpensive, easily provisioned DB instances • Elastic compute services consumption • Easily deployed web roles for isolated tenant web sites

  28. YOUR FEEDBACK IS IMPORTANT TO US! Please fill out session evaluation forms online at MicrosoftPDC.com

  29. Learn More On Channel 9 • Expand your PDC experience through Channel 9 • Explore videos, hands-on labs, sample code and demos through the new Channel 9 training courses channel9.msdn.com/learn Built by Developers for Developers….

  30. SVC33 Questions? Ben Riga benriga@microsoft.com Phil Calvin CTO Sitemasher Corporation Stephan Friedl Chief Architect Quark, Inc.

More Related