Windows Azure Lessons Learned: Quest Software
- Posted: Jan 05, 2010 at 5:24PM
- 5,713 views
Right click “Save as…”
In this episode of Azure Lessons Learned I chat with Dmitry Sotnikov, new product research manager with Quest Software. Quest, as you probably know, is a huge global ISV focused primarily on Systems Management software.
Quest is an early adopter of the Windows Azure platform. They’ve been working on a new offering for their various management business. They’ve built out an extensive services framework as well as a few service offerings on that framework.
Quest has hundreds of solutions for the enterprise. These are your typical on-premises that would normally require hardware and people to install and maintain those solutions. The Quest OnDemand project Dmitry is working would extend those offerings to the small and medium business by making many of the solutions available as subscription services. The first 3 offerings are Recovery Manager OnDemand for Active Directory, InTrust OnDemand event log management, and Site Administrator Reports OnDemand for SharePoint. These are now available in beta.
Dmitry walks us through the experience of setting up Recovery Manager OnDemand to provide backup and recovery of AD. The solution running in Windows Azure does most of the work in the cloud while sending requests to the local infrastructure via agents that are running locally. There is no need to set up servers or install anything beyond that simple local agent service.
Dmitry was very open about the process they went through to adapt their existing solutions to this new subscription model. He mentions that they were able to re-use about 50% of the code for one of their solutions (Recovery Manager).
Since Quest OnDemand is meant to be on solution with many different component offerings it was important that there be a consistent framework across all those offerings (including login authentication/access control, portal, subscription/payment/billing). Even within Quest I think they were a little surprised as to how fast they could port applications over once that framework was in place and available to re-use.
Dmitry also goes into detail about the architecture they have built out for this set of services including the portal, Windows Identity Foundation (formerly Geneva) Security Token Service (STS), and the individual services. He also is very open about what they learned along the way of this development. It’s interesting to note that the bulk of the Quest products are on-premises so although they had many large installations there had never been a call for super-scalable super-secure multi-customer/multi-tenant deployments like the one required by Quest OnDemand.
I love that Windows Azure played such a big role in helping Quest to adapt the way that they do business.
Have a look at the Quest OnDemand Service here: