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.
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.