Productizing Orleans

[petroemil]

I haven't seen this discussion brought up before, but I think it's quite important in the long run. Orleans is a fantastic piece of software and should gain way more attention than it gets today, and I'd like to give some constructive (though sometimes harsh-sounding) suggestions that could help "productionising" Orleans.

Naming

The name "Orleans" is clearly just a codename and doesn't say anything to someone who first encounters it. I think a more reasonable name could be something as simple as "Actors" (with the root namespace being "Microsoft.Actors").

And then even people who are familiar with the Actor pattern, still have a bit of learning curve to switch their brains to focus on "Grains" and "Silos" instead of the well-known terms like "Actors" and "ActorHosts".

Being straightforward with the naming and following the universal language around the Actor pattern might be a bit boring (one could say), but it would make the framework easier to discover and understand (and it would also feel more professional, people wouldn't get the feeling that they are working with some kind of prototype project from a research lab with fancy codenames and funny naming of components).

Documentation

I know that there is a pretty good documentation available for Orleans, but I think it should also (or only) be made available on the official Microsoft Docs website for easier discoverability.

Integration

Orleans is not a standalone system, it requires external dependencies like the membership table and storage. I think it would be great to build a deeper Service Fabric integration ( #1059 ) and use that as the reference implementation (it could also mean the deprecation of the Reliable Actors in Service Fabric, but that's a different discussion).

Also samples for Docker Containers, Docker Swarm, Kubernetes and typical configurations should be provided - I know, I see, some of these are already available, I'm just mentioning them for the sake of completeness.

Project Templates

I know there is an effort ( #3587 ) to provide up-to-date project templates with the new 2.0 release that can be used from both VS and CLI, so I'm just mentioning it here, again, for the sake of completeness.

[jan-johansson-mr]

Hi,

I concur with your writing. I think (as you) it's important to make two references, one for Service Fabric and one for not Service Fabric. The move to support .NET Core is fantastic and make availability for Orleans on other ecosystems than Microsoft (remember that Orleans already has a .NET Framework implementation tied to Microsoft ecosystem), so with that in mind I think that both of these two views (Microsoft ecosystem and other ecosystem) are as important.

[jan-johansson-mr]

While at it :-)

With reference samples, I also think an architectural view is needed. I've been reading up on eShopOnContainers, a classical tiered solution that is great, bundled with great architectural descriptions (in PDF files).

I think it will be good to illustrate what architectural impact an actor based architecture has, and compare that to a classical tiered architecture.

The nice introduction document in this repository, with a single DB at the storage tier, with stateful actors in the middle tier actually begs the question - why use a DB at all? (Of course there will be reasons, but I think it'll be a good point from a pedagogical perspective).

[sergeybykov]

Thank you both for the thoughtful feedback and concrete suggestion!

Now let me push back on some of them :-)

The name "Orleans" is clearly just a codename and doesn't say anything to someone who first encounters it.

Well, there are many technologies with such "codename" names: Kafka, Spark, even Java. We hope that by now Orleans accrued enough brand recognition to stand on its own, without the need to rename it to something more enterprise friendly.

And then even people who are familiar with the Actor pattern, still have a bit of learning curve to switch their brains to focus on "Grains" and "Silos" instead of the well-known terms like "Actors" and "ActorHosts".

We've debated this quite a bit early on. There are two major factors here.

1) There are tons of various actor solutions and languages out there, but most of them are about local in-process actors. Orleans from its inception focused on distributed actors.

2) Orleans invented Virtual Actors, and their behavior is so different from the traditional actors (that are explicitly created and managed) that we thought that it would be better not to add to the "actor" terminology confusion.

Hence, we believe us using the term "grains" helps our customers understand that the Orleans model is different from, for example, Erlang or Akka. Another example is Erleans project that picked "grains" term as is.

I personally think it would be very confusing to rename "grains" to "actors" after 6 years of running grains in production and nearly 3 years on GitHub.

I agree with the rest.

I know that there is a pretty good documentation available for Orleans, but I think it should also (or only) be made available on the official Microsoft Docs website for easier discoverability.

That's definitely something we need to look into.

[petroemil]

Fair enough :)

But in this case I'd have another suggestion for just the Grains. I understand and accept that you want to very explicitly differentiate it from any other existing Actor implementation, but maybe, somehow, you should then provide this explanation, potentially with at least a high-level comparison with other Actor implementations, even without names, just focusing on the concept itself.

Right now the introduction documentation only says:

In Orleans, actors are called 'grains'

[sergeybykov]

I agree with that. An attempt to explain the difference was made in - http://dotnet.github.io/orleans/Documentation/Introduction.html#virtual-actors. Do you think it's too obscure and insufficient?

Right now the introduction documentation only says:

In Orleans, actors are called 'grains'

Ah, we totally missed the landing page! Need to fix it. Thanks for pointing it out.

In general, while revamping the documentation, we tried to move away from talking about actors, and use "grains" instead. We might have missed a few here and there. The tutorials though are behind in many aspects, including this one.

Do you think it'll be more clear if we eliminate all mentions of "actors" except for one section explaining virtual actors and their difference with traditional ones?

[petroemil]

Do you think it'll be more clear if we eliminate all mentions of "actors" except for one section explaining virtual actors and their difference with traditional ones?

Absolutely, yes, I think it can give the kind of clarity about the naming that I was looking for in the first place. Don't get me wrong, I understand what it is about, but I was trying to look at things from a newcomer's point of view, and those are the points I brought up that are not necessarily very clear.

[sergeybykov]

I opened #3625 to clean up the index page.

[AceHack]

I would say in any docker implementation follow the .NET core multi-arch docker pattern for easy support of both linux and windows.

https://github.com/dotnet/announcements/issues/14

[AceHack]

Also as someone who understands the difference between traditional actors and virtual actors I would like to say grains and silos are a huge turn off from this wonderful project. It does make the concepts seem foreign and hard to learn at first. To me grains and silos don't convey the concepts as desired. Maybe someting more like particles and space or the void. Although I must admit I just like the Actor name. It's not like these things are not actors, it's just they are actors that have a different lifetime management. Just like when dependency injection was introducted we didn't start calling objects something else because their lifetime managment was now different. :) That's just my 2 cents.

[AceHack]

I just wanted to say my above comment is ment with no disrespect. What you guys have built here is a wonderful technology and whatever you call it, it's great. Thanks for all you do.

[sublee]

After reading the above comments, I can respect why Orleans chose "Grain" instead of "Actor". Thanks for the clear explanation.

Can I get explanation about the name of "Silo" also? Of course, a silo is a container for grains in farming. But when I was learning Orleans, it was very confusing to understand the boundary among process and host. If its name was "GrainHost" or just "Host", it wouldn't be confusing.

[galvesribeiro]

@sublee a Silo is an Orleans host process. It is up to you if you want host 1 or N silos per host (physical machine, VM, container). Usually as a silo process can be CPU-hungry, we recommend 1 silo per "host".

[ghost]

We are marking this issue as stale due to the lack of activity in the past six months. If there is no further activity within two weeks, this issue will be closed. You can always create a new issue based on the guidelines provided in our pinned announcement.

[AceHack]

Bump

[ReubenBond]

What would you like to see happen here, @AceHack? It seems that there might be a few actionable items here, but we should separate the distinct ones into individual issues if we want to be able to make progress on them.

[ghost]

This issue has been marked stale for the past 30 and is being closed due to lack of activity.