This project is read-only.


The Windows Azure Accelerators Project abstracts the common resource provisioning and configuration requirements of applications as independent XML definitions. It is an engine which orchestrates the startup, runtime and tear-down of applications hosted on the Windows Azure platform.

Accelerators Documentation

Getting Started Guide

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Windows Azure deployments of Umbraco using pre-configured virtual hard drive (cloud-drive) images. Enables the migration from on-premise to the cloud of application images, accelerator solution engine and associated service configurations. Provides for the migration of local Microsoft SQL Server or SQL Express database schema and content to SQL Azure; including the creation of accounts and logins necessary to enable, set or reset connetivty between the hosted service and SQL azure database.

A full working reference example of Umbraco as an image, with a corresponding exported SQL schema is included. To get started, unzip the package, update the ServiceConfiguration.cscfg with settings for your Azure services, and then run the SetupUmbraco.bat file.

For more information about where to source the settings, and an overall view of what actions are automated, please see the rapid deployment diagram and checklist files. (Also included in the package download.)

Umbraco Rapid Deployment: Diagram

Umbraco Rapid Deployment: Checklist

Zero-Code Cloud Migrations

The Azure Accelerator engine provides for the graceful migration of Windows Platform services to the Windows Azure cloud.  Offloading legacy and non-core applications and services, from in-house servers and datacenters, in a zero-touch, application-agnostic set of solutions applied using application and service specific XML definitions.  Once a solution is implemented for a given scenario (eg. mounting drives, changing app pipleine, add PHP to IIS, etc) it can thereafter be leveraged by any service or application which may require it.  

Applications and services are not limited to web sites, or single self-contained services.  The accelerator provides for the deployment complexities and application inter-dependencies which are common, and are often requirements, for the platform migration to be successful.  The engine provides for the defintion of applications, provisioning of platform services, and the further specification of those applications and their inter-dependencies on other services or plaform resources being started by the Accelerator.  The XML definitions for any application may be refined and split to accomodate differences amongst application versions.  (The Umbraco solution leverages two separate application definitions--one for each major legacy version--with the only notable, yet critical, difference being their HWC application pipeline requirements).

The Accelerator application XML definitions are composable and inheritable.  Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance).  Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc.,   Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration.  These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.).  The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers.  The runtime is deterministic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML.   Code once, use and reuse everywhere.  

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Last edited Jan 18, 2011 at 11:18 PM by ryanmar, version 19