Windows Azure SQL Database Marketplace
Editor’s Note: Today’s post, written by Icertis CTO Monish Darda, describes how the company uses Windows Azure and SharePoint Online to provide scalable contract management and workflow services to its customers.
Icertis Contract Lifecycle Management (CLM) helps enterprises author, run, support and report on a contract’s lifecycle. Contracts and their associated templates are highly governed entities and participate in complex business processes that can run for months or even years.
We had some interesting requirements – not unique in themselves, but as a combination, something we knew was going to be an interesting challenge to take on. Our Flexible Deployment architecture had to support hybrid and pure SharePoint Online and Windows Azure deployments. Windows Azure was a foregone decision – our customers wanted an enterprise product on Microsoft’s cloud that could scale with their needs and be cost-effective to run. And Icertis does nothing else but build enterprise solutions on Microsoft’s cloud! Icertis CLM is an enterprise product built for Windows Azure from the ground up.
The deployment choices meant that we needed parity between SharePoint declarative workflows (SharePoint Designer lets business users design workflows in a declarative way, without having to write code) and workflows deployed on Windows Azure. Windows Workflow Foundation running on Windows Azure looked to be the obvious choice. The million dollar question was, how well would things run for our complex requirements? The key requirements for the workflow service in Windows Azure were:
We started by abstracting the workflow service on Windows Azure. This way, we could switch to an on-premises workflow engine later if necessary, and also leave the door open for plugging in a hosted workflow service in the future.
Contract Lifecycle Workflows are customized and persisted as XAML files in a SQL Azure management and metadata database. Using the Windows Workflow Foundation (WF) infrastructure, workflows are loaded (hydrated) and executed programmatically based on user action or a system event. A custom workflow host runs in a Worker Role and uses SQL Azure as its persistence store. Since running workflow instances are persisted, the Worker Role executing the workflows can scale out incrementally. Increased concurrent workflow instances can be handled by increasing the number of Worker Role instances at runtime, thus providing elasticity in a crucial compute-intensive component.
We wrote our workflows as state machine workflows – an ideal metaphor for a contract’s lifecycle. Custom activities provided the power and simplicity of declaratively defining a contract’s lifecycle to business users, who could quickly relate to the state machine paradigm.
Well, the thing worked like a charm! We could quickly deploy and test workflows that we thought would be very complex to implement. Some interesting monitoring code within the workflow service allowed the service to scale dynamically based on the execution characteristics of workflows that were currently running. Turns out, it made things less expensive to run. We could demonstrate dynamic scaling under specific contract events (for example, end of the month, beginning of the year and other calendar events that can trigger contract states like expiry and renewal in the thousands).
Compute instance selection for the workflow service turned out to be an interesting exercise. The workflow service is compute- and memory-intensive so we tried using different instance sizes with a varying workload. As workload changes (a mix of contract types represents a varying workload), Medium instances provided more flexibility (and thus less cost) in scaling compared to Large and Extra Large instances. This exercise effectively brought home the fact that instance size selection affects pricing, and the type of workload needs to be matched not only to the number of instances, but also to instance size. For this workload, medium (2-core, 3.5GB) compute instances worked best for the workflow service, and provided optimum scaling costs.
We now had a scalable workflow service at our disposal, with the SharePoint team also able to leverage the service to run some integration workflows that were impossible to run in the sandboxed environment of SharePoint Online. Sure, we had our share of issues, especially around distributed transactions (not supported in SQL Azure yet, and an interesting subject I intend to take up another day), but nothing that we could not work around. Something that we had anticipated to take months was up and running in weeks. This is what makes Windows Azure interesting: a bit of out-of-the-box thinking can produce huge returns.
Here are some things we did that helped the service scale and be efficient:
The key points to note are:
All in all, it was a great and rewarding experience. And it did reinforce our belief that Windows Azure has tremendous potential for enterprise applications that has not been exploited yet. It is good to be a successful early adopter (we launched Icertis CLM world-wide this month – see here for the news release), and we look forward to sharing more real-world experiences with our customers as we continue to uncover the potential of Windows Azure.