Pluggable transports for connecting tiers in different docker containers?

[aprokopyev]

Hello,

Please let me know, which methods can be used to connect different tiers of .NET 5 application based on your latest CSLA except REST? I am going to place some of different CSLA tiers into different docker containers and need to connect them somehow.

Can I use following libraries like:
ServiceStack (most likely REST too), MassTransit,
light low level clients for MQ services like https://www.rabbitmq.com/dotnet.html ,
may be something else?

Examples of using MassTransit:
https://ffimnsr.medium.com/connecting-services-using-masstransit-rabbitmq-on-net-core-3-1-343b510c9202
https://blog.hildenco.com/2018/08/creating-masstransit-clientserver.html

Which one of mentioned variants of interconnections between microservices would you suggest for CSLA applications?

Thanks

[rockfordlhotka]

First, it is important to understand that the CSLA data portal is designed around an n-tier model, not an async service-based model. That has a set of consequences, most notably that each time you call the data portal, the data portal calls a service, and then expects a response, which it provides to you. Understanding this, we can talk about protocols.

The data portal is protocol agnostic, and you can provide data portal channel implementations for any protocol that can support the concept of sending a message, getting a response, and returning that response to the caller.

This is very easy with things like http or grpc, because they are designed from the ground up as call-response protocols.

A little over a year ago I implemented a RabbitMQ channel to demonstrate how to implement this concept using async messaging. The same basic implementation will work for Azure Service Bus or any async messaging model based on queue endpoints.

The core idea is that the channel listens on a "callback queue" to get any responses, and sends messages to whatever queue is associated with the service you are calling. The requirement is that the service send its responses to the "callback queue".

Given that the client-side and server-side data portal are designed using this call-response model, that all makes sense and is generally pretty easy to implement.

The upside, is that (especially when combined with the versioning/routing features of the data portal) you can have your client send a message to a Kubernetes cluster (queue endpoint), and that message can be handled by any active service instance within the cluster. Because the message includes the name of the callback queue, it doesn't matter which container, instance, node, whatever handles your request, because that service is the server-side data portal and will send the response back to the callback queue, so the caller gets the response.

Again, not "SOA", but with the same scalability, reliability, fault-tolerance characteristics that most people are looking for in a service-oriented system. Without the headaches that normally come with being service-oriented.

[rockfordlhotka]

Or perhaps, to more specifically answer your question, right now the following data portal channels exist:

• HTTP
• gRPC
• RabbitMQ

And in legacy .NET Framework

• Enterprise Services (COM+)
• WCF

And if you dust off some old code

• asmx
• Remoting

And, as I note in the previous post, you can fairly easily create your own data portal channel for any protocol based on the existing HttpProxy, GrpcProxy, and RabbitmqProxy implementations.

[aprokopyev]

Thank you very much for your explanation.

It would be easy to scale nHibernate vertically up to some level by adding more power just to a single node, also it is possible to add L2 cache with redis cluster on other several hosts.

But how DataPortal with nHibernate or other ORM can be used in several processes/containers simultaneously to avoid its L1 cache inconsistency in different instances? How such DataPortal instances can be scaled horizontaly by adding more DataPortal nodes without adding caching at level 2?

[rockfordlhotka]

It is important to understand that the server-side data portal interacts with your data access layer (DAL), but doesn't really care, or dictate, how your DAL works.

In a k8s scenario, the data portal will be typically hosted as a deployment with n pods, fronted by either a service or listening in a queue. Either way, at scale, there'll probably be 1+ instances of the data portal running somewhere in your cluster.

Again, the data portal is not your DAL, it just interacts with your DAL. So if your DAL is implemented with nHibernate, EF, Dapper, ADO.NET, or whatever, that is your call. Similarly, if your DAL implements caching, that is your call.

A fairly common way to cache data these days is via REDIS. So I'll use that as an example.

Your DAL could be implemented to attempt to answer queries from REDIS, and if the data isn't there, then it would get the data from the database, loading it into the REDIS cache and returning it to the caller.

This offloads the complexity of a distributed cache to REDIS, which would be installed and running as a workload in your k8s cluster. Very comparable to running RabbitMQ as a workload in your cluster.

Assuming your REDIS workload was installed and configured properly, it'll provide a distributed cache across your cluster's nodes, and it manages its own consistency across the cache, so your DAL code doesn't need to worry about it.

[aprokopyev]

For example if I have following config:

CSLA Application->DataPortal->nHibernate DAL on a single hostD ->
Redis cluster for NH L2 cache -> some type of DBMS cluster, may be even IBM DB2 pureScale

I cannot understand what to do when DAL hostD cannot sustain its load anymore (most likely CPU or may be RAM too are at their max utilization) and cannot be upgraded if it has already a maximum resource configuration available in a hosting facility?

May be load for DAL host can be devided and spread among several DAL hosts by some criteria too? I guess it shall be very application specific, for example if DAL1,2,etc. are able to work only with a part of some large table without needing to access other parts? For example if could be achieved even by speading by EntityId mod DAL_server_num or something like it? Then aplication shall be self broker for requests to a correct DAL host?

Would not it be nice to have a nHibernate dialect for Tarantool DBMS which is very fast and still provides ACID and other features of a general DBMS?

[rockfordlhotka]

You are using jargon I don't understand.

The server-side data portal is designed to be stateless, specifically so you can have multiple instances of the server if desired; that way you can scale horizontally and spread the load across multiple nodes. In Kubernetes you just set the replicas value to 2 or higher and let the cluster load balance pods across multiple nodes in your cluster.

That's where something like REDIS cache becomes important, because if you are doing caching then you want the cache to be consistent across multiple data portal server pods, and that's what REDIS provides.