Watch a Video About How We Use Windows Azure
For the Microsoft Worldwide Partner Conference we have created a video that shows how time cockpit uses the Windows Azure Platform.
Why we have chosen Windows Azure
You can describe the benefit of Azure for our company with a single word: Focus. Azure allows us to focus on our core business, the development of the software solution “time cockpit”. As mentioned before we are a start-up company and therefore our resources – time and money – are limited. It is neither our passion nor our goal to build and run data centres. Conventional hosting providers would solve this problem to a certain extent. We could outsource problems like housing, power, cooling, etc. to them. However, as soon as scalability is involved most regional hosting providers are not a satisfying answer. We hope that our user base will soon grow to a size where a single server is not sufficient. In a typical hosting environment we would be responsible for building and maintaining a complex server farm based on hardware provided by our hosting partners.
How we use Windows Azure
Azure solved this problem for us. We have designed our infrastructure to match the Azure platform as efficiently as possible. We have built a web role that provides WCF web services for our full client (WPF), for the product’s web site (built on top of telerik’s CMS Sitefinity; we have chosen this product because telerik announced that they will support Azure with their next release of Sitefinity) as well as for the upcoming Silverlight 4 UI. All services have been built in a stateless way where long running processes such as the creation of a new tenant are performed by worker processes asynchronously (Note: Currently Azure does not support .NET 4; therefore the code for the worker role runs in our own environment. As soon as Azure will support .NET 4 we will move this component into Azure, too). We apply Azure Queues as the communication mechanism between web and worker roles. This architecture ensures that we are ready to grow the number of instances over time as we need more computing power to serve a growing user base while continuing to guarantee good response times during marketing campaigns.
When it comes to storage we combine Azure Blob Storage and SQL Azure to be able to optimize costs and functionality. time cockpit’s signal trackers gather a good deal of personal data concerning the behaviour of users. Naturally this data is highly sensitive and has to be handled with great care. We therefore encrypt signal data on the user’s client with a key that belongs to the specific user rather than his company. By this, time cockpit guarantees that personal data is kept secret from others, even from us as the service provider. Additionally we had to keep in mind that signal data may occupy quite some space, even for a single user. Azure Blob Storage offers a perfect solution for storing large amounts of encrypted signal data. Base data and timesheet records are quite small to begin with and as they are not as sensitive as the signal data, we store them in SQL Azure. This allows us to use server-side SQL for filtering and aggregation. The combination of Azure Blob Storage and SQL Azure optimizes cost (large amount of data that is rarely accessed stored in Blob Storage, small amount of data that is accessed regularly is stored in SQL Azure) and scales nicely.
time cockpit is a multi-tenant solution on SaaS maturity level 4 (single, highly configurable application serving multiple tenants running in the context of a server farm). We are going to offer this product for a monthly price comparable with hosted Exchange. With these boundaries creating a single 1 GB Azure database for every user would be too costly and inefficient, because it seems very unlikely that a single small company needs 1 GB of relational database storage for their timesheets (given that signal data is stored in Blob storage). Therefore we decided to create a multi-tenancy enabled system in which multiple customers can safely share a single database. We used the Dynamic Language Runtime (DLR) as well as the C# compiler-compiler ANTLR to implement a textual domain specific query and expression language very similar to LINQ. The runtime environment of this data access layer has multi-tenancy built in from ground up. We separate tenants using SQL Server schemas without the user even noticing. More experienced users can query the time cockpit data store (blob store and relational store transparently) using a syntax similar to one they are used to (LINQ). We translate their queries into SQL and/or .NET expression trees and inject the appropriate schemas/filters so that users can never query data of other tenants. The system scales very well because it allows us to move tenants between databases. Therefore we can relocate large tenants to separate databases and share single databases between multiple small tenants on the fly. As it seems very unlikely, from today’s point of view, that a single tenant will need more than 10 GB of relational storage, we opted not to implement partitioning.
Client Side and Sync
On the client side we use SQL Server Compact Edition 2008 SP 2 to enable offline usage of time cockpit. We have written custom Sync Framework 2.0 providers to support the synchronisation of data and data model as well as the synchronisation of signal data into Azure Blob storage.
In short we state that Azure allows us to start very cost effective while providing a system that has the potential to scale massively. time cockpit may start small but should be a cost effective solution for a worldwide market. We consider ourselves in a good position to support many thousands of users based on the infrastructure that the Azure platform provides.
comments powered by