In its current version, LitwareHR is focused very much on the challenges an ISV faces while building a SaaS delivered app: multi-tenancy, configurability, etc.

In the last few weeks I've been working on exploring the implications of hosting LitwareHR on a hypothetical hosting platform. The goal was to twofold: identify changes that have to be made in LitwareHR code base to support specific hosting scenarios and explore the interaction points between hoster & ISV.

I've published some of this work already in previous post which focused on Provisioning. As described there, externalizing Provisioning required changes in LitwareHR, but it was pretty straightforward because it was functionality well encapsulated.

But of course Provisioning, as important as it is, is just one aspect. This series of articles will cover what I've found. As usual, any feedback is greatly welcome.

Eventually we hope to publish this content and the collateral generated (code, demos, etc), but realistically that will take some time as we need to invest more on polishing, testing, etc.

So lets start with a first article on the the scenario itself. Who are the actors? What motivates Litware to search for a Hoster as opposed to self-host? what characteristics is Litware looking in a hoster? What attributes are important for them?

 

The Scenario

The Actors in the exercise are:

  • Litware, a SaaS ISV
  • Northwind Hosting (NWH), a SaaS hoster

Litware is searching for a hoster to run and operate their flagship SaaS delivered application (LitwareHR). Litware is a startup ISV that lacks the funding, skills and experience to operate their solution. They want to enter a global market and therefore searching for a hoster with presence in different geographies. Quality is important, so they are also looking at contracting high SLAs.

Other Litware requirements can be summarized as follows:

  • Litware wants a seamless on-boarding process. They want to be up and running in a matter of days, rather than weeks. They want to be able to upload new versions and updates with the certainty that if something goes wrong they can immediately roll-back to previous well-known state.
  • Litware wants a fully automated provisioning system for tenants. They want new potential customers to have a seamless experience to try and buy their app. 
  • Litware wants to bill their customers based on 2 scenarios: on a subscription basis (fixed amount of $/tenant/month) and on a transaction basis (in their case per Resume Submitted). They don't want to create a billing system on their own, because they want to focus resources on enhancing LitwareHR features
  • Foreseeing a dramatic growth, they want the hoster to be able to allocate resources dynamically and transparently to keep their SLAs at agreed levels. They are also expecting the Hoster to help them troubleshoot and diagnose performance issues. 

Litware is willing to make changes into the app to make this happen, increasing the level of compliance of their app to follow the hoster's environment capabilities.

Among different hosters available they have found that Northwind Hosting is a "SaaS" hoster, that goes beyond “power, ping & pipe”, has a good coverage worldwide with datacenters in the principal markets Litware is interested in expending and offers advanced services like:

  • Metering & Billing to tenants on behalf of the ISV
  • Tenant Provisioning engine
  • Identity & Role management
  • Automatic on-boarding with multiple staging environments
  • Application Management & Optimization services including:
    • Exception logging and escalation
    • Customer support
    • Profiling and tracing
    • Automatic capacity management to comply to SLAs

Northwind specializes in hosting applications built with the Microsoft distributed applications technology stack: .NET, ASP.NET, WCF, SQL Server based transactional systems. They offer high availability systems and good coverage for a good price, if the application is built according to certain rules.

Northwind has streamlined their operations for applications that are compliant with a specific model (Figure 1), in which:

  • Applications are made up of sets of Web Sites, Web Services and Databases
  • Web Sites must be implemented in ASP.NET 2.0 and must interact with WCF exposed web services
  • WCF services interact with SQL Server databases
  • WCF services that interact with a user repository using Directory Services (exposed as WS themselves)

 

NWH-HAM

Figure 1: Northwind Hosting - Application Model

 

This might might sound quite restrictive, but NWH is able to offer competitive pricing with high SLAs if the application is built according to this principles. Coincidentally, LitwareHR design is very close to this. (By pure chance of course :-))

However, NWH has some additional requirements and constraints, for example:

  • All .NET assemblies are private to the application (No components should be installed in the GAC)
  • All configuration should be stored in .NET standard files (web.config files)
  • Exception logging and handling should be done with Microsoft Enterprise Library
  • Data Access should be done with Enterprise Library Data Access Application Block
  • Only standard extensions are allowed to Enterprise Library (meaning that extensions should have been done through Microsoft published extensibility points)
  • Enterprise Library binaries will be supplied by NWH

Anything that differs from these rules can be negotiated, but it is guaranteed that for the same SLA, the costs will be higher as illustrated in Figure 2.

SLA-COST-NWH

Figure 2: Cost increase for increased SLA with different levels of compliance 

    

NWH of course, publishes these models and restrictions together with an SDK with APIs to be called for specific services. In its current implementation, NWH publishes an SDK for the following services:

  • Tenant resources provisioning
  • Identity Management (users & roles)

The ISV is required to call these APIs for these features.

Finally, Northwind Hosting requires ISVs to package the application in a predefined way and supply additional information for deployment and operations in an "Application Manifest". Northwind requires this so they can fully automate the on-boarding of a new app. We will call the "stuff" that the ISV hands over to the hoster, the "Hosting Pack". Think of it as an "MSI for hosting".

On next chapters we will drill down on these different pieces in the context of Northwind Hosting and Litware's LitwareHR. What is in the "Hosting Pack"? What does the "Manifest" describe? How is it authored and consumed? How intrusive are Northwind APIs?