Why is Axum relevant to distributed systems?

Last week Microsoft announced the first version of Axum. In a nutshell, Axum is a domain specific language (DSL) for modeling coordination and concurrency scenarios in .NET applications. Although Axum is still an incubation project and there is no final word on whether it will be productized, we should all agree that this represents a remarkable effort to enhance the .NET language ecosystem to embrace the next generation of applications based on multi-core architectures.

At first, Axum might seem a little “different” for developers accustomed to the traditional OO paradigm. This is fundamentally based on fact that this new language embraces the concepts of functional programming and messaging passing paradigms. It is understandable that a lot of developers in the .NET community will question the need for a new language for concurrency especially after similar efforts in technologies such as the .NET parallel extensions, F# and the Common Concurrency Runtime (CCR). Among these recent technologies, the CCR has made significant strides introducing new paradigms for addressing concurrency scenarios. In that sense, it does not come as a surprise that Axum uses the CCR as the runtime components underneath the language constructs.

Beyond any skepticism, we should see Axum as another step towards the renaissance of functional and messaging passing programming paradigms in the software industry. Outside the .NET community, similar tendencies can be seen by the increasing popularity of languages such as Erlang or Scala that intend to address similar type of scenarios. Contrary to the traditional school of thought that these type of languages are only relevant in academic environments, we keep finding more and more real world applications that are powered by the use of functional languages and specifically the message passing paradigm.

For thus of us working in distributed systems, I can see a few reasons while we should embrace this new type of programming technique.

• Scalability: Passing messages across side effect free tasks is a naturally scalable approach for distributed applications. It is not surprising that some of the most scalable systems in the world leverage on languages that follow similar principles to Axum. For instance, it’s well known that Amazon’s Simple DB has been entirely built on Erlang or that Twitter has relied on Scala to address some of their notorious scalability issues.
• Task partitioning: Axum forces developers to think how to split the functionality of an application into a set of concurrent tasks that can communicate via messages. This is a very familiar approach to distributed system programmers who have been using messaging distribution techniques for years now.
• Task distribution: One of the features that differentiates Axum from similar languages is its ability to partition an application into a set of isolated agents that can communicate either locally or remotely. In that sense, Axum relies on WCF as a mechanism for distributing tasks in a single server or across thousands of machines.
• Concurrent Service Choreographies: Orchestrating concurrent services interactions it’s a very common and equally challenging aspects of SO systems. These scenarios have been traditionally addressed by integration technologies such as BizTalk Servers or Windows Workflow Foundation. Even when using these technologies, implementing concurrent and coordinated interactions across distributed services typically requires large amounts of infrastructure code. For instance, implementing a very simple scenario that requires distributing a message across ten different services, collecting all the successful response and all the errors on those separate lists and aggregate them into a single response is far from trivial in most, if not all, of the existing integration frameworks.