Lokad.CQRS Can Make Windows Azure Cheaper for You

Development of cloud computing systems can be a bit expensive these days. Expenses come from the development costs (and difficulties of finding good "cloud" developers) along with the actual pricing of the computing, storage and network capacities.

For example, traditionally the smallest distributed web application in the cloud requires a separate worker and web role. This can cause even the small projects to cost quite a bit when deployed to Windows Azure (to be precise, Microsoft recommends to have at least two web role instances, in order to achieve SLA).

If we are using Extra Small VMs with price of 0.05$ per hour, this would sum up to 72 USD per month just in the compute expenses. That's a bit too much for the small projects. Yet, every large project (that's where Azure shines with it's elastic scalability) starts small.

Lokad.CQRS framework offers three primary options to save the money while targeting Windows Azure Cloud.

First one, is to run an instance of Lokad.CQRS App Engine within the Web Role. This way we half our expenses from the start - paying 36 USD per month instead of 72 USD for the compute resources.

Sample code for that is available in the gist.

The approach of reducing costs by 50% was tried out by Vsevolod Parfenov of Lokad (also a new contributor to Lokad.CQRS, who currently pushes forward the Tape Storage).

We have a system already in production at Windows Azure. That's CallCalc, which is also explained in greater detail in Lokad.CQRS PDF (see case studies).

Second option comes from the portability side and involves deploying Lokad.CQRS solution outside of Windows Azure, till it grows large enough to justify cloud. You can run systems on local or hosted services using the cheapest Windows Server hosting to run web UI in IIS and App Engine as windows service or a console.

Note, that theoretically we can even go cheaper and use Linux with Mono. But research and development in this direction has not been the priority of Lokad for the time being.

As the system grows, it should be possible to switch it to Windows Azure by reconfiguring it to use cloud-scalable storage and transport. This is the scenario we have started using Lokad.CQRS in for development purposes, since Azure Development Fabric (Storage and Compute emulators) just add too much friction (you need to run VS as Administrator) and performance overhead.

For example, I get 15000 messages per second processed sequentially by Lokad.CQRS using in-memory queues, while Azure Queues give me just 7.4 messages per second. This test scenario involves sequential processing, where message handler keeps sending messages to itself. This tests full roundtrip overhead of a system and uses just a single thread for message processing.

Obviously, I could boost up the numbers of out-of-Azure performance by using multiple threads and also optimizing the reflection code. Yet for the time being there has been no real case, since Lokad.CQRS forces systems to be designed in a partitionable way. In it you improve performance not by over-optimizing code (which makes it more complex and involves expensive development effort) by just throwing in more processing power (which is generally cheaper).

If we do the math. An additional "Extra Small" instance on Windows Azure costs 36 USD per month. I would imagine that any performance optimization, deployed to production, would be generally more expensive than that:

• Costs would involve a few hours of development and testing work, followed by QA and deployment. Besides, good luck on finding an experienced Azure developer for less than 36USD per hour.
• Added code complexity is likely to add future penalty on new development along with the potential risks of breaking something (system that needs to scale must be already quite stressed and important for the company).
• You need to have enough qualified developers and time to do that (opportunity costs are involved).
• There is always a limit to how deeply you can optimize the code (deeper you go - more expensive it becomes).

I'd say it's much cheaper and easier to just provision a few more processing units, as needed.

This is the third way to save money on Azure - using the flexibility of elastic cloud to avoid doing risky and expensive development to handle scalability issues. Instead of going deep into the guts of Windows Azure, we just stay simple, wide and almost-infinitely-scalable.

BTW, if you are interested in design and performance of Lokad.CQRS and Windows Azure - please, check out Lokad community. It might already hold answers to some of your questions. Besides, there always is CQRS starting point.