Lokad.Cloud vs Lokad.CQRS, tiny insights about the future

Among the (small) community interested by the software practices of Lokad to develop entreprise software over Windows Azure, Lokad.Cloud vs Lokad.CQRS comes as a recurring question.

It’s a good question, and to be entirely honest, the case is not 100% solved even at Lokad. 

One of the core difficulty to address this question is that Lokad.Cloud and Lokad.CQRS come:

• from different backgrounds:
  • Lokad.Cloud orginates from the hard-core data analytics back-end.
  • Lokad.CQRS originates from ourbehavioral apps.
• with different intents:
  • Lokad.Cloud wants to simplify hard-core distributed algorithmics.
  • Lokad.CQRS wants to provide flexibililty, auditability, extensibility (*).
• and different philosophies:
  • Lokad.Cloud is a sticky framework, it defines pretty much how your app is architected.
  • Lokad.CQRS is more a NoFramework, precisely designed to minimally impact the app.

(*) without compromising scalability, however scalability is not the primary purpose.

Then, historically, Lokad.Cloud has been developed first (which is a mixed blessing), and, as we have been moving forward, we have started to partition into standalone sub-projects:

• Lokad.Cloud.Storage, the O/C mapper (object to cloud), dedicated to the interactions with the Azure Storage.
• Lokad.Cloud.AppHost, an AppDomain isolation layer to enable dynamic assembly loading within Azure Worker roles (aka reboot a VM with new assemblies in 5s instead of 5min). (**)
• Lokad.Cloud.Provisioning, a toolkit for the Windows Azure Management API.

(**) Lokad.Cloud does not leverage Lokad.Cloud.AppHost yet, it still relyies on a very similar component (which was developed first, and, as such, is not as properly decoupled than AppHost)

Those sub-projects end-up combined into Lokad.Cloud but they can be used independently. Both Lokad.Cloud.AppHost and Lokad.Cloud.Provisioning are fully compatible with Lokad.CQRS.

The case of Lokad.Cloud.Storage is a bit more complicated because Lokad.CQRS because Lokad.CQRS already has its own Azure Storage layer which focuses on CQRS-style storage abstractions. In particular, Lokad.CQRS emphasizes interoperable storage abstractions where the local file storage can be used in place of the cloud storage.

The Future

As far I can speak for Lokad.CQRS (see the projet boss), the project will keep evolving focusing on enterprise software practices, aka not so much what the framework delivers, but rather how it’s intended to structure the app. Then, Lokad.CQRS might be completed by:

• tools at some point such as a maintenance console.
• refined storage abstractions (probably event-centric ones).

In constrast, Lokad.Cloud will continue its partitioning process to become decoupled and more flexible. In particular,

• the cloud runtime
• the service execution strategy

are still very heavily coupled to other concepts within the execution framework, and likely candidates for sub-projects of their own.

Combining Lokad.Cloud and Lokad.CQRS?

I would not advise to combine Lokad.Cloud (execution framework) with Lokad.CQRS within the same app. At Lokad, we don’t have any project that adopts this pattern, and the resulting architcture seems fuzzy.

However, if we consider the sub-projects of Lokad.Cloud, then the combination Lokad.CQRS + Lokad.Cloud.AppHost + Lokad.Cloud.Provisioning does make a lot of sense.

Then, it’s possible to adopt a SOA architecture where some heavy-duty functional logic gets isolated, behind an API, into the Lokad.Cloud execution framework, while the bulk of the app adopt CQRS patterns through Lokad.CQRS. This pattern has been adopted to some extent at Lokad.

Reader Comments (2)

Joannes, Do you have any samples or docs describing how you would use Lokad.CQRS + Lokad.Cloud.AppHost +Lokad.Cloud.Provisioning? I can picture a generic framework where you can create a dictionary of CQRS commands, events, handlers, domain models, and maintain versions of these with the ability to make adjustments to the model on the fly. The adjustments would get loaded up/re-loaded using the AppHost code where you can make tweaks to your commands and events(versioned) and have the system unload and reload the new ones on the fly. It seems like with Project Roslyn combined with a good way to load and unload app domains(AppHost) you could build a high level set of tools and runtimes that could allow you to build a system where you can design your model in a dsl, generate and compile the code(roslyn), deploy and provision(Lokad) a very flexible, robust, and malleable system. January 3, 2012 | darren

Hi Darren, Thanks for your interest. Unfortunately, no, at this point, we don’t have such a “combo” documentation. Then, “Lokad.Cloud.Provisioning” is a bit a special case here, it’s not a framework, but really just a small library to interact with the Windows Azure Management API. The main difficulty being how to properly setup your Lokad.CQRS app to take advantage of the multiple VM instances if those happen to be instantiated. Don’t hesitate to post specific questions on our forum at https://groups.google.com/forum/#!forum/lokad January 4, 2012 | Joannes Vermorel