These are chat archives for akkadotnet/akka.net

21st
Dec 2018
to11mtm
@to11mtm
Dec 21 2018 03:16

@cgstevens I almost feel like the two are on slightly different layers... Akka.NET with clustering can act as sort of a service mesh, but it looks like Istio is a higher level of abstraction.

IMHO, from an architectural standpoint Istio looks like it does a lot.... possibly too much. That's an opinionated statement, but concepts like Authentication should be handled at the API Gateway level and not at a service mesh level.

Also, looks like if you're not using Kubernetes... good luck?
(I don't trust google.)
to11mtm
@to11mtm
Dec 21 2018 03:24

(Broader opinionated statement) I'm always careful of libraries/frameworks that are backed by massive corps like Google/IBM (and even MS; see: EF). They have a lot of organizational/process strength to enforce rules that go with making large frameworks work well. Smaller shops, it's often a very difficult battle.

OTOH, This has been re-hammered into me because I'm on a team with only 4 devs in the entire company right now. ;_;

Bartosz Sypytkowski
@Horusiath
Dec 21 2018 08:04
@angrybug you can use different stores per actor type, but not per persistenceId, if this is what you are asking for
Peter Huang
@angrybug
Dec 21 2018 10:46
@Horusiath that's a shame - what would you suggest for multi-tenancy requirement like that, where the event store needs to be separate for each tenant? i was hoping there's some way for each actor instance to signal which store it should live in, but the design doesn't seem to allow that naturally. Would you say a better approach be to use the persistence store as a "temporary" event store, then replay it to separate the entries into the tenant-specific stores? (duplicated data etc)
On another note, how often do AkkaContrib pull requests get processed? I noticed the last one was in March for MongoDb persistence repo. Was hoping to not have to make our own nuget packages in private repo in the mean time.
Bartosz Sypytkowski
@Horusiath
Dec 21 2018 13:55
@angrybug it really depends on the people's occupation. I can review your PR eventually, but it's 2k lines of code and I'm pretty tight on time myself ;)
regarding multi-tenant event stores, you'd probably need something customized
Aaron Stannard
@Aaronontheweb
Dec 21 2018 18:01

After my demo at work I was ask how Akka.Net comes to service mesh. The implementation to compare is Istio

Honestly, Akka.NET eliminates the need for a lot of infrastructure like Istio

Istio and service mesh technologies in general are designed for making it easy to connect stateless microservices together, because these types of technologies inherently have no concept of "topology" built into them
(because they are stateless)
Akka.Cluster pushes topology awareness into every node inside the system, because fundamentally all of those services are peers in a peer-to-peer network
not stateless client-server services
therefore, I don't need a central point for looking up the address of services
knowing which nodes are up or down
or routing messages to them
this is all decentralized in Akka.Cluster - all of the data and infrastructure needed to do that is available locally on each node
the stuff Istio provides that you don't get out of the box with Akka.NET would be stuff like the access control policies and built-in tracing
Aaron Stannard
@Aaronontheweb
Dec 21 2018 18:06
in terms of what a large company needs, infrastructure-wise
if your company is thinking in terms of making it easy to form large networks of HTTP services that need to work together, Istio might be worth investing in - maybe. Depends on the number of services and developers working on it
Akka.Cluster is more for building fast, real-time services that work cooperatively together
you probably don't want a gigantic Akka.Cluster that every single possible service in your company is a part of
designs I've supported for large-scale adoption of Akka.NET look like having multiple clusters, one for each "product" within the company - that product usually consists of 4-10 services, and these clusters communicate with each other when necessary by either passing messages through something like Kafka or calling HTTP APIs on top of each other. This gives those products the ability to be maintained and managed by totally separate teams
this design also allows products that don't intrinsically need Akka.NET themselves to still benefit from having those clusters around - i.e. a CRUD service that needs to read some output from the cluster and serve it up to a reporting tool or an HTTP API
maybe integrating those clusters inside a service mesh would make sense for scenarios like that
I don't want to be too prescriptive and give any recommendations that sound like "always do X" or "never do Y"
Aaron Stannard
@Aaronontheweb
Dec 21 2018 18:11
so those are my thoughts on the subject
does that make sense @cgstevens ?
to11mtm
@to11mtm
Dec 21 2018 19:57
@Aaronontheweb Thanks for this, as we've been having discussions about Service meshes as well and Akka has come up but people worry about a distributed monolith. I wasn't able to put what you just said into words, but now I can at least use some of yours. ;)
Aaron Stannard
@Aaronontheweb
Dec 21 2018 20:37
@to11mtm happy to help
I abhor complexity in my infrastructure
I want as few moving parts as I can manage
so you wouldn't see me moving towards something like a big service mesh unless I had dozens and dozens of services that all needed to be exposed to each other
because my chief concern isn't really the technical side of things - it's the human cost part of the equation. It's yet another thing we have to standardize and train people on and manage during deployments
anyway, like I said - I don't really like making black and white recommendations because everyone's domain and situation are different