Editor’s Note: Today’s post, written by Minitab Enterprise Web Architect Michael Yeaney, describes how the company uses Windows Azure and continuous integration to rapidly build analytics solutions for its customers.

Minitab Inc. is the leading provider of quality improvement software. Minitab Statistical Software – our flagship product – has been used to implement virtually every major Six Sigma initiative around the world. Quality Trainer by Minitab teaches you quality improvement statistics and how to analyze your data with Minitab.  Quality Companion by Minitab supports and guides Lean Six Sigma teams through projects from start to finish. Distinguished companies that rely on Minitab products and services to help them achieve world-class quality include BMW, General Electric, DuPont, Boeing, Nike, Procter & Gamble and the leading Six Sigma Consultants.

Overview

Our Qeystone product suite is a project portfolio management system for the Lean Six Sigma (LSS) market built on Windows Azure.  Comprised of several discrete applications, Qeystone takes full advantage of the available features of Windows Azure in order to deliver a powerful, consolidated analytics platform for LSS practitioners.  Project data is gathered from LSS project team members through various desktop interfaces, which push their data into the Qeystone Cloud Services data repository. Once submitted, this data is indexed across multiple dimensions and used to provide analysis and rollup information in a near real-time manner. This information provides up to the minute visibility into all process improvement projects across the customer’s enterprise.

The core components of the Qeystone product suite are:

• Cloud Services:  Web-based HTML/Javascript dashboard used for management of data repositories and rollup/reporting information.  Also provides the core REST management services used by all relying Qeystone products.
• Desktop Tools: Fully customizable information gathering and data visualization tools specific to the LSS market (Value-Stream maps, Process maps, etc.). Connects to a Cloud Services deployment (above) for all data needs.
• Web / Mobile: Task-focused interfaces designed for quick information delivery.
• Deployment Management Tools: Specialized tools used for rapid customization, deployment, and management of customer sites. Uses the Qeystone REST management API.
• Licensing Portal: Company-wide Secure Token Service (STS) incorporating licensing controls, subscription management, quotas, etc.  Also provides web-directory functionality for connected applications. Built on top of Windows Identity Foundation (WIF) and WS-Federation standards.

Developing such an extensive suite of products using traditional approaches would normally take months and consume a significant number of human resources. However, using the flexibility and service offering of Windows Azure, we were able to make the applications available extremely fast, (apps were available for preview testing 8 to 12 months).

Qeystone Architecture 

A high-level view of all components involved in the Qeystone product suite is shown below; where appropriate, the Windows Azure services used for each component are called out.

 

The core of the Qeystone product suite is the cloud platform, providing centralized data management for all connected applications.  This platform is comprised of a typical web / queued-worker setup, with several augmented features (see diagram below). The public-facing web roles handle REST API calls from all client applications and manipulate structural metadata about any single particular piece of data. These calls may result in additional deferred commands such as data extraction, indexing, exporting/report generation, which are delivered over Windows Azure Storage Queue instances to one or more available backend compute roles. In addition to monitoring queues for incoming commands, these backend compute nodes also host a set of real-time WCF Analysis Services that allow the web roles to dispatch analysis/roll-up requests issued to them. These two distinct methods of input to backend compute nodes offer a clean separation between system commands and analysis requests.

Cloud Architecture

The Qeystone system was designed for the Windows Azure environment to leverage many independent servers, as opposed to relying on the traditional “big iron” approaches to enterprise data analysis.  All components in the system are designed to run on 1..N compute instances in order to enable rapid and powerful scale-out for customers with large computing needs.  In order to take advantage of this, customer deployments are continuously monitored via Windows Azure Diagnostics from an in-house system, which tracks performance counters data against predetermined thresholds.  If a particular customer is exceeding these thresholds, alerts are sent out to our support engineers to evaluate whether the customer is able to scale yet stay within current subscription limits.  By leveraging Windows Azure for its elastic scalability, scaling a customer deployment from 6 machines to 24, which normally would have taken weeks or even months, can now be accomplished in minutes providing that the customer subscription allows for the scaling to occur.

Another critical part of the data storage subsystem is the ability to backup and restore in the event of catastrophic system failure, user error, or application error.  By leveraging the management API’s offered by Windows Azure we were able to create a fully automated system that creates daily backups of key data from both SQL Azure and Windows Azure Storage.  These backups are then available for restore operations on an as-needed basis.

The elasticity of Windows Azure has also helped the core product development as well. Designing and building large-scale, multi-instance development and test environments has traditionally been a prohibitive endeavor.  This typically means that bugs due to parallelism and state are not found until late in the development cycles. However, building such a system on Windows Azure enables testing on “real” configurations, allowing difficult issues such as racing, scheduling conflicts, etc., to be flushed out quickly and easily.

Licensing Portal

The License Portal allows trusted applications (such as Qeystone) to completely delegate all handling of user authentication, authorization and claims assignment to a single authority. When a trusted application delegates an identity request to the Licensing Portal, the information contained within the Portal describing the subscription is used to select the appropriate authority for identifying the current user. These authorities could be any SAML/WS-FED compliant service, such as ADFS, OpenID, or the default Minitab identity provider.

Linking this cloud-based identity provider to in-house systems is enabled by the Windows Azure Service Bus, which provides the bi-directional messaging required in order to facilitate these integrations. Leveraging the topic-based access and multicast capabilities of the Service Bus, we are able to send and receive messages between all Qeystone deployments and in-house support systems, allowing the tight integration necessary to drive the Licensing Portal. The power of the Service Bus is the ability to immediately utilize an enterprise-class messaging infrastructure without the overhead of setup, deployment, and updates. This is another excellent example of Windows Azure enabling us to focus on building products instead of supporting infrastructure.

Application Tenancy

Due to the sensitive nature of the information that customers place within the Qeystone system, we decided early on to build and deploy Qeystone Cloud Services as a single-tenant application.  This means that each customer deployment has isolated compute, storage accounts, SQL Azure, and Service Bus instances. While potentially more costly to us from an operations perspective, the additional security associated with the isolated deployments has received positive feedback from our customers, and more closely resembles traditional enterprise software models. A typical deployment scenario may look like the following:

 

Notice that in the above diagram, separate trust boundaries are established for each customer, mitigating the risk of cross-deployment data leaks. These trusts may also extend into the customer site for additional functionality (such as integration with ADFS).

Development Challenges

As with any large-scale product development effort, many cycles are consumed in developing the “mechanics” of the application development life cycle. While the built-in Windows Azure SDK tools provide simple and powerful deployment options for Windows Azure applications, they do not easily accommodate highly controlled / audited deployment environments, for the following reasons:

• Individual developers are able to publish deployments of controlled applications.
• We cannot selectively push builds/branches to various Windows Azure sites for Development, Test, Load-Test, and Regression purposes in a controlled manner (note this is different than the built-in configuration support provided by the Windows Azure Tools for Visual Studio).
• Production deployments do not flow through an audited, human workflow in order to deploy and upgrade only through controlled channels.

Based on these reasons, we developed an in-house custom deployment mechanism that ties together all the key components of the product development pipeline: VS2010, Windows Azure Tooling and SDK, TFS 2010, and CruiseControl.NET.   The following diagram outlines this workflow:

Note that this workflow is triggered automatically when code is checked in (thus driving our CI environment), and optionally by manually triggering the custom build scripts.  These custom scripts allow support engineers to “pick and choose” the exact build, branch, and/or changeset to deploy to one of many Windows Azure accounts we use for product development. Each automated build pulls the selected source branch, builds the product, starts the Windows Azure emulator, and runs through our entire suite of unit tests and automated verifications. Only after a successful test run is a build available for deployment to the selected site.  Leveraging the Service Management API, the build packages are uploaded into the selected Windows Azure account as an active, staged deployment. If this deployment site is an internal account (such as test, regression, etc.), the staging environment is swapped over to production.  However, if the site is a customer account, the VIP swap is not executed, instead leaving that final step to customer support technicians.  As stated above, this manual step directs deployments to customers through controlled channels.

Conclusion

Windows Azure provides many powerful, out-of-the-box features, which rapidly enable SaaS application development at a fraction of the cost and overhead of traditional methods.  In addition, it has removed many technical limitations that would have severely impeded development of a system such as Qeystone.  Instead of struggling with these issues, Minitab is able to focus on delivering unparalleled value to our end-customers at incredible speeds – a venture that would have been nearly impossible without Windows Azure.