Do not do in code what can be done in infrastructure
Or subtitle: Maybe distributed programming is no longer a programming problem? (For the obvious impaired: This is meant to be more thought provoking than an actual truth)
Or subtitle: Maybe distributed programming is no longer a programming problem? (For the obvious impaired: This is meant to be more thought provoking than an actual truth)
…
First of all, there is no such thing as “the fastest” serializer, it is all contextual.
But under some conditions, I would however argue that Wire is, by far, the fastest of all the .NET serializers out there.
In this short post I will explain some of the things I’ve learned building Akka.NET.
I will describe some of the friction points I have noticed and why I personally don’t use features like Akka Cluster to build entire systems.
Some of these thoughts might be obvious, some might be naive, but they do reflect my current view on building distributed systems.
In this post, I will try to cover some of the early history of Akka.NET and how and why things turned out the way they did.
**Akka.NET of course have some parallel histories going as there are many contributors on the project.
But the post is written from my own point of view and my reasons for getting involved in this. **
I know that there is some confusion out there on how Akka.NET relates to products like NServiceBus and Azure ServiceBus, I think that Akka.NET Co-founder Aaron Stannard said it the best;
This is a continuation of my completely random learning experiences while trying to learn the Azure plattform.
I’ve decided to bite the bullet and finally dig into Azure.
One question that often shows up when talking about the Actor Model, is how to deal with distributed transactions.
Time to break the silence!
We have now ported both the code and configuration based deployment features of Akka.
This means that you can now use Akka.NET to deploy actors and routers on remote nodes either via code or configuration.