Rinat Abdullin on Lokad Shared Libraries

People Don't Think in Tables

2012-02-05T12:14:26Z

Within the last few years I've seen major change in UI approaches in the systems I build. The change is caused by a shift from relational databases as persistence to something that does not require an SQL server (or DB server at all).

Take a look at this old UI of mine. It's pretty powerful (huge amount of buttons proves that), is intuitive for geeks and scary for normal people.

What's more curios, this UI is shaped by the relational persistence model that was created in mainframe days, when storage was expensive, memory even more so, and data had to be heavily normalized. However, technology has advanced slightly since then, and we no longer need to fit our UIs to something that is so spreadsheet-like. We can prevent user from overexposure to underlying data complexity, especially when data itself is simple, but just happens to be stored in a computer-optimized way.

Think of it again. We turn UI experience of users in sudoku game just because we know how to store data in a way that was good 20 years ago. No wonder Apple is making so much money - at least they don't try to turn every UI into spaceship control panel:

People don't think with tables. They would prefer something that is more simple, even if it does not benefit from a fancy styled UI framework. Something that does not involve solving sudoku puzzle every time you need to find a simple answer to your question or do your job.

or where we have the most simple way to search complex structured info, as patented and proven to be useful by google:

It is surprising, how underlying technologies affect what we build with them, is not it?

As you can guess, first 2 screenshots depict UI that runs on some sort of SQL, while the other UIs were influenced by a simple NoSQL storage model (to be precise: CQRS/DDD+ES model that uses for UI persistence blobs for cloud persistence and plain files for on-premises deployments).

BTW, I know that quite a lot of people are using Lucene to provide full text search capabilities for their read models. However in the simplest case (esp. with cloud deployments), it's easier to write a few lines of code as opposed to dealing with one more dependency.

Another side effect is that with the change of underlying tech from SQL (and more importantly - thinking model), there is less need to resort to data-aware UI frameworks (mostly used on conjunction with desktop apps) in order to provide rich user experience. This allows to have web-based applications that don't force framework installations (good luck with getting .NET or Java on all machines in some large organization with a lot of momentum) or complex upgrade routines (i.e. ClickOnce auto-update or automatic MSI updates).

I'm not talking about development simplicity and cloud-scalability - these come for free, and we don't really value things unless we struggle for them.

Obviously, as you can see from screenshots above, my UI skills are still below that of a kid with a box of crayons but lately Bootstrup and jquery have provided a really nice experience, especially, when you can reuse some great ideas and frameworks.

Wait, till we start getting into mobile experience with HTML5. It actually comes almost for free as well, since latest web layout frameworks provide a lot of mobile experience out-of-box.

NB: In no way I'm implying that this second approach is anywhere near close to being reasonably simple. And it's obviously bad looking (especially UIs that I hack together), but I think this is going in the right direction. At least, less time is wasted on writing UI docs and providing support.

New Videos on CQRS/DDD and Practical CQRS

2012-01-20T13:04:53Z

Thanks to awesome guys from Austrian Alt.NET (and particularly Jörg Egretzberger) there has been an opportunity for me to speak with Greg Young at Professional.NET in Vienna on September 2011. And here are the videos that were made there.

It's recommended to watch them in the provided order: first Greg's "CQRS and DDD" and then my "Practical CQRS"

Please, keep in mind, that this event took place more than 4 months from now; it also was the first talk I've done together with Greg (meaning that I became slightly less stupid and naive since then, especially during the CQRS RoadTrip 2011; at least that's what I hope).

CQRS and Domain Driven Design

by Greg Young. Direct link: http://youtu.be/KXqrBySgX-s

Practical CQRS in Cloud

by Rinat Abdullin. Direct Link: http://youtu.be/CnvO_nlvrps | PDF

I hope you enjoy them. Once again, kudos to terrific guys from Austrian Alt.NET community for making these recordings possible.

Run Lokad.CQRS code natively on Windows Azure

2012-01-14T14:09:08Z

As it seems, the most common use of Lokad.CQRS Sample these days is for building CQRS-based applications for Intranet (and migrating legacy projects). I didn't see that coming, but glad that the latest "lean" version makes some sense to people (more about it).

However, one of the initial purposes of this Sample is to enable and demonstrate cross-cloud portability of projects developed using abstractions from Lokad.Cqrs.Portable. That's how we use it at Lokad.

So to highlight this (and to help folks from Microsoft CQRS Advisory Board that showed interest in trying Lokad.CQRS with Azure), I've added two new projects: Sample.Azure.Wires and Sample.Azure.Deploy. There is nothing really special, first project just wires SampleProject to run on Windows Azure in a Worker Role, without touching existing domain code. Second project is the actual deployment.

As expected, trace output is similar to the one we get from running sample in on-premises mode (via Sample.Engine console).

Obviously, this worker is wired to use native components of Windows Azure, instead of file system. These components (developed in Lokad and production-tested over the last few years in various scenarios) include:

BlockBlobTapeStorage (used for append-only event streams on Azure)
AzureAtomicStorage (used for storing documents, saga state and persistent read models)
BlobStreamingStorage (used for streaming large BLOBs for Big DataProcessing)
Azure Queues (for your message sending needs)

If you have latest Azure SDK installed, just open Lokad.CQRS.Sample.withAzure.sln to see these additional Azure projects and get a taste of event sourcing on the cloud (actually tastes exactly like any other ES, but feels cooler).

Maintenance Tip: By the way, you can download domain log file (sample-tapes/domain.tmd) from the Azure Storage to your disk and open it with Audit tool. This helps to visualize and investigate processes that happen in your CQRS system on the cloud (actually saved my day more than once, when production systems hit unexpected problems). Likewise you can also download and investigate event streams of any single aggregate.

Actually, this Audit tool was also designed to open event streams directly from Azure (and allow sending selected messages back or rebuilding all projections), however this functionality is not ported to open source yet. If somebody finds it useful, I'll try to find time and export it (there is nothing really fancy there, though - just using append-only nature of event streams for efficient data replication from remote cloud to local machine).

Maintenance Tip: Those, that plan to use this in a production, might want to plug the quarantine into the message handlers. For instance, here is a sample that records every handler failure and send a detailed report (with stack traces and message information) to email as soon as message is quarantined. The latter helps to deal with cloud problems really fast.

The next thing I want to include in this Sample Project is a lean Web UI, using ASP.NET MVC 3 Razor Views with jQuery and Bootstrap.css. Just to demonstrate how easy it is to add browser-friendly and fast Web UI to existing CQRS systems (and have it hosted on-premises or in the cloud, of course). What do you think?

Meanwhile, have fun, join the community of people abusing the project and be sure to fill in CQRS Survey put out by P&P Team

Announcing Lokad.CQRS vLean - SampleProject and Tools

2012-01-05T17:49:25Z

I've just finished assembling pre-release of Lokad.CQRS vLean (lean branch in github repository). From of this version Lokad.CQRS is no longer a framework, it is a full sample.

As such, Lokad.CQRS could be used for learning about event centric development (CQRS/DDD with event sourcing and ability to deploy in cloud and on-premises). Gradually growing series of articles in my bliki could provide some theoretical background.

You can also use Lokad.CQRS to jumpstart new projects by copying the entire SampleProject to your system and then modifying it to your needs. That's essentially how we start new projects at Lokad these days.

Because of this transition from "Framework" to "Sample with Sources" (aka "Reference Implementation"), I was finally able to include a lot of new material into this branch.

Sample Project

I've ripped part of domain code (simple account+users setup) from one of our projects, along with all the accompanying tooling, tests and engine. Current approach to event sourcing is also included (as explained in the bliki)

The project currently does not include:

Deployment runners for Azure.Cloud (planned later, however Lokad.CQRS users should have pretty good sense of reconfiguring the domain to run in Azure).
Web UI (but I might add it later, if time permits, since Razor + Bootstrap make really pleasant and fast development with this architecture).

I'll try to add these later (community contributions are also awesome).

Absence of Web UI makes it harder to visualize what's going inside. However you can still run tests and also start Sample.Engine (configured with file-based persistence and queues), that will fire a few commands, which will produce events that will be wired to sagas and projections. Just like in the real world.

Plus, this project includes some sample code and tools that are wired to it. These are used exactly how we currently use them (although not necessary how we will use them a few months later). Read below for more info.

Contracts DSL

Lokad Contracts DSL is an optional console utility that you can run in the background. It tracks changes to files with special compact syntax (as mentioned in commands and events on bliki) and updates CS file. Changes are immediate upon saving file (and ReSharper immediately picks them). This is an improved version of Lokad Code DSL, it supports identities and can auto-generate interfaces for aggregates and aggregate state classes.

You can try this out by starting SampleProject\Tools\Dsl project and then doing some changes to SampleProject\Domain\Sample.Contracts\Messages.tt.

Current DSL code generates contracts classes that are compatible with DataContracts, ServiceStack.JSON and ProtoBuf. Here are how they look like:

[DataContract(Namespace = "Sample")]
public partial class AddSecurityPassword : ICommand<SecurityId>
{
    [DataMember(Order = 1)] public SecurityId Id { get; private set; }
    [DataMember(Order = 2)] public string DisplayName { get; private set; }
    [DataMember(Order = 3)] public string Login { get; private set; }
    [DataMember(Order = 4)] public string Password { get; private set; }

    AddSecurityPassword () {}
    public AddSecurityPassword (SecurityId id, string displayName, string login, string password)
    {
        Id = id;
        DisplayName = displayName;
        Login = login;
        Password = password;
    }
}

Audit Tool

After you have run Sample.Engine, try starting Audit and opening with it this file temp\sample-tapes\domain.tmd (located in folder where the engine run). You should see something like this:

You'll probably figure out the purpose of color coding (or you could look out in the sources).

BTW, here's how the other tab looks like - it is used for automatically detecting and wiring all projections and then running the selected event stream through them:

Please keep in mind, that this is a fast rip from internal code, so a few buttons and functionality might not make full sense in the file-based context (i.e. domain log synchronization).

Simple Testing

I've been mentioning heavy abuse of Greg's SimpleTesting for dealing with specifications to test Aggregates. Source code for that is included (and for printing out them in readable format). Just fire your NUnit (either directly or via ReSharper):

This setup currently supports usual AR+ES testing, plus testing exceptions thrown by the domain code (domain errors), plus dealing with services and time.

Core Changes

There were a few core changes in the actual Lokad.CQRS framework. They were caused by the need to move forward and support wider range of scenarios (and better scalability). Actually, these features were mostly related to throwing things out - all builder syntax and containers. In the current version you wire everything without using overcomplicated builders. This leads to fewer dependencies and simpler code.

If you don't know, how old builder code translates to the new one - just check Wires and Engine projects in SampleProject (in addition to Snippets and unit tests for core building blocks).

In the spirit, we are gradually drifting away from style of architectures that is similar to NServiceBus, MassTransit and RhinoQueues (where you have handler classes plugged into the container for you). Instead, we are going directly for the type of architectures described by the outstanding ZMQ guide.

What's Next

As always, your feedback is always welcome (it helped to shape the current release and let us move forward). Please share it (along with any questions you might have) in Lokad community

A lot more is planned in this world along the following directions:

Simplifying the core even further, along with solidifying the backing theory, based on real-world experience.
Better support of multiple clouds (just Azure is not enough)
Realt-time performance scenarios.

Stay tuned and participate in the community, if you are interested!

Roadtrip-2011 Lessons Learned at #eventcentric in Kiev

2011-10-24T17:46:40Z

In short - this spontaneous Event centric weekend in Kiev was totally awesome and rewarding.

Check out tweets, if you are interested in what others feel (people are talking about sparkles in the eyes and #eventcentric cult :)

This event was organized as a part of Road-Trip 2011 with Greg Young. There were quite a few other adventures that happened along the way earlier - too much to write about. So I'll just focus on the last weekend and lessons learned.

Event Centric weekend in Kiev was a two day class held for free in Kiev. Greg Young was doing his well-known CQRS/DDD course, I've got to share some of my practical experience with such systems "in the wild" (including various cloud options).

Room was packed with 90+ people from multiple Ukrainian cities and also from a few cities in Russia.

Luxoft Ukraine helped us immensely by providing with the place to do that. Irina Odina of Luxoft deserves a medal (or two raises in salary) for staying with us through the weekends and helping with the coffee breaks. Mike Chaliy and really friendly Kiev Alt.NET community were helping with afterparties, logistics and coping with unexpected.

Here's what I've learned during this event:

One of the best ways to strengthen your understanding in a field is to speak and share. For instance, I've learned a lot simply by explaining aggregates and sagas to the audience and then seeing that not everybody gets a clear and coherent picture. Or, when you get an question from an audience, and you know an answer to that question, but can't explain this immediately in clear and concise language immediately. Then Greg comes in with his explanation and reveals missing pieces and steps in my own explanation and understanding.

Showing my own hacks to the theory and practice (and sharing how everything works really nicely in distributed teams and cloud environments) is always a pleasure of its own.

There were a few smaller realizations of its own along the way. The most important one of them was about more clear and focused picture of bringing multiple complex systems together in a way to limit complexity and facilitate development (obviously, with limited time and resources). Basically that's the a-ha understanding of how to separate elements of a distributed systems (bounded contexts, sagas, services, cloud scalability points), while keeping each element highly specialized (and relatively simple).

In essence, this is a direct analogy with human body, where:

Bounded contexts (matching aggregate roots in extreme) == neurons that are completely isolated from each other, but can exhibit complex behaviors and have a short-term memory;
Sagas (stateful or stateless) == glial cells that protect and insulate neurons from each other, while connecting them;
Stateless services (integration, number crunching, file processing etc) == specialized organs) in a body that can get some job done, but tend not to have any memory on their own. They react to impulses and send back information about the events that happened to them.

This analogy (coupled with the basic principles of biology) actually explained me better how to build and evolve really interesting IT systems, while keeping core cells simple. In short - that's just like how evolution does this. That was a really important realization since before that I simply could not understand how to bring together behavioristic CQRS-driven systems with elastically scalable functional elements of big data crunching or messy technology-dependent integrations. This understanding comes just in the right time - as we are starting yet another project at Lokad these days. I'll definitely blog about that more of that later.

A few smaller realizations were coupled to Sagas (explaining them better, to be precise) and transition from domain models to Aggregate Roots with Event Sourcing via TryDo-Do logic (nothing essential to the production but still helps to see and explain better)

By the way, the road-trip is not other yet. There is still a lot to learn and do.

So far, thanks to everybody for helping to learn and have some wonderful time!

Experience with CQRS+ES/DDD in Current Project

2011-10-11T19:55:51Z

Just a quick summary of tech I'm using in the current project. So far it works out rather nicely.

Project targets Windows Azure. However, just like our other recent projects at Lokad, it is developed to be cloud-ignorant (can be deployed anywhere where Microsoft .NET can be run).

Development machine: MacBook Air 2011 13' with intel i5 CPU (1.7Mhz), 4GB RAM and 128 GB SSD. OSX (Lion) with Windows 7 running in Parallels. I used to boot it in BootCamp (for native performance) a few times and then switched to pure VM mode.

Development IDE: Visual Studio 2010 with ReSharper 6 (solution-wide analysis is OFF). Windows Azure SDK is installed (with Emulator and Storage) However it's not used at this project at all, due to being rather inefficient with resources of my MBA. File system is used for both queues and storage instead. In production they will be reconfigured to use Azure-specific adapters (abstractions provided by Lokad.Cqrs).

Architecture: Distributed system with "CQRS approach" where aggregates are implemented using Event Sourcing. Business processes are stateless routing rules (as opposed to more classical sagas), with more complex workflow logic and state being pushed to aggregates or dedicated entities. The latter makes perfect sense with event sourcing and deployments in cloud environments.

Read-models are implemented using document model for now (each view is a single document being updated atomically). Still no SQL. Huge lists will be handled on per-platform basis (if they ever become a problem worth solving).

Frameworks: Domain logic (the most complex part) does not really depend on anything except Base Class library (System. namespace). Infrastructure (essentially, configuration code) relies on ProtoBuf/ServiceStack for serialization and Lokad.CQRS with Autofac for hosting everything server-side. Web UI - ASP.NET.

Testing: NUnit used to wire custom specifications (code copied and adjusted from SimpleTesting).

Custom tools: using side helper to generate command/event contract classes (got lots of them) out of compact DSL. C# code is generated whenever I do Ctrl-S and is immediately picked up by R# (this is slightly improved version if T4-driven CodeDSL. Improvement - it no longer depends on T4 and hence is much easier to change. Actual DSL generation is completely within the project now. details are in gist. This custom tool can be dropped at any point (completely along with the DSL files), contract files will stay.

What makes development complex:

it's hard to get domain models and bounded contexts right (however coding or testing itself is no longer an issue. Scalability and performance - even more so);
hard to communicate finer-grain detail to people used to SQL/ORM;
I still haven't figured how to explain (graph) business processes. So far sequence diagrams work the best;
Event sourcing plumbing had to be implemented manually (EventStore was too much of a dependency, something more simple was needed).

For the record, this project is a replacement of the project that was using following stack:

NHibernate + FluentNHibernate
Newtonsoft JSON
Autofac
Windows Azure
Microsoft SQL Server
Protobuf
Lokad Shared Libraries

Migrating existing system to ES requires an additional custom "Reverse Engineering" app, which scans database and generates events for the new deployment (roughly 300000 events).

Best lessons learned:

NHibernate and ORMs in general are a pain (especially in systems that has to live through more than 1 deployment). Although we are so used to that pain, that it does not feel. Well, until you have to go back and work on projects that have not been migrated, yet.
Specification tests (and ability to use them as a living documentation readable by non-dev people) create some interesting additional opportunities.
Simpler the code is - better.
Abstraction from the persistence not only reduces friction, but also allows to have multiple deployment options (in cloud, on-premises, in memory etc).
If domain model is defined (i.e.: there is BC and specifications for an aggregate), then actually coding Aggregate root with event sourcing (AR+ES) feels like a monkey coding - you just need to make all tests pass.
Helland's principles (of building distributed systems in eventually consistent world) can be enforced in CQRS/DDD world, if we get rid of sagas in classical interpretation (something that has state, subscribes to events and publishes commands), replacing them with stateless routing rules and pushing state to entities (aggregates). Underlying framework becomes much easier (no need to explicitly manage and correlate saga state). Dynamic scalability - too.
I'm using Event Sourcing even for simple things (like replicated user logins), simply because introducing Sql (or any other storage) would add too much complexity and friction without any visible gains.
Using specifications for testing AR+ES has another side advantage - I added a single unit test, that gathers pre-populated commands and events from these specifications. This data is round-ripped through a few serializers and compared. This ensures that message contracts (and their use) stays compatible with all primary serialization options (ProtoBuf, JSON). Helps to catch use of DateTimeKind issues (which is generally not supported by JSON+PB).

Obviously, this is highly subjective experience (and really rewarding). It might change as we are pushing the project to the first release (and further). Your mileage may vary. If you are really interested in long-term production experience - please ask me about that in a few years.

PS: This is not the first project where ES has been used. But it combines the best lessons learned in lean development at Lokad.

Golden Rule of Technology

2011-09-28T11:54:37Z

The rule says: 1 new technology goes into codebase only after 1 old technology goes out.

This is a simple empirical rule that we've coined with Joannes, while talking about business and managing technology. As it turns out, this rule makes a really nice guideline for planning future development.

The rule can apply to all sorts of things: new technological concepts, frameworks, ideas, tools and software. Basically, a technology in this list is anything that a new Junior Developer will have to learn about the project, before he can productively work the assignments.

This approach encourages technology pruning and explains how to structure technological evolution of your company, almost turning this process into a game. This is quite important, since otherwise it will be hard to "embrace the change" and leverage new technologies and tools, as opposed to being hit hard by every new "revolution". Essentially it helps to define your own Technology Radar at the project level.

For instance, we have the following evolution path for the User Interfaces in the world of Microsoft .NET Framework:

Windows.Forms
Silverlight/WPF
Windows 8/HTML5/some Metro UI

If you treat these UI technologies as something to focus completely on, then every new change might be quite expensive (i.e. from Silverlight to HTML5), because of the way the problem is being structured:

We are going to develop new eCommerce suite with Silverlight.

However, treating technologies as something transient and replaceable can reduce costs and even improve architecture (making it more resilient to risks and changes). Consider this way to structure a problem:

We are going to deliver eCommerce suite, while using Silverlight for UI for the time being.

Obviously, this approach requires an architecture that favors decoupling and simplicity (i.e.: CQRS/DDD/ES methodology). However, this is not limited by the software architecture alone. Here are some samples:

Frameworks
Version Control Systems
Testing Approaches
Project Management Concepts
Integration Servers
Deployment Strategies
Serialization Formats

Another interesting side effect of this Golder Rule of Technology is that it encourages developers to simplify and refactor in order to be able to try some new cool things in the project.

And sometimes, when you get rid of an old technology, there already is so much improvement, that you don't even want to add anything instead. One example of such replacement in place is gradual migration from traditional SQL-driven persistence to Event Sourcing at our place. It allows us to discard quite a few items from the current stack:

NHibernate with all the related binary dependencies
SQL Servers along with the entire concept of relational database and object-relational impedance mismatch
Evolutionary databases and managing them (including upgrade scripts and unit tests working against mock databases to verify behaviors on continuous integration servers)

Another practical sample would be - planned replacement of API implemented as REST via WCF (with SOAP and all sorts of weird configuration problems) towards a dead-simple implementation on HttpListener.

An interesting thing is that I never really considered complexity of technologies related to a feature till starting to think about that in terms of "Return on Technology Introduced". As it turns out:

Usage of technologies is extremely overrated (sometimes attributed to the marketing hype related to certain buzz-words).
Usage of additional technologies tends to increase both burden and complexity of a project at hand. Emprical evidence suggests that linear increases in these - lead to exponential rise in project costs.

The process of complexity increase can continue till the project becomes so expensive that it stalls. By reducing the number of non-essential technologies used, we can have better management of overall complexity (fighting delays, quality problems and costs).

In essence, simplicity is a technology of its own. But it does not count as one.

.NET Sample of Marrying CQRS, JS, and Http

2011-09-01T16:53:18Z

We've just published a rather interesting .NET code sample illustrating interactions between a browser and a CQRS-like server with queue processing. The sample is implemented as a snippet on top of Lokad.Cqrs, leveraging the latest codebase and new http endpoint functionality.

Just a reminder. Lokad.Cqrs is not a real framework. It is just a temp scaffolding that speeds up development of distributed systems following CQRS architecture principles. It enforces design that will make it easy to scale and move system between on-premises and cloud deployments (saving money, whenever possible). Core elements are made intentionally simple to educate and encourage eventually replacing them with solutions tailored specifically for the specific project.

HttpEndpoint is a new feature of Lokad.Cqrs, that demonstrates how easy it is to write some simple non-blocking web server and then put it to a good use. In the sample we do some interesting stuff:

host both CQRS engine and http server in the same process;
actually start the entire process inside a unit test;
serve some html, images and javascript to the web browser (tested with all major ones :)
let browser post simplified commands to the memory queue on the server;
process these commands in async, aggregating results to a simple view;
use this view to display info back in the web browser.

Sounds cool enough for a simple sample? Here's how it actually looks like:

You drag Lokad.CQRS logo around the canvas. Each mouse move generates an event, which is AJAX posted to HttpEndpoint, which adds a message to the queue. Another javascript queries a view for the stats like distance and average message throughput of this non-optimized code.

Interested to see how simple this code is? It is shared with the community as open source within the Lokad.Cqrs/Snippets project in hope that it will be of any help. You can:

Check out ReadMe or just grab Lokad.CQRS (branch 'vnext') from github and run it locally.
Ask questions in our community.

BTW, the primary reasons, why HttpEndpoint functionality was added to Lokad.Cqrs were about supporting following simple scenarios:

network message dispatch in non-Azure deployments of systems developed with Lokad.Cqrs;
simple secure endpoints for posting commands and querying views (problem of long lists can be solved here);
extremely simple built-in UI for certain maintenance scenarios in Lokad.Cqrs systems that should work nicely even with fast push deployments on Azure;
an easy way to support XML/REST/JSON integration scenarios with 3rd party systems without the need to roll out ASMX/WCF/ASP.NET or whatever over-complicated mess.
have all these endpoints (supporting multiple virtual urls on a single server) on the same machine with the server processes, saving money on small project deployments in the cloud.

What do you think of this sample?

Self-Improvement Process

2011-07-17T02:26:34Z

Lately I've been doing a little bit of new and well-forgotten old things, while trying to become a better me. They also help me to reduce work pressure by offering something new for the brain to chew on.

I just wanted to share these things (at least for the sake of writing down the links). We'll talk a little bit about:

git;
vim;
LMAX and Martin Fowler;
VerseQ;
Lokad.CQRS and functional approach.

Git

I've started using git on a number of new learning projects. As I've mentioned it on a couple of occasions already, I start liking git more than mercurial, despite its steeper learning curve.

By the way, Google Code has finally added git to their project support. Although they are way too much behind github both in usability and commits.

Vim

Subj, the good old editor coming from the terminal era. Exactly the one, where "the best way to generate a random string is to ask a student exit vim" (by the way, it is ":x" to exit with save-if-modified).

I find using it more and more for common text editing tasks. That's where I'm writing articles and blog posts these days.

And I'm getting really tempted to start replacing IDEs with vim in non-.NET environments. Developer's mind is better than any IDE anyway, especially when he or she deliberately keeps projects dead-simple.

Now, if you got interested in vim, then that's what your future will look like. If this didn't scare you, here's a quick intro from the eyes of guy from VS environment.

LMAX and Martin Fowler

It seems that all this CQRS/ES stuff is getting mainstream, since Martin Fowler wrote a bliki post on CQRS and really good overview of LMAX architecture: the latter is essentially an in-memory circular buffer that also acts as a queue for the event sourcing messages; processed by a single writer and multiple readers. All workers have access to each other location pointers and this avoid any locks altogether. Predefined buffer size and one-writer-only approach allows to achieve high hardware affinity (in other words, CPU likes it a lot).

The study is highly recommended for a read.

By the way:

bliki is term for versioned blog/wiki coined by Martin Fowler a while ago. These days people just use github with markdown (for example, this Lokad.CQRS Study isn't a page, but just a markdown file in a github repository).
Don't read Martin's pounding on branch-per-feature. I believe he got it wrong (and got quite a bit of pounding from the community afterwards).

VerseQ

To keep up with the learning process, I've stepped back on improving my keyboard typing skills. I believe it would be a wise investment of my time to improve on something that is so tightly related to the job and thinking as the typing is. This (when coupled with vim) feels like reducing VS development friction by introducing ReSharper.

For this task I'm currently sticking to VerseQ, which was recommended to me by Vsevolod. VerseQ tutor simply keeps on generating pseudo-random strings for you to type. However these strings are not entirely random:

they include chords common to the language you practice (i.e.: "jg" is not common to English, while "li" is more common);
next random string is based on the statistics captured so far. It will force you to practice your slowest keys and key combinations (or most erroneous ones).

Recommended to give it a try, if you are typing more than 50 lines of text per day (emails or code alike).

Functional Stuff

In the previous post I've mentioned that it is possible to get a whooping number of messages per second on a single thread in Lokad.CQRS using lambda dispatchers. This comes from a simple realization that everything is either an aggregate/saga or a function. For example, handlers are just functions partially resolved from the container and executed against the message.

Now, to be true with this kind of development you can easily achieve much higher throughput, if you switched to some other platform. I'm currently looking at akka for the small specific cases where extremely high performance would be needed (i.e.: message routing for Lokad.CQRS or doing some high-frequency data transfer). Fortunately enough, envelope and data formats of Lokad.CQRS are relatively cross-platform (protobuf to the rescue).

With akka you can get something like a few millions of messages processed per second. The latter might be another life-saving option for devs and start-ups (constrained on resources) who are using Lokad.CQRS and are hitting some throughput limitations on elements of a decoupled/cloud system that are a bit hard/expensive to scale (load balancers and routers, for instance).

Obviously I'm not planning to switch anything in Lokad.CQRS to akka and dead-simple functions editable in vim (no matter how tempting this might look, there always are real-world costs associated with such dreams). Yet, where possible to simplify things (i.e.: by throwing another framework out of the window) the experience and ideas will be reused in the approach. Especially, if they provide a clear and simple path of massively boosting performance of certain nodes in a decoupled app by switching them to the non.NET stacks.

PS: if you post a comment and it does not show up within a day, please drop me a line. I get the feeling Squarespace has messed up it's spam protection badly again.

Lokad.CQRS - Getting Simpler and Faster

2011-07-16T18:27:32Z

Recently I've been pushing a few changes into Lokad.CQRS trunk, as required by current Lokad projects. Two major ones are:

easy consumption of messages from completely separate projects;
lambda dispatch.

Multi-verse consumption

The most important improvement is to simplify consumption of messages coming from different systems. Consider situation, when project C consumes messages from projects A and B. Each project is in essence it's own universe with it's own dependencies and development speed. Message contracts are distributed in binary form of A.Contracts.dll, B.Contracts.dll etc.

based on our experience at Lokad we strongly recommend to ensure that these contract libraries should depend only on System.* dlls. Otherwise managing multiple projects will become time-consuming task.

Problem was related to the fact, that given:

project A defines its own base interface IMessageA for message classes;
project B defines its own base interface IMessageB for message classes.

in the project C we can't define a consumer signature that will handle both base interfaces.

As it turns out, the solution is quite simple. We can define polymorphic dispatcher to use object as a base message class (could be done on the latest):

mdm.HandlerSample<IMyConsume<object>>(s => s.Consume(null));

And then actual handler could be defined as:

public class SomeHandler : IMyConsume<ProjectAMessage>, IMyConsume<ProjectBMessage>

This small refactoring actually allowed me to decouple polymorphic dispatcher from the actual dispatch process. The latter simplified things a lot and enabled dead-simple performance optimization.

More than that, it allowed to move forward with our current projects within Lokad (where we have on average less than one developer per active project and thus can't waste any time on unnecessary friction).

What is polymorphic dispatcher? It is that complicated piece of code in Lokad.CQRS that allows you to define handlers as classes that inherit from various consuming interfaces (i.e.: IConsume[SpecificMessage] or IConsume[IMessageInterface]), while correctly resolving them through the IoC Container, handling scopes and transactions as needed.

Lambda Dispatch

Lokad.CQRS is rather simple (unless Azure slows it down) and hence it can be fast. Since we no longer have extremely tight coupling with the polymorphic complexity, we can dispatch directly to a delegate, which has form of lambda:

Action<ImmutableEnvelope> e => /* do something */

This is implemented as another dispatcher type available for all Lokad.CQRS partitions.

c.Memory(m =>
    {
        m.AddMemorySender("test");
        m.AddMemoryProcess("test", x => x.DispatcherIsLambda(Factory));
    }

static Action<ImmutableEnvelope> Factory(IComponentContext componentContext)
{
    var sender = componentContext.Resolve<IMessageSender>();
    return envelope => sender.SendOne(envelope.Items[0].Content);
}

Note, that we are actually using container once here, while building the lambda. Aside from that, there is neither reflection nor container resolution. This allows to get better performance. Below are some test results. First number goes for classical polymorphic dispatch, second one - for lambdas. MPS stands for messages per seconds.

By the way, you can obviously combine different types of dispatchers in a single Lokad.CQRS host.

Throughput performance test (we fill queue with messages and then consume them as fast as possible in 1 thread, doing all proper ACK stuff):

Azure Dev Store (don't laugh) - 11 / 11 mps
Files - 1315 / 1350 mps
Memory - 79000 / 101000 mps

By the way, memory queues are equivalent of non-durable messaging, while file queues are durable.

Reaction time test (single thread sends message to itself, then pulls this message from the queue etc):

Azure Dev Store: 8 / 8.4 mps
Files - 817 / 908 mps
Memory - 14700 / 44000 mps

First of all, You shouldn't worry much about relatively slow performance of local Azure Queues (that's what happens when you use take the complex path). Production performance should be an order of magnitude faster for a single thread. Besides, File and Memory partitions were added precisely to compensate for this slow performance while reducing development friction for Windows Azure Platform.

BTW, there is a chance that we can come up with better queues for Azure, than Azure Queues, drawing inspiration from LMAX circular architecture and relying on the inherent Lokad.CQRS capabilities.

Second, while looking at Files/Memory performance on a single thread, I would say that this is not so bad for code that was not performance optimized for the sake of staying simple.

Caveat: this performance applies to local operations only. True tests should cover network scenario that matches your production development (preferably with a chaos monkey in the house).

Probably if we use RabbitMQ or ZeroMQ, throughput can be even better than files out-of-the box.

Third, performance improvement is just a side effect. This refactoring was actually driven by desire do simplify the core (potentially getting rid of IoC container), provide much better support for extremely simple handler composition (based on lambdas), event sourcing and strongly-typed pipes.

For example, you can actually wrap all your command handlers (this applies even for polymorphic dispatch of commands/events) with some method that apply to them all (i.e.: logging, audit, auth etc). You can check this video of Greg Young to get a hint of things where we are going from here.