reubenbond

That document is outdated and was written with an Akka-centric view. The author from Akka's side of things, Roland Kuhn, has since moved on to Actyx, from what I can tell.

The doc predates ACID transactions support in Orleans, but it talks about the Virtual Actor model vs the Akka model in general.

I'm a core developer on Orleans. Feel free to ask any questions here, or on gitter: https://gitter.im/dotnet/orleans

I gave a talk recently on how we use it at Microsoft: https://www.youtube.com/watch?v=KhgYlvGLv9c - the talk is very short and so it does not go into many details, but it gives an overview of some internal use cases.

We (Orleans team) also stopped referring to them as actors some time ago for the same reason. The Orleans papers call them Virtual Actors or Grains. Usually, I describe grains as Distributed Objects.

Fixed, thanks for pointing that out. I didn't realize this was posted here.

Great! We need more freely available, open-source language learning apps. I made one for reading/typing mandarin on Android: https://github.com/ReubenBond/HanBaoBao / https://play.google.com/store/apps/details?id=com.tallogre.h...

Congrats on the launch!

Metrics monitoring is hugely useful for figuring out what's going wrong (or right...) and where - especially when you can slice and dice by dimensions/tags. Microsoft (where I work) uses lots of metrics internally, for every sevice. It's nice to see M3/Chronosphere making this kind of thing more affordable and widely accessible.

`var` is entirely syntactic sugar (compile-time type inference) and there's no runtime cost associated with it.

I find it makes most (but not all) code more readable, particularly given that we have great IDEs/tooling in the .NET world.

I feel I need to clarify this - my post is aimed specifically at optimizing code for high performance. Many of those tips will reduce readability of the code, which may make it harder to determine its correctness.

I'm a big fan of LINQ and I use it in my own code, just not in the high-perf bits. LINQ is great for writing code which has "obviously no deficiencies" in terms of correctness. Without it your code may end up having "no obvious deficiencies".

I also like LinqFaster, LinqAF and these other libraries/tools which can make LINQ usable in more domains.

.NET Core support is in the 2.0 Technical Preview builds, which you can access using this MyGet feed: https://dotnet.myget.org/gallery/orleans-prerelease (see blog: https://blogs.msdn.microsoft.com/orleans/2017/03/02/orleans-...)

From the Readme, it seems they do:

> LIKQ is powering Academic Graph Search API, which is part of Microsoft Cognitive Services.

PowerShell is underrated. For those who haven't tried it:

* It's part-REPL, part-shell

* In addition to plain text, you can pipe objects between cmdlets

* Integrating with .NET dlls is very easy

* Objects can be represented as directories using a provider model (eg, navigate the windows registry: cd HKLM:\Software\Microsoft)

On the other hand, I always found asynchrony/concurrency in PS to be a PITA. I wish it had async/await.

For an example of how to write a PowerShell module, check out this PR on Orleans (open source .NET virtual actor framework) which lets you call into remote actors: https://github.com/dotnet/orleans/pull/1990

In this case you can: Orbit (by Bioware/EA) for the JVM also implements the Virtual Actor model. Hopefully other frameworks will adopt the model, too. Orbit: https://github.com/orbit/orbit

Back when this was an internal MS project (and I was working there, on another team), I believe the icon for the Orleans (internal) nugets and the demo apps was the Mardi Gras flag, which suggests that it's named after New Orleans. I might be misremembering.

> I think the Microsoft Azure Service Fabric is cloud version of the orleans might be originated from this framework(I may be wrong)

Service Fabric is a confusing beast. It includes a Virtual Actor runtime which is indeed very heavily inspired from Orleans, but it is a reimplementation. Orleans is built for "cloud" scenarios. You can run Orleans on top of Service Fabric using a host I wrote: https://github.com/OrleansContrib/OrleansFabricSilo

Orleans calls them grains to differentiate them from actors in the Akka/Erlang sense - because they are Virtual Actors, rather than traditional actors.

Yes, the same kind of logging - transaction logging.

It's common at Microsoft to sign off on a code review with "LGTM".

I also previously worked for Microsoft (Azure Active Directory). We took code quality very seriously. All new features required at least 80% code coverage from tests before commit (not a particularly high bar, but a pragmatic one). New features also required a test plan + review covering stress/perf, unit, integration, & system tests. Many features required threat models which were reviewed with the security team.

Progress/bugs were reviewed weekly at ship room. Live site issues were reviewed the next morning (involving the relevant on-call engineers).

So as with any large company which isn't a monoculture, things vary from team to team.

Also, calling them "M$" in 2016?

Akka persistence is different. It doesn't give you managed lifecycles like in the Virtual Actor model - so you aren't insulated from failures and you still have to consider when to create/recreate an actor. It gives you Event Sourcing / Command Sourcing (depending on how you use it).

ES is a work-in-progress for Orleans, but many of us are using our own ES systems.

For an implementation of Virtual Actors on the JVM, check out Orbit from Electronic Arts / BioWare: http://orbit.bioware.com/

The first Orleans paper is from 2009 or 2010, so I don't think they are reinventing riak core.

The Virtual Actor model implemented in Orleans differs from what OTP & Akka offer in that Virtual Actors have managed lifecycles and are never created or destroyed. Instead, they are activated when needed (fetching state from storage if needed) and deactivated when idle.

This helps you to reason about your system. You can never know if a node will fail at any point in time (in any system), but with Orleans you can be sure that an actor will be reactivated on a surviving node in event of a failure. In other words, you can continually message actor X without worrying about ever having to reinstantiate it on another node due to failure.

By default, Orleans maintains an eventually consistent mapping of actors to nodes (called silos) and relies on the storage layer to give strong consistency. Most of the default storage providers offer strong consistency.

By the way, Service Fabric includes an implementation of Virtual Actors which differ in a couple of ways: 1. The actors are placed using consistent hashing. Actor Ids are mapped to a range of partitions, the replicas of which can be moved between nodes in case of failure. 2. Actor state is physically stored on the actor node by default. Because Service Fabric uses distributed consensus to implement stateful services, they can persist each actors state in the partition which it belongs to. The state is replicated to a quorum of replicas on each write.

What boilerplate is that? Grain state interfaces are better now, and the Roslyn-based runtime code generator (https://github.com/dotnet/orleans/pull/528) is so close to being merged (so you don't have to include anything in your .csproj, even though that's automatic with the NuGet packages).

Whatever it is, maybe we can fix it?

The half-assed actor project mentioned by the article is probably ActorFx - which is an interesting project with some cool ideas. For exammple, you could write actors in a mix of languages like Python, JS, & C#. It had automatic state replication after each turn. Actors were observable, Rx-style. Actor behavior could be specified at runtime: you could effectively throw a JS closure into the cluster and it create an actor out of it.

I wonder, though why it became stagnant so soon and never gained momentum. I'm don't know, but I have a theory. The team were using some tech which was semi-secret at the time, which they weren't allowed to talk about: Service Fabric (known as Windows Fabric at the time). Fabric was in use in projects like Lync Server and Service Bus Server, but no one could talk openly about it.

How can you develop an open-source distributed system without being able to mention the framework which makes it all possible? Fabric handles ActorFx' high availability, service discovery, code distribution/upgrades, and their state replication. It's pretty difficult... Forum posts asking what this fabric thing was went unanswered and the people who may have been interested in ActorFx just moved on.

Regarding Orleans, there were probably a couple of internal actor frameworks in use at some large .NET houses, but they were never released to the public. I think it was more of a cultural issue than a lack of devs: .NET devs weren't used to sharing code.

Things are getting better. The community around Orleans is great (come join us on Gitter! https://gitter.im/dotnet/orleans) and the ecosystem as a whole feels to be gaining momentum.

This is certainly very interesting. I wonder what kind of replication they are using (on mobile, didn't check, looks like 2PC).

Curious to see how this is related to Service Fabric, which shares many of the same goals. Fabric seems more mature (very well battle tested), but this has some interesting concepts around accessibility.

Windows (Phone) has this feature called "Wi-Fi Sense". It shares wifi passwords with your Facebook/Skype/etc friends. I've never used it to share with other people, because not many people have Windows Phone, but it's nice that it syncs passwords between my own stuff.

Looks like this: http://imgur.com/ShQvqAU

What is a good alternative to WCF if I want Binary+TCP. I used WCF in the past and didn't have trouble with it, but there is seething hatred for it in this thread.

For the record, I eschewed XML configuration for code and instead of supporting a range of protocols/transports, I used binary over TCP.

Service Fabric does this. You provide the stream of operations and Fabric replicates them using distributed consensus.

Databases can be hosted on the framework. DocumentDB is, for example. While at MS, I wrote a near-real-time metrics system using Fabric and worked on a tunable-consistency distributed cache built on Fabric.

Summary of Service Fabric here: http://daprlabs.com/blog/blog/2015/04/30/service-fabric-2/

I'm not in the know here, but maybe M-Brace is vaguely similar. Unsure about the optimization part. http://www.m-brace.net/

Microsoft bothered with the visa headaches for me when I interned from Australia. It makes sense, too: internships lead to full-time positions.

To be fair, this has been around for many years within Microsoft under the name Windows Fabric. I'm not sure how old the python lib is, but the other one is much newer.