Windows Live represents a set of client software products and online services from Microsoft that allows users to connect and share information with friends online. This offering includes Windows Live Spaces, which is a Web-based blogging and media-sharing service that allows users to publish and share blogs, photos, and other types of online media through a highly customizable Web interface. Launched in 2004 under the MSN brand, Windows Live Spaces is delivered today to more than 100 million users[2] worldwide in more than 35 languages. The key features of the service include a personalized blog, photo and file sharing, and other features for publishing content.
Similar to Windows Live Hotmail, Spaces is divided into multiple architectural components, including but not limited to the user-facing front-end Web services, back-end user data storage, and authorization and user management storage. These components are large, extremely complex, and shared across multiple other Windows Live services. Once deployed, the size of the Web front-end subsystems alone is more than 900 MB, almost all of which is developed in managed code.
Suffice it to say that, based on the size and complexity of the service, Windows Live Spaces is an application that requires a high degree of engineering rigor to manage effectively. There are numerous moving parts within the application, variations in business logic by market, complex infrastructure dependencies that change by server environment, and many feature-level dependencies on other products and services. As with any dynamic service on the Web, many of these variables can change—and often do. Certain types of changes, such as enabling a new feature in a specific market, can happen fairly often, while others like infrastructure changes may happen less frequently. In either case, if the application is not designed properly, even minor changes can require a build, deployment, and broad regression testing to ensure quality remains high. It would be unrealistic to expect any team to be able to quickly deploy simple changes to a service of this magnitude when the install footprint is so large and the infrastructure so complex without significant engineering effort.
The team has embraced the challenges of complex business logic, cross-team dependencies, and frequent rate of change, and it has invested in a design that leveraged the use of metadata to enable dynamic control over many aspects of the application. The team believed its objectives for managing dynamic updates to the service should be twofold.
This includes ensuring that metadata is completely separated from the code, and features are largely configuration driven. This would allow the team to tweak the logic dynamically when required without recompiling the code or incurring a large regression testing effort. Additionally, this would also allow for increased control over the quality of the application, while subsequently improving the team’s ability to be responsive to change.
This includes ensuring that getting dynamic updates to the live production site would happen quickly and without a high degree of risk or costly operations work. Building upon the previous objective of making features configuration driven, investing in a system that would allow each configuration file to be managed and deployed reliably across all servers within minutes, would both minimize required operational effort and maximize service management agility.
When reduced to practice, the team was able to accomplish both goals very successfully. For starters, many features are controlled by configuration information using a combination of .NET configuration and simple XML files. This investment has proved to be quite effective in providing very granular levels of control over business logic, features, component dependencies, and deployment logic. This level of control has allowed the team to be more responsive to changes and less burdened by broad regression testing when changes are made to the application via the metadata. Certain classes of feature changes are possible anytime without recompiling the application code. This has increased the overall ability of the application to adapt to dynamic changes in the business, without incurring high cost of engineering.
To address the second goal of enabling dynamic updates to configuration information, the team implemented a system that provides the ability to make site-wide configuration changes. This system would allow the team to execute the changes and deploy them to hundreds of servers, across multiple geographic locations, within minutes. Previously, despite the best engineering efforts, deploying simple configuration changes to the live site would take hours to implement across multiple data centers and hundreds of servers. Even with scripted deployment processes, engineers were prone to making errors, and the risk was high that users could be negatively affected by a change gone awry. This automated system realized almost immediate return on investment as its reliability, speed of deployment, and enforcement of change management rules increased the reliability of configuration deployment while reducing the risk and cost of maintaining the application.
Since implementing the combination of the metaprogramming design practice in conjunction with site-wide configuration management, the Windows Live Spaces team has been able to increase the overall quality and manageability of the various components of the service. This success can be largely attributed to the abstraction of metadata from code and the use of configuration files to drive and govern feature behavior. In and of itself, this practice is a success, but coupling it with the dynamic management system further increased the application’s adaptability to change and the team’s ability to respond in kind. This implementation of metadata within a managed code application is a true testament to the value of this design best practice, but it also highlights the capabilities of managing configuration data provided within the .NET Framework.