Top Domain Model

It looks like a new series is going to be published on this blog!

I received some feedback related to the recent series making your event sourcing functional. Posts in this series will be loosely coupled and more-less self-contained. The topic that will connect them is modelling your domain, aggregates, processes towards models that are useful, not necessarily correct. We’ll go through different domains & different requirements and we’ll try to focus not on the created model (it’s just an exercise) but rather on the modelling approaches and practices.

Put on your modeller’s gloves and safety glasses. It’s about time to crunch a few domains!

 

[PL] Eksperymenty małe i duże

TL;DR

Polski Piątek: o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich, jak na przykład o eksperymentowaniu.

Jak?

W ciągu ostatniego pół roku udało mi się przeprowadzić kilka eksperymentów. Każdy z nich był ograniczony:

  1. w czasie (próbuję coś przez miesiąc, pół)
  2. w kosztach (nie wydam 100000 na samochód aby zobaczyć jak się jeździ, ani nie powiem w domu, że teraz coś testuję i nie ma mnie przez miesiąc)
  3. efektach ubocznych (eksperymentem dla mnie nie jest jedzenie 10 czekolad dziennie – to głupota).

Jednym z moich eksperymentów było niejedzenie słodyczy przez miesiąc. Eksperyment zakończył się dobrym wynikiem. Słodyczy nie jadłem przez miesiąc, i już nie będę jadł. Jeżeli na konferencji, na której nie ma kanapek/sałatek a tylko ciastka, zjem jedno, dwa. Natomiast nie mam już ciągów słodyczowych. Koszt eksperymentu jest ujemny: nie kupuję słodyczy. Efekt uboczny: prawdopodobna redukcja tkanki tłuszczowej. Ojej ojej, co ja z tym zrobię 😛

Kolejnym, wstawanie o 5:45 a nie o 6:00 po to, aby zawsze móc poćwiczyć przed pobudką najmniejszego z domowników i nie mieć problemów z “niewyrabianiem się”. Eksperyment zakończony sukcesem w pierwszym tygodniu. Koszt: męczenie się podczas ćwiczeń, na które zawsze jest czas. Skutki uboczne: trochę lepsza kondycja i siła.

Kolejnym, są Polskie Piątki. Sprawdzam siebie, czy potrafię pisać o rzeczach mniej technicznych i Was, czy chcecie czytać o takich tematach.

Po co?

Nie wiem jak zareaguje moje ciało, umysł, otoczenie dopóki czegoś nie zmienię. Więc zmieniam, w ograniczonym zakresie (czas/koszt/efekty uboczne) i patrzę co z tego wychodzi. I tyle. Nie wszystko wyjdzie, nie wszystkiego się podejmę, ale sprawdzanie i korelacja efektów po, daje ciekawe wyniki.
Nie jestem tak dobrym eksperymentatorem jak Tim Ferris, który żyje ze swoich 4 godzin.  Jednocześnie mogę powiedzieć, że eksperyment z robieniem eksperymentów ma jak na razie pozytywne konsekwencje. I ten właśnie, postaram się przekuć w nawyk. A Ty, jak testujesz siebie?

ThreadStatic vs stackalloc

TL;DR

I’m working currently on SewingMachine, an OSS project of mine, that is aimed at unleashing the ultimate performance for your stateful services written in/for Service Fabric (more posts: here). In this post I’m testing whether it would be beneficial to write a custom unmanaged writer for protobuf-net, instead of using some kind of object pooling with ThreadLocal.

ThreadStatic and stackalloc

ThreadStatic is the old black. It was good to use before async-await has been introduced. Now, when you don’t know on which thread your continuation will be run, it’s not that useful. Still, if you’re on a good old-fashioned synchronous path, it might be used for object pooling and keeping one object per thread. That’s how protobuf-net caches ProtoReader objects.

One could use it to cache locally a chunk of memory for serialization. This could be a managed or unmanaged chunk, but eventually, it would be used to pass data to some storage (in my case, SewingSession from SewingMachine). If the interface accepted unmanaged chunks, I could also use stackalloc for small objects, that I know how much memory will be occupied by. stackalloc provides a way to allocate some number of bytes from the stackframe. Yes, it’s unsafe so keep your belts fastened.

ThreadStatic vs stackalloc

I gave it a try and wrote a simple (if it’s dummy, I encourage you to share your thoughts in comments) test that either uses a ThreadStatic-pooled object with an array or a stackallocated and writes. You can find it in this gist.

How to test it? As always, to the rescue comes BenchmarkDotNet, the best benchmarking tool for any .NET dev. Let’s take a look at the summary now.

local_vs_threadstatic.png

Stackalloc wins.

There are several things that should be taken into consideration. Finally block, the real overhead of writing an object and so on and so forth. Still, it looks that for heavily optimized code and small objects, one could this to write them a bit faster.

Summary

Using stackallocated buffers is fun and can bring some performance benefits. If I find anything unusual or worth noticing with this approach, I’ll share my findings. As always, when working on performance, measure first, measure in the middle and at the end.

How does Service Fabric host your services?

TL;DR

Service Fabric provides an amazing fully automated hosting for any number of services with any number of instances each (up to the physical limits of your cluster). But how are these hosted? What if you have more partitions than nodes?

Structure recap

When building an app that is meant to be hosted in Service Fabric you build an… app. This application might consist of multiple stateful and stateless services. The application is packaged to a… package that, when uploaded to the cluster as an image, provides an application type. From this, you can instantiate multiple application instances. Let me give you an example.

Application “Bank” consists of two services:

  1. “Users”
  2. “Accounts”

When build with version “1.0.0” and packaged, it can be uploaded to the SF cluster and is registered as “Bank 1.0.0”. From now on you can instantiate as many banks as you want within your cluster. Each will be composed of two sets of services: “Users” and “Accounts”.

Services, stateful services

When defining stateful services, these that have a built in kind-of database (reliable collections, or SewingSession provided by my project SewingMachine) you need to define how many partitions they will have. You can think of partitions as separate databases. Additionally, you define the number of replicas every partition will have. That’s done to ensure high availability. Let me give you an example.

  1. “Users” have the number of partitions set to 100 and every partition is replicated to 5 replicas (let’s say P=100, R=5)
  2. “Accounts” are configured with P=1000, R=7

Imagine that it’s hosted on a cluster that has only 100 nodes. This will mean, that on every node (on average) system will place 5 replicas of “Users” and 70 replicas of “Accounts”. It’s a valid scenario. Once some nodes are added to the cluster, replicas will be automatically moved to new nodes lowering the saturation of previously existing.

What if a node hosts more than one replica of one service, how are they hosted? Moreover, how do the communicate, as there’s only one port assigned to do it?

Cohosting to the rescue

Currently, all the replicas are hosted within the same process. Yes, although 5 “Users” instances will be created, they will all be sitting in the same AppDomain of the same process. The same goes for 70 “Accounts”. You can check it on your own by obtaining the current process ID (PID) and AppDomain.Current and compare. This reduces the overhead of hosting as all assemblies and static resources (assemblies loaded, static fields, types) are shared across replicas.

One port to rule them all

By default, when using native Service Fabric communication listener, only one port is used by an endpoint. How is possible that the infrastructure knows how to route messages to the right partition and replica? Under the hood, when opening a communication listener, replica registers the identifier of the partition it belongs to and its replica number. That’s how, when a message arrives, Service Fabric infrastructure is capable of sending the message to the right communication listener, and therefore, to the right service instance.

Summary

Now you know, that all replicas of partitions of the same service on one node are cohosted in the same process and that Service Fabric infrastructure dispatches messages accordingly to the registered partition/replica pair.

[PL] zdobywanie wiedzy i kompetencji dziś

TL;DR

Polski Piątek: o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich.

Za 15 lat

Jeżeli ktoś, podczas moich studiów, powiedziałby mi, że za 15 lat będę mógł uczęszczać w Warszawie codziennie na inny meetup związany z technologią, powiedziałbym, że to czyste żarty (wyraziłbym się bardziej dosadnie). I nawet, jeżeli cały czas jestem oszołomiony ich liczbą, to jest to przyjemne oszołomienie.

Poza dużą liczbą wydarzeń, charakteryzują się one też dużą różnorodnością. Mamy:

Jest tego naprawdę, zarówno pod względem liczby, jak i formy bardzo dużo. I dobrze!

Elitarność

Zdobywanie wiedzy traci na elitarności. I nie chodzi o to, że sama wiedza jest “gorsza”. Po prostu dostęp do niej jest coraz bardziej powszechny i coraz więcej zależy od jednostki, od Ciebie. Masz chęć i siłę poświęcić 2 godziny dziennie aby pouczyć się Go? Idziesz na meetup, rozmawiasz z ludźmi, oglądasz prezentacje, idziesz na szkolenie, kodujesz i zdobywasz wiedzę. I już.

Chęć

Pozostaje tylko jedno. Twoje chęci, zapał, wytrwałość, siła i kilka innych zasobów, którymi musisz się wykazać. To jak, wykażesz się? 🙂

 

Orchestrating processes with full recoverability

TL;DR

Do you call a few services in a row as a part of a bigger process? What if one of the calls fails? What if your hosting application fails? Do you provide a reliable way for successfully finishing your process? If not, I might have a solution for you.

Anatomy of a process

A process can be defined as at least two calls to different services. When using a client library of some sort and C# async-await feature one could write a following process


var id = await invoiceService.IssueInvoice(invoiceData);
await notificationService.NotifyAboutInvoice(id);

It’s easy and straightforward. First, we want to issue an invoice. Once it’s done, a notification should be sent. Both calls although they are async should be executed step by step. Now. What if the process is halted after issuing the invoice? When we rerun it, there’s no notion of something stopped in the middle. One could hope for good logging, but what if this fails as well.

Store and forward

Here comes the solution provided by DurableTask library provided by the Azure team. The library provides a capability of recording all the responses and replaying them without execution. All you need is to create proxies to the services using a special orchestration context.

With a process like the above when executing following state is captured:

  1. Initial params to the instance of the process
  2. invoiceData are stored when first call is done
  3. invoiceService returns and the response is recorded as well
  4. invoiceNumber is stored as a parameter to the second call
  5. notificationService returns and it’s marked in the state as well

As you can see, every execution is stored and is followed by storing it’s result. OK. But what does it mean if my process fails?

When failure occurs

What happens when failure occurs. Let’s consider some of the possibilities.

If an error occurs between 1 and 2, process can be restarted with the same parameters. Nothing really happened.

If an error occurs between 2 and 3, process is restarted. The parameters to the call were stored but there’s no notion of the call to the first service. It’s called again (yes, the delivery guarantee is at-least-once).

If an error occurs between 3 and 4, process is restarted. The response to the call to the invoice service is restored from the state (there’s no real call made). The parameters are established on the basis of previous values.

And so on and so forth.

Deterministic process

Because the whole process is based either on the input data or already received calls’ results it’s fully deterministic. It can be safely replayed when needed. What are not deterministic calls that you might need? DateTime.Now comes immediately to one’s mind. You can address it by using deterministic time provided by the context.CurrentUtcDateTime.

What’s next

You can build a truly powerful and reliable processes on top of it. Currently, implementation that is provides is based on Azure Storage and Azure Service Bus. In a branch you can find an implementation for Service Fabric, which enables you to use it in your cluster run on your development machine, on premises or in the cloud.

Summary

Ensuring that a process can be run till a successful end isn’t an easy task. It’s good to see a library that uses a well known and stable language construct of async-await and lifts it to the next level, making it an important tool for writing resilient orchestrations.

 

Much Better Stateful Service Fabric

TL;DR

In the last post we found the COM+ interface that is a foundation for KeyValueStoreReplica persistence. It’s time to describe the way, how the underlying performance can be unleashed for the managed .NET world.

Internal or not, I don’t care

The sad part of this COM+ layer of ServiceFabric is that’s internal. The good part of .NET is that when running in Full Trust, you can easily overcome this obstacle with Reflection.Emit namespace and emitting helper methods wrapping internal types. After all, there is a public surface that you can start with. The more you know about MSIL and internals of CLR and the more you love it, the less tears and pain will be caused by the following snippet code. Sorry, it’s time for some IL madness.


var nonNullResult = il.DefineLabel();

// if (result == null)
//{
//    return null;
//}
il.Emit(OpCodes.Ldloc_0);
il.Emit(OpCodes.Brtrue_S, nonNullResult);
il.Emit(OpCodes.Ldnull);
il.Emit(OpCodes.Ret);

il.MarkLabel(nonNullResult);

// GC.KeepAlive(result);
il.Emit(OpCodes.Ldloc_0);
il.EmitCall(OpCodes.Call, typeof(GC).GetMethod("KeepAlive"), null);

// nativeItemResult.get_Item()
il.Emit(OpCodes.Ldloc_0);
il.EmitCall(OpCodes.Callvirt, InternalFabric.KeyValueStoreItemResultType.GetMethod("get_Item"), null);

il.EmitCall(OpCodes.Call, ReflectionHelpers.CastIntPtrToVoidPtr, null);
il.Emit(OpCodes.Stloc_1);

// empty stack, processing metadata
il.Emit(OpCodes.Ldloc_1);   // NativeTypes.FABRIC_KEY_VALUE_STORE_ITEM*
il.Emit(OpCodes.Ldfld, InternalFabric.KeyValueStoreItemType.GetField("Metadata")); // IntPtr
il.EmitCall(OpCodes.Call, ReflectionHelpers.CastIntPtrToVoidPtr, null); // void*
il.Emit(OpCodes.Stloc_2);

il.Emit(OpCodes.Ldloc_2); // NativeTypes.FABRIC_KEY_VALUE_STORE_ITEM_METADATA*
il.Emit(OpCodes.Ldfld, InternalFabric.KeyValueStoreItemMetadataType.GetField("Key")); // IntPtr

il.Emit(OpCodes.Ldloc_2); // IntPtr, NativeTypes.FABRIC_KEY_VALUE_STORE_ITEM_METADATA*
il.Emit(OpCodes.Ldfld, InternalFabric.KeyValueStoreItemMetadataType.GetField("ValueSizeInBytes")); // IntPtr, int

il.Emit(OpCodes.Ldloc_2); // IntPtr, int, NativeTypes.FABRIC_KEY_VALUE_STORE_ITEM_METADATA*
il.Emit(OpCodes.Ldfld, InternalFabric.KeyValueStoreItemMetadataType.GetField("SequenceNumber")); // IntPtr, int, long

il.Emit(OpCodes.Ldloc_1); // IntPtr, int, long, NativeTypes.FABRIC_KEY_VALUE_STORE_ITEM*
il.Emit(OpCodes.Ldfld, InternalFabric.KeyValueStoreItemType.GetField("Value")); // IntPtr (char*), int, long, IntPtr (byte*)

The part above is just a small snippet responsible partially for reading the value. If you’re interested in more, here are over 200 lines of emit that brings the COM+ to the public surface. You don’t need to read it though. SewingMachine delivers a much nicer interface for it.

RawAccessorToKeyValueStoreReplica

RawAccessorToKeyValueStoreReplica is a new high level API provided by SewingMachine. It’s not as high level as the original KeyValueStoreReplica as it accepts IntPtr parameters, but still, it removes a lot of layers leaving the performance, serialization, memory management decisions to the end user of the library. You can use your own serializer, you can use stackalloc to allocate on the stack (if values are small) and much much more. This accessor is a foundation for another feature provided by SewingMachine, called KeyValueStatefulService, a new base class for your stateful services.

Summary

We saw how KeyValueStoreReplica is implemented. We took a look at the COM+ interface call sites. Finally, we observed how, by emitting IL, one can expose an internal interface, wrap it in a better abstraction and expose it to the caller. It’s time to take a look at the new stateful service.