Michel Baladi on software

After a six and a half year career at Microsoft, first as a principal consultant in Microsoft Consulting Services and later as Architect and Technical Lead in the EMEA Microsoft Innovation Centre (MIC) in Denmark, it is time fo me to move on.

Lately I have been working almost exclusively with innovation and software as a service (SaaS, and now it's time for me to stand on my own legs and practice what I hav been preaching. As of April 1st I will be doing free-lance consulting (mainly SaaS related) and also go back to my roots by starting a SaaS ISV with a couple of friends.

From April 1st, my blog will live at http://blog.baladisoftware.net and my web site will be living at http://www.baladisoftware.net 

I'll talk about the remaining two sceanrios in the SHP from there...

m_

Sitecore's solutions architect has posted a series of excellent articles on the joint project we did. Have a look at Lars's view on his blog on

• what it takes for an ISV to move in to SaaS
• what an ISV expects from a SaaS Hosting Platform (SHP)
• how Federation can enable single sign-on across multiple SaaS applications as well as across a mix of on-premise and SaaS applications
• and more...

Scenario #4: Order fulfillment and order management in the store front and provisioning for new application tenants (subscribe)

When & who?
Once there’s something in the catalog to sell, the store front companies expose public facing order fulfillment web site(s). These sites are used by potential application tenants to browse plans, options, price and eventually sign-up for plan or “try-before-you-buy” offer.

How?
The plans that were created in the catalog in the previous scenario are queried using a call to the catalog service and the result is displayed on a customer facing web site. Using a sign-up wizard, the potential application tenant can then select and deselect options and the system keeps track of dependencies as well as what parameters the user must supply for each selected software item. Example: if the potential application tenant selects the dental booking module priced by number of dentist, the order fulfillment wizard must ask for the number of dentists, know that this is a numeric and validate user input agains possible ranges (the knowledge of these parameters came from the ISV provided application manifest via the platform service). In the final stages of the sign-up wizard, the potential application tenant is asked to supply company information, billing information etc and submit the order.

The order fulfillment wizard sends customer and order data to CRM/ERP and asks platform service to initiate an application tenant provisioning sequence supplying the data from the wizard. This provisioning sequence was designed and the scripts where verified and approved during design-time (as described in scenario #2 in a previous post). Now, at run-time, the platform service does some book keeping and asks the provisioning service to execute:

Image 1: Order fulfillment and per application tenant provisioning

Looking at it in terms of call sequences, order fulfillment and per application tenant provisioning looks like this: 

Image 2: Sequence diagram for order fulfillment and per application tenant provisioning

Scenario #3: Managing the re-sellers hosting plans in the store front to include software items from the new application

When & who?
There may be multiple store fronts offering the same underlying software items for sale in different packages and price models. Each store front has a business/sales manager responsible for composing plans/packages using software items and services from one or more sources, setting price per time period for eh plan etc.

How?
Each store front has its own catalog implemented of any technology the store front happens to chose. In our store front implementation, the catalog is a service implemented using Windows Communication Service (WCF), but other store fronts may choose to implement their catalog on top of an ERP system. Our catalog stores information about what software items are available, their dependencies and their license schemes. This data is read from the platform service’s inventory and the underlying platform/application manifests. In addition to software items, the catalog service also stores information about services, such as e-mail support, phone support, domain registration etc. The catalog service is then able to keep track of these software items and services in any possible combination in a plan with an associated time period and metering info (more on this in a later post about metering and billing). As an example the store front could offer a “Small business” plan that look like this:

·         two software items with a fixed fee per module and month from ISV A

·         three software items from ISV B with a fee per “application object” (i.e. books in a book store application, pages in a CMS application, number of hair dressers in a salon application etc)

·         domain registration/renewal

·         e-mail support

·         12 month at X/month or 24 month as Y/month

The 1^st stab at a simple catalog data model we implemented in our sample looks as follows:

Image 1: Catalog data model

The business/sales manager at the store front works with one plan at time, but the plan may contain software items from multiple vendors potentially running on different platforms located in different hosters data centers. Our architecture allows for these complex scenarios by

·         Clearly separating the three roles (store front, ISV/platform tenant and platform provider)

·         Having a service interface through which these three roles can interact and

·         Having the catalog automatically refresh its software items from the platform as they are being used during plan management.

With this design, the three roles can be played by any number of business entities (two store fronts for the same applications on the same platform, one store front for two applications on two different platforms etc). However, to make life keep it simple and comprehensible in the short lab, we chose to use a simple but realistic (remember there’s a real hoster, a real re-seller and a real ISV with a concrete business problem participating in this lab) setup:

·         one store front re-selling

·         two applications from two different ISVs (or platform tenants) running on

·         two different platforms provided by

·         one platform provider (i.e. using one platform service)

as shown in the illustration below:

Image 2: Catalog & plan management

Looking at it in terms of call sequences, catalog and plan management looks like this:

Image 3: Sequence diagram for catalog & plan management

The first call is there because we discussed the possibility of having a product manager at the ISV side maintain an XML doc (using some fancy product configuration tool obviously) with the suggested packaging (i.e. “Standard” includes these 50 modules with the usage limits and “enterprise” includes these 200 modules with no usage limits etc). We thought it might be useful if the applications are complex and if the re-seller mostly follows the suggested plans, but decided to skip implementing it for now…

Next step
With the current SaaS maturity level, SaaS ISVs start-ups will pick up the phone and call the hosters sales department. However I believe that, in a not so distant future, SaaS ISVa wants to shop for hosters just as a SaaS consumer shops for applications. I also believe that many start-ups want to start small & inexpensive and the upgrade to “premium” platform services later. Therefore I believe SaaS hosters should package their platform in to “subscribe per year” type plans just like applications – i .e. offering a “bronze”, “silver” and “gold” SaaS hosting platform plan as the following example:

·         Bronze: Hosting on a shared platform with data on a shared stand alone SQL server

·         Silver: Two load balanced web servers in virtual machines and data on a clustered SQL server with an entry level SAN with service level of X.

·         Gold:  Two or more load balanced web servers in physical machines, published through two load balanced application proxies and data on a clustered SQL server with and top notch geo-dispersed SAN with service level of X*2.

Scenario #1: Defining the platform run-time instances and its capabilities

Why?
Describing and documenting a platform is always a good thing to do, but by storing it in a machine readable format opens up a new set of opportunities such as automation of initial application provisioning, provisioning application tenants as they subscribe and ongoing operations – all in order to save time and reduce cost.

When?
Defining the platform can be done by the hoster up-front to describe what their standard shared SaaS platform looks like. However, in some cases this is done after there’s a business agreement in place with an ISV to start hosting and/or re-selling the new application.

Who?
This work is typically done by the operations team at the hoster and the tools they most commonly use is scripting for operations/management and a diagramming tool for documentation.

How?
The Dynamic Systems Initiative (DSI) is a commitment from Microsoft and its partners to do all of the above and more. The System Definition Model (SDM) is a key technology component of the DSI product roadmap that provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems.

The first implementation waves of the DSI vision have already surfaced in products like Visual Studio 2005 and more will come in next version of Windows server code named “Longhorn” and in Systems Center. However, for this project I needed to use released products only, appeal to the target group and solve a concrete problem within a very short time frame. Therefore the choice of “modeling tool” for the platform run-time instances fell on Visio 2003. By annotating the Visio diagram with the standard basic machine information (name, IP-address etc) plus machine/network capabilities (such as fault tolerance) and saving the diagram to an XML file (Visio uses the VDX file extension for this), a simple “Platform Manifest” was implemented.

Image 1: Platform manifest for the shared SaaS platform included in the hypothetical “Silver platform plan”

Then we implemented a Visio XML parser that was capable of recognizing the most basic shapes and extract information about these network nodes and store it in to the platform service for use in the other scenarios. Using an XSLT, this model of the application run-time instance could be converted to a logical data centre diagram for Visual Studio 2005 (LDD file) that the hoster could give the ISVs for them to verify their architecture against a hosters standard platform offering.

In the future, post “Longhorn”, this should obviously all be SDM models in the SDM persistent store. See Understanding SDM and its Practical Application in 2006 to 2008 for more details on the DSI road map.

Scenario #2: Defining the application meta-data and mapping the platform tenant to a platform run-time instance

Why?
To host a SaaS application, the hoster needs to know a walth of technical details of how to install and operate it such as machine requirements, support for platform level authentication (such as federation), performance couters, management rules etc.

To aggregate and re-sell the application, the store front needs to know how it can be packaged (i.e. dependencies between software items), how to meter usage in order to do usage based billing, what questions each new application tenant need to answer for each item in the package etc.

The ISV, hoster and re-seller could share all this knowledge by having meetings, sharing diagrams and documents etc, but by capturing all of this meta-data in a machine readable format –using a common schema across all SaaS ISVs – allows for automation and both ISV and hoster saves time and reduces cost.

When, who and how?
Most of the work involved in creating the platform and application manifests is done in design-time. On the ISV side it’s done by a developer using Visual Studio and XML Schema.

The idea of the application manifest is that the ISV describes requirements (I need a load balanced farm of web servers and no server affinity, I’m claims-aware etc.) and the hoster assigns resources by filling out tenant parameters (you get web servers web01 and web02, the app pool account will be X and I’ll use my BIG-IP box to load balance using simple round robin etc). The hoster does this assignment using a platform manifest and a platform tenant parameters. With this information, the platform run-time service can automate most of the tasks as described below.

The application manifest is structured as a hierarchical tree of software items. Each software item has information about

·         Name/Id

·         How to start/stop (i.e. gracefully tell the app something is about to happen)

·         How to provisioning/de-provisioning throughout the life cycle (at initial install, per application tenant subscribe/unsubscribe, at application upgrades and final application de-provisioning)

o   Provisioning is split up in common task Web, DNS, Database, Directory etc

o   Application manifest specify run-time parameters that order fulfillment can use to ask the new application tenant for input at signup (i.e. ask user for a delegated admin user for the main software item and ask for number of mail boxes for the mail module)

o   We cut corners by only implementing support for Microsoft products such as MS IIS, MS DNS, MS SQL, MS AD (ignoring other vendors but hey, we had three weeks not three years)

·         Dependencies other than parent nodes (i.e. dependencies on siblings)

·         Prerequisites (such as IIS, .NET, ADAM etc)

·         Platform requirements (sticky sessions, federation etc)

We looked at implementing the application manifest with the application designer in Visual Studio 2005, but too many aspects of the manifest was missing so we ended up inventing a custom schema. The schema we implemented is available here. Short term, this could be generalized to include other vendors and federation claim mapping tasks. In an ideal future, post “Orcas” or post “Hawaii”, the application manifest schema should obviously evolve into an industry standard SDM/CML model living in the SDM store and be modeled using some cool new modeling tool in Visual Studio yet to be invented… Again, see Understanding SDM and its Practical Application in 2006 to 2008 for more details on the DSI road map.

With the application manifest at hand, the hoster’s IT operations staff can now map ISV applications (or platform tenants) onto specific platforms and generate install templates and management packs using a set of PowerShell scripts.

Once the IT operations staff has inspected & approved the generated files, the initial provisioning of the application onto selected physical platform(s) and import of a management pack for System Center is done run-time.

The following two diagrams show the entire process for this and the previous scenario:

Image 1: New platform tenant and initial application provisioning

Image 2: Sequence diagram new platform tenant and initial application provisioning

The platform service was implemented as a Windows Communication Foundation Service (WCF) hosted in Internet Information Services v6 (IIS6).

To import platform and application manifests and map platform tenants onto platforms we implemented a set of PowerShell CmdLets such as, Get-PlatformTenants, Get-Platform, Add-PlatformManifest etc.

And now the real magic starts. The Generate-ProvisioningTemplates CmdLet in the sequence diagram above merges platform manifest, application manifest and platform tenant parameters into a two provisioning templates – one for initial installation and one for each application tenant subscribe/unsubscribe. These templates are XML documents with a set of install tasks that an administrator can inspect and optionally edit. This stage marks the end of the design-time phase.

Finally, as the first step in the run-time phase, the Provision-PlatformTenant, executes initial provisioning of the application. For Microsoft Provisioning System (MPS) this would mean that the platform service would perform an XSLT to MPS format and pass it to the MPS engine for execution. Our Light Weight Provisioning System (LPS) is a WCF service hosted in IIS that receives an “install task document”.

Before sending the install tasks to MPS, LPS etc, the platform service have expanded all parameters (i.e. “I need a web site on all web servers in the platform instance I’m running on” is now expanded to “create a web site on web01 and do the same on web02”).

LPS converts the install tasks to a set of PowerShell CmdLets that then gets executed inside Windows Workflow (WF). WF allows us to implement long running tasks such as sending an email to a domain registrar and wait for an answer. Using PowerShell CmdLets and logging all actions allow the hosters operations staff, to inspect and optionally re-run tasks. The CmdLets that we implemented include common task for Microsoft products such as IIS6, AD/ADAM, SQL, DNS etc. In a production environment we would also nee CmdLets for the load balancer, other DNS implementations etc.

Spring is here and the sun is shining. As I live close to the beautiful Roskilde Fjord, I took a walk by the water front. I figured catching some rays wouldn’t be that harmful and maybe, just maybe, my eyes would revert to an oval shape again after a couple of lengthy screen sessions. By the harbor, people were working on getting their boats ready to go into the water. However, three weeks ago when we were doing the SHP lab, it was a snow storm here :-o

This is what the Microsoft Innovation Centre lab looks like with almost ½ meter of snow in front of the main entrance:

Multiple store fronts

Since the ISV may chose to sell directly and/or through a hoster and/or an aggregator, we introduced the term “store front”. The store front is one or more places from which a potential application tenant can subscribe to the application. An ISV may choose to have a store front on its web page as well as selling some edition of the application through a re-sellers store front.

N-tierd multi tenancy 

To fully leverage the economy of scale, the hardware infrastructure and many of the platform services in a given hosting infrastructure may be shared between multiple ISVs.

From an application hosting provider’s perspective, there may be many instances of these application architectures, one for each application, running simultaneously. These applications may come from the same or different ISVs, sharing services such as the security services. So from this viewpoint, the hosting infrastructure is multi-tenant with multiple ISVs (“platform tenants”) sharing hardware and services.

One level up in the SaaS ecosystem, at the ISV’s or application providers’ viewpoint, each application can have multiple tenants (“application tenants”) since the ISV will sell his application services to multiple customers/users (jointly referred to as “consumers”).

An ISV that chooses to self-host and to build the shared services capability themselves will not have to be concerned with multi-tenancy at the hosting infrastructure level. However, this series of blog post will focus on the requirements and techniques for building the multi-layered model and therefore cover multi-tenancy at the application level as well as multi-tenancy at the hosting infrastructure level.

Two platform tenants or two application tenants may never see each other’s private configuration, but there may be shared configuration at higher levels.

·         As an example at the hosting infrastructure level, all platform tenants are configured to use the centralized authentication model, except the platform tenants in a specific region that use the decentralized model trusting a local Security Token Service (STS).

·         As an example on the application level, all application tenants in a SaaS Point-of-Sale system have a the “refund approval limit” for the “store manager” role setting set to €1000 for all stores in the Europe, except for the stores in France where the same setting may be €1500.

Actors/roles in this play 

In this series of blog post, we have used a couple of fictitious companies to illustrate the SaaS ecosystem:

·         A fictitious SaaS application hosting provider named “Northwind” providing two platform run-time instances and a set of shared services. One run-time instance is an entry level platform with a single web server and a single database server. The other run-time instance has a much higher service level and uses load balanced web servers and clustered SQL servers.

·         Two fictitious ISVs (or platform tenants) called “Litware” and “AdvetureWorks”. Both ISVs have chosen to use external hosting and signed up for Northwind’s SaaS platform plans. Litware’s application is only available on the entry level platform but AdventureWorks is available on both platforms through a low price “basic” plan and a high price “premium” plan.

·         The architecture of the SHP allows multiple store fronts and Litware have chosen to sell both directly through their own web site as well as through Northwind.

·         Two fictitious consumers (or application tenants) have subscribed to Litware’s application. These application tenants are “Contoso” and “Fabrikam music school”

Image: The SaaS ecosystem as applied to this series of blog posts

In-house vs. external hosting

An ISV that wish to start offering an application throug a SaaS delivery model could choose to move down the stack and host the application in-house (sometimes referred to as “self-host”), requiring the ISV learn how efficiently and securely operate a data centre for thousands of application tenants. A friend of mine is the CEO of an ISV that has sold 80,000 copies of an application as on-premise installation to customers with an average of 2 users. The company is used to send upgrade CDs out and do support to end-users at small businesses. Moving to a SaaS delivery model their skills would have to shift to operating a data centre 24*7 with 160,000 concurrent users and application tenants constantly subscribing an unsubscribing to services. These are obviously two very different skills sets.

Self-host could mean to actually have the data-centre in-house or to have a bunch of dedicated servers located in the data centre of a “classic” hoster who provides very basic services (sometimes referred to as “ping, power & pipe”).

Another option is outsource the hosting to a SaaS hosting provider that offers a complete SHP-for-rent and provide services at a higher level (i.e. providing an application level SLA as opposed to machine or network level SLA).

Some ISVs may even start by buying these services in the start-up phase and then bring these services in-house as they grow their business. As an example a small ISV startup may want to host its application with an application hosting provider in a shared environment (shared load balanced web servers, shared security services, shared database cluster etc). As the ISV grows in size or requirements for isolation get higher, the ISV may move to dedicated hardware within the same data centre or even choose to move the hosting in-house.

Recently we have also seen examples where ISVs that have chosen the in-house hosting model, quickly getting the required knowledge, people and data centre by acquiring a hosting provider.

Build or buy the shared services 

The SHP is both an application run-time platform as well as a set of shared services. For the shared services, the ISV has a variation of the classical “build vs. buy” choice. In the SaaS world, “buy” really means “use/rent with a SLA”. This means that the ISV has a lot of options:

·         build all the shared services (with self-host or outsourced hosting)

·         “buy” the shared services from the same hosting provider that provides the application run-time platform

·         “buy” some of the shared services from the same hosting provider that provides the application run-time platform (such as monitoring) and other services (such as catalog, order fulfillment and billing) from a re-seller or aggregator

·         “buy” some of the shared services from external service providers (example; one SaaS application could send usage data to another SaaS application that implements a billing service).

·         Any combination of the above

Reasons for building the shared sources in-house include:

·         Better and more tailored BI on customer profiles, usage patterns, retention, targeting

·         Higher level of control with features and service level iH

·         Complex tenant management features – multiple levels of tenant relationship (resellers etc)

·         Desire to keep customer and business information away from third parties

·         More cost effective to build and operate this capability themselves

·         Regulatory requirements that cannot be satisfied by third party hosters

Reasons to using shared services from of the application hoster or other SaaS ISVs:

·         Allows to focus on application features to get to the market faster

·         Need market presence and visibility that SaaS aggregators can provide

·         More cost effective to outsource this capability

There are a couple of trade-offs involved in this decision. One tradeoff is about choosing between sharing and isolating. Should the services be shared between multiple ISVs or should it be isolated for a single ISV.

The second is about choosing between developing the shared services in-house and buying, or renting, the shared services.

These trade-offs are never black or white, but instead, it’s more of a continuum, with many variations that are possible between the two extremes.

As an example of sharing vs. isolating, an ISV may choose to share the security services, but not the data services. As an example of in-house vs. outsourced shared services, an ISV may choose to develop the operation support system in-house, use someone else’s billing system.

From an application architecture perspective it’s therefore important to abstract the underlying implementation and location of the service provider away behind a stable contract/interface in order to support changing business requirements.