Orleans and Cloud Service Providers

[galvesribeiro]

Although Orleans can run perfectly on-premises and on any other Cloud Service Provider (CSP), I saw people asking about having a deeper/transparent integration with those CSPs by leverage their service offers.

This issue will track a series of issues that will implement minimal providers like the ones already created for Azure but instead, targeting other major CSPs:

• Amazon Web Services (AWS) - Amazon AWS integration #2006
• Google Cloud Platform (GCP) - Google Cloud Platform (GCP) integration #2057

Feel free to make suggestions of other major CSPs to be included on this list or if you wish to contribute on those. Discussions about an specific CSP's provider implementation please keep inside its linked issue.

Lets put Orleans to run everywhere! 💃

[gabikliot]

This is great!
It is of course not new, we have been talking about it a lot in the past (e.g., #473).
Also, some work have already been done in the GCP space (#1174 - Google Protobuf, part of OrleansGoogleUtils).
This line of work will take the framework to the next level and unblock a great potential of application mobility across cloud providers.

[galvesribeiro]

@gabikliot Yep, I already saw the google part, I just started with AWS cause I have someone that want to use Orleans here but they are 100% on AWS so I just want to get them started asap.

When the time comes, I will get to google as well :)

[galvesribeiro]

Ok... As much as I want that providers to reach the main branch and support the major CSP player, I'm dropping this issue and all its related PRs and closing it.

The reason is that after a long discussion with the core team (as much as I don't agree with the decision), the decision was to move it to OrleansContrib. By doing that, it will slow down the development of those components and I have no time/resource to invest on it. The reason it will slow down is that in order to properly test the whole providers we will need the internal tests from the main repo and we can't do that in a manageable way by having it on OrleansContrib.

I feel sad about that and I still believe Orleans should reach other CSPs easily. Thanks to everyone who contributed with either comments or reviews on the related issues/PRs, but I'll drop this engagement since I have another higher priority and time consuming engagements on Orleans like .Net Core support.

I hope eveyone understand. Thanks.

[gabikliot]

I am really disappointed and frustrated by that decision as well.
You listed all the exact reasons why I believe it should be in the main repo.
We already have ZK, and Consul and SQL in the main repo. Why AWS/GCP are different?

Mostly, the biggest mistake is the lost opportunity. Almost no one ever talks about the lost opportunity, about "what could have been if I made the right decision" (an example of a lost opportunity - SF have Orleans Actors 3 years ago). But the real visionary and strategic thinking is about not loosing the opportunity. In this case - more .NET apps beyond Azure; potential huge uptake by other communities that are not aware of Orleans; ...
And the cost to have that opportunity - a bit bigger main repo? Poor internal tooling (manual braches syncs, better code sharing between repos) dictating the platform capabilities and forcing us to loose this potential opportunity?
That would not have been the decision I would have made.

[galvesribeiro]

@gabikliot I agree with you... Like I said... As much as I don't agreed with them, they explained their point. Sadly, it is not what we want.

I'm not trying to extend a debate here. I've already put my point to the core team which is the same as yours and that was their decision.

I wish I could have time/resources to do it outside so I can at least help people that asked for the AWS support for now but like I said, that is something I don't have Today unfortunately.

[jdom]

I'd like to clarify this a little bit with more context.
The reason we decided not to merge this PR yet is because we still don't have a customer who is vested in using it production and hardening it. We would need this to be a little bit more stable (proven) before we can start supporting it.
We are not dismissing this feature at all. As curators of the project, we just need to guarantee some quality of what we release.
Other similar external dependencies that not all of the committers are very familiar with -like ZooKeeper, SQL, etc- had customers already using them and vested in them before we made them part of the main repo.
We are also doing this with things that come from internal MS teams (like MSR and 343i). That's one reason why merging the multi-cluster PRs is taking so long. Some people are already using it even before all the PRs are merged. The same thing with the EventHub stream provider, and countless others.

Adding these dependencies would introduce a huge new testing area that we just don't have the bandwidth to handle in the short time frame that @galvesribeiro expects, and that's why we rely on the community to help us get there. I was just pushing back on the ask for "merging this PR fast so that @galvesribeiro can work on the next set of related PRs".
As an option to get this stabilized, I suggested publishing to OrleansContrib so that we can have nuget packages being released and people can start using the feature. In the meantime the PR could stay open on hold (or closed temporarily, I have no opinion here) until the feature is hardened. During this hardening period we will definitely point people to it and give it as much visibility as we can, as we DO want the feature to be merged.

So in short, we should not cut this feature. We should just be diligent and not throw it in and hope that it works.
@galvesribeiro said he's building this but not planning on using it. Let's find a proper vehicle to get this feature more mature.

[galvesribeiro]

IMHO, if we don't have the feature, we don't have the users. For example, the one I was trying to help is sad but will not use Orleans anymore since it doesn't play with AWS.

But again, points taken and lets not make this issue a big debate.

Let's move forward.

[jdom]

Let's keep talking in private. We can get together with them in a Skype call and work with them. If we can have them be the vested customer, awesome, that's what we need to get this feature validated and eventually merged.

[galvesribeiro]

OK. More one thing... Before anyone ask, the decision to drop it is mine, and mine only. Because I don't have time and resources to make a full test set external to Orleans main. By having it on main solution, I could leverage the current test infrastructure which would cut a lot of time and that is why I decided to start this at first place. So there is no implicit meaning here that "Orleans core team doesn't want other CSPs". If someone else can do it, please reopen the issue and move forward.

[gabikliot]

Let me suggest a compromise.

1. Definitely, we should NOT be "merging this PR fast". We should use the same high quality bar that we use for any other PR. This goes without saying.
2. My recommendation is to start with the membership provider. I will review it thoroughly, at the same level of due-diligence I did for other membership providers (Consul and ZK and Cassandra).
3. We were pretty fast and efficient in accepting ZK and Consul mbr providers and I see no reason to why we can't do it here at the same high level of quality and speed as before. I estimate that we can have the MBR provider be merged within a week at most, maybe faster depending on how fast we iterate.
4. We will have the same level of testing for AWS provider as ZK/Consul (manually run tests, no automatic since all of those require pre-installed dependent services).
5. We have roughly the same level of commitment from @galvesribeiro w.r.t future customer as we had from @PaulNorth about Consul and @shayhatsor about ZK. No one can commit for 100%, but we know @galvesribeiro and I trust he will keep supporting this code in the future.
6. MOSTLY important: there is zero risk merging this PR, since it does not change a single line in main Orleans binaries, it is 100% pluggeable external provider, thus is can not destabilize the rest of Orleans. This is VERY different from the Geo code which changes key internal components, and thus of course has to be reviewed and vetted with much more care. That is not to say that anyone suggested that the AWS MBR provider to compromise on the general high quality bar. As I said already, I promise to review it thoroughly, as I did before for other providers.
7. Once we are done with MBR, we can move to storage. Others (@shayhatsor , @ReubenBond, ... ) might help there. If not, I will review it as well.
8. I therefore see no risks for the project overall, or any concerns for the curators of the project. On the other hand, the cost of the loss opportunity is enormous in my opinion, as I wrote above.

[shayhatsor]

@galvesribeiro, I understand that you don't want a debate regarding this issue, but IMHO this is a very dangerous precedent.
I'll just share my experience, which is from both sides of the coin, as a developer and as a customer of Orleans.
I absolutely agree with you, this should be in the main repo. It can be tagged as a "beta" feature, it can also be undocumented and unsupported. This enhancement has a huge potential of opening Orleans to significant untapped markets.
When I implemented ZooKeeper membership provider, it was part of my company's evaluation process of Orleans (same as your situation). Had I got an answer like you got here, we'd probably go elsewhere. The amazing dedication of @gabikliot, @sergeybykov and others is still one of the biggest selling points of Orleans to date. I believe it tipped the scale towards building our entire SOA architecture around it.
About the stability/maturity of the provider, it takes time and it takes community support, which is what you get here. I don't see any difference between this provider and others. We review the hell out of it, hope for the best and fix as we encounter bugs.
The same stability/maturity arguments could have been made about any of the new providers, and a single company that's saying it might use Orleans shouldn't be the deciding factor whether a new provider should be added to the main repo. There aren't many people that are ready, willing and able to contribute, we should embrace them.
Where would Orleans be now had we sent everyone to OrleansContrib ?

[jason-bragg]

@shayhatsor, Please take a moment to reread @jdom’s post. We are very open to new providers. I find nothing in what @jdom stated that should give the impression that we’re unwelcoming to new changes.

We weren’t willing to rush the integration of this PR, which is what was requested.

We don’t have the background or bandwidth to maintain or harden this capability, so we preferred having a customer that had a vested interest in it, as we do with ZK, and SQL, both of which have been developed and maintained almost entirely by community members that use these systems in production.

No one has argued against the value of this contribution. We’re all very interested in widening the market for Orleans. If there is commitment from the community to shepherd these changes through the process and ensure it is hardened and production ready, we’d love to see that happen. Without such community support and commitment, however, OrleansContrib would be a better location. @jdom has stated nothing contrary to this.

@gabikliot’s ‘compromise’ is great, though it’s not really a compromise from our perspective as much as an addressing of the concerns we had about the contribution.

I thank @galvesribeiro for the contribution and @gabikliot for taking the time to shepherd it through the process.

[jdom]

This is exactly my point: @gabikliot's compromise isn't really a compromise, it's the expectation I had and conveyed to @galvesribeiro in the first place. He did not want to start a debate and rushed to close the PRs without a lot of info, which misled the rest into thinking it was due to the nature of the feature itself.
All I asked was that we can't just rush the PR in and get it merged as @galvesribeiro asked me several times to do (so he could work on the next few PRs). This happened in some of the PRs themselves, as well as on gitter chat (public and private conversations).
Also, compared to other initiatives, @galvesribeiro built this not to use it himself, but as something that might help someone else (for what we know with zero commitment to even try it out once, and we do not know whether they'll contribute back to harden it, or at least I knew of no commitment). This is not a reason to dismiss the help, on the contrary, I'm thankful for @galvesribeiro's drive, as this is not just potentially useful for this other person, but to many more. All I asked is that we'd need to find someone who'll at least try it (not just see that the BVTs turn green in Jenkins). If @gabikliot is that person, that is absolutely brilliant, as we trust he is a strong advocate for quality.
If we didn't have anyone responsible for using it, I suggested to either keep the PR open for longer reviewing (and don't try to rush it in), or publish it temporarily in OrleansContrib until we find that shepherd. Several people shared the idea of using OrleansContrib as a staging/experimental area until some new feature matures. I'm definitely not sending everyone to OrleansContrib to not have to deal with them.
I'm sorry there was miss-interpretation of something people thought we said.

[shayhatsor]

@jdom, I agree with your point. A feature like this must have a shepherd, at least till it becomes stable. I was under the impression that @galvesribeiro is willing to be that guy. This is the source of the misunderstanding. I apologize, I misread the situation.

[veikkoeeva]

For what its worth, we could keep PRs like this open and have a new tag that asks interested people to 👍 (those little emotics in the upper corner). This way the work can be rebased periodically and visibly
and someone who has a need and ability to put the effort could pick up work with lesser effort.

Also, this speaks to a degree that we don't trust our testing battery and infrastructure and that it's not easy to use the functionality outside of Orleans. Maybe we should put more effort it. One way could be to expose existing test sets and functions from testing libraries so that plugins/providers could be tested independently with data like Orleans would feed it in. There's been a bit work to that direction, maybe there should be more.

Then perhaps one discussion is what exactly should go to OrleansContrib and what to Orleans repo.

[gabikliot]

I am definitely not going to try running Orleans on AWS. I can review the code, and based on a prio experience with ZK and Consul I was able to catch most/all of the bugs just by code reviewing, but I never actually run Consul for example.
If/when we get into GCP, I will definitely try to help run it as well, and can be that future customer (or shepherd on behalf of one).

Doing things fast does not necessarily mean having a degraded quality. We can review it fast and still have the same level of quality as in other cases. My understanding was that @galvesribeiro was planning to be the one who will actually try to run it. If he was not even planning to run it, then its a different story. If he did, I think that is good enough even without the 100% commitment from a future customer.

[shayhatsor]

two notes:

• the zookeeper membership provider was merged about a half a year before my company actually used it in production. I believe it's the expected flow for any company that has decided to develop with Orleans, since it takes time to assimilate a new technology, especially a new development paradigm.
• it's very hard to write a faulty membership provider or a faulty reminders provider that passes all the tests we currently have. I made sure of it.

[galvesribeiro]

Ok... things are getting way longer than I expected here so let me clarify 1 thing...

I never desired to bypass any process to "merge fast" in degradation of the review quality... I was hoping the review could be kept up as the speed I was pushing the PR (and that is what usually happen here).

My point was only one... I was trying to help a potential new company that has AWS contracts to use Orleans and then I said "hey, why just make it for AWS? Why can't I organize a series of contributions to push Orleans to other CSPs like Google?". I never asked for them to contribute back since it I thought it was MY contribution here and it would bring potential new users first from Amazon and later on from GCP.

The only thing I asked to merge (and as @gabikliot said is totally harmless to the core) is #2007 because DynamoDBDataManager.cs is used inside #2008 Membership provider and until I had #2007 merged, it will complicate the review of #2008 because all the commits from #2007 are pushed along #2008 - maybe my GIT noob-ish or the way it is suppose to work.

I was willing to contribute it not to make use of it myself, but to enable a new user to use it AND open Orleans to a whole branch of potential users. Following that, I was willing to work on GCP as well with @gabikliot help.

The point here that made me close the issue is that the core team has their opinion about having the PRs sit and wait until some customer can invest time to use it and contribute back to stabilize the provider. This position is what I don't agree. I believe that regardless if there is no users NOW, we should have other CSPs supported out-of-box so the user CAN use it. Like @shayhatsor mentioned, if there is no way to use ZK they would just walk away which is what the company I was trying to help just did. Again, nothing on that is related to Orleans team denying or avoiding add support to other GCPs. Their argument is just "lets wait to see a customer come in, and then invest time in it" which is precisely what I'm against to.

Again, this is my point of view and I don't speak for the team which has a different position as mine.

I'm not paid to be 100% of my time working in Orleans. I work in it when I can (1) because I use it and (2) because I believe in the project otherwise, I wouldn't fighting inside my own company to keep it after the whole company want to move to ServiceFabric for other business reasons.

Please, lets not keep fighting the team. This is the way they manage their internal resources and decide what is important/priority to invest time/resources and what isn't, and not a matter of whether they want or not another CSP.

@gabikliot just to point out why I started with the Grain State provider, is because (1) it is simple and (2) easier to test and lay down the foundation to talk with DynamoDB that would be eventually used by other PRs like MBR and Reminders.

If the paradigm of "having a customer to use it" is break and @gabikliot as anyone else want to help on reviewing it, I would be happy to re-open issue and contribute it to the project otherwise, move it to OrleansContrib is something that unfortunately I can't do just because I don't have time/resources to build a full test set there since I couldn't leverage the full test suite from master branch.

I hope that clarify my intentions and demystify any misunderstand about the Orleans team decision.

[jason-bragg]

I believe that regardless if there is no users NOW, we should have other GCPs supported out-of-box so the user CAN use it. Like @shayhatsor mentioned, if there is no way to use ZK they would just walk away which is what the company I was trying to help just did. Again, nothing on that is related to Orleans team denying or avoiding add support to other GCPs. Their argument is just "lets wait to see a customer come in, and then invest time in it" which is precisely what I'm against to.

We can debate the importance of our internal priorities vs. other feature sets important to the community, but we don’t really need to. The advantage of an open source project is that we have a built in litmus test for the importance of a feature: Is someone willing to develop and maintain it. Nothing more is necessary.

In the case of ZK, @shayhatsor demonstrated a willingness to develop and maintain the capabilities, so Orleans supports ZK. This is great, and we’re very grateful for the effort.

I completely understand the desire to build more features to draw more users, but we risk unused systems becoming out of date and not working. We’ve seen the difference in the quality of systems hardened by production use vs. those developed but rarely used. We also run the risk of developing and maintaining features we think others will want, and being wrong, missing out on other opportunities. Preferring new systems to have users, to me, seems a very reasonable means of avoiding these problems and having a degree of confidence that the systems will be maintained and hardened.

Having said all that, if anyone in the community is committed to these systems, willing to develop, harden, and maintain them, we welcome the contribution and are happy to help.

[gabikliot]

if anyone in the community is committed to these systems, willing to develop, harden, and maintain them, we welcome the contribution and are happy to help.

Jason, my understanding was that this is exactly what @galvesribeiro suggested to do: develop, harden (via code review and feedback from users) and maintain in the future. I am not sure what made you guys believe otherwise, that he is just "dumping" a bunch of untested code just for the sake of it?
Of course, he is not signing up with a contract to support it forever, just like anyone else here is not.

For example, consider this example:
@dVakulen decided to implement cancellation token support in #1599.

1. We had no actual customer asking for that (the whole idea was suggested by @veikkoeeva , as yet another nice to have feature).
2. we welcomed @dVakulen contribution.
3. I contributed numerous hours of reviewing it, there were 250 comments on that review, multiple and multiple iterations, plus the risk of destabilizing the runtime, since it made a number of changes in the heart of a key component, and yet
4. no one objected, we worked relentlessly, @dVakulen was extremely patient and goal-oriented to "drive the implementation home" and make it at the highest quality we could and I believe that we now have a pretty robust implementation of that feature. Still of course possible that we have bugs.
5. still no users, and only partial test coverage - unit tests, but not scale test.
6. Are we happy overall that we have this feature now? I think we are.

So based on your reasoning above, I should have refused to review #1599 since there are no customers? You should have told me that before I contributed numerous hours of reviewing it.

[ashkan-saeedi-mazdeh]

I think There are two issues being discussed here.
Let's not mix them up and don't make it confusing.

• First some people like at @galvesribeiro think and I think rightly think that supporting major environments should be a concern of Orleans team regardless of current customers if we want to move it to all environments really, and some like @jdom think it is better to focus resources elsewhere until some customer comes and want to use it + have the willingness to help us harden it. As an on premise user atm and future azure probably, I can not feel the pain of that right to speak about it .It 's ultimately about the main policy of the core team and their current priorities.
• The second point is that everyone agrees that high quality features should be in if they are useful in general and for this to happen good tests and review processes are needed and also the contributer should be willing to fix..

For the second one the real issue is not having externally usable test cases. For example for couchBase I'm writing a few tests myself but at the end probably should use all of the internal tests to be fully sure. I'm testing by hand and unit tests atm and storage works, am moving to membership. I plan to use this in production and use CouchBase only for everything.

but I'm doing this because I believe much in Orleans, Love it and am willing to spend the time on this particular project to do this all. Time and resources always don't allow. I'm doing this because having Orleans with configurable placement strategies is a strategic difference for a game backend. I'm doing this because I've been at Erlang's side for a bit and SF doesn't solve my problem in the most important part well but Orleans can potentially do it. I'm doing this because before coming to Orleans I knew actor model is the best way to solve these kinds of problems.

Other people might not do this all on their own specially if others like Google and Amazon start to provide SF like solutions, we want to lead these systems all , right! and if the answer is yes, we should be easy to try and use out of the box on all major environment so .NET core ftw, providers for all major environments and later on probably a standard protocol for talking to Orleans from external clients are very good steps. Of course improvements and features can not be stopped for these. We can lose users to Akka and Akka.net as well.

Not that we are in direct rivalry with them but at the end if we want to grow as a project, we should maximize quality people and projects to develop the framework more while MS and MSR guys push the novel ideas in. This is of course all IMHO

[jdom]

@gabikliot, it seems as you are talking as if you signed up to review or #2007 (the storage providers), which you explicitly said you did not really care, that you cared about reviewing the membership providers. @galvesribeiro was asking me to merge #2007 first so you could review the other PR. This was what I refused to do.
Also, with the example you mentioned about cancelation token, it is a great contribution in the same way that the DynamoDB providers have the potential to be, I never said the opposite nor asked the PR to be closed or dismissed. Nevertheless, to be fair, the cancelation token one was within the familiarity zone of every one of us, and our build system has the capability and necessary configuration to run automated tests for it. You were extremely thorough in your review, and combined with the countless times we run all the functional tests, load tests and reliability tests on our side, we were confident enough that it didn't destabilize the core, otherwise we wouldn't had merged it, and certainly not "fast so that we could work on an upcoming PR". Could more have been done to guarantee the quality of that PR we merged? Probably yes, but definitely not practical (you already mentioned it took a ton of time from several people and several iterations).
In this particular PR (2007) we did not have tests that would run automatically in the CI build, nor we had a single extra person yet who signed up for running some validation. It was just a matter of finding someone willing to put effort and time into making sure is good enough and met the quality bar.
The thread blew out of proportion unnecessarily because @galvesribeiro decided to close that and all related PRs without explanation, and wrong conclusions of what we might had said were drawn.
I hope this discussion finds a conclusion and we can all realize that we are all agreeing on how valuable these suggested features are, and put that into action. It's not fair to complain why others don't put their time into reviewing/validating a feature that one deems interesting when that person is not willing to put his own time in it. Let's find the people and get them together so that we can actually get these in.

[gabikliot]

I am ready to review #2007 as well, if reopened.

[veikkoeeva]

@jdom has a point here, but I wonder if we need to have a new label for work that might take arbitrary time. I don't think there is anything fundamentally wrong starting work and if it takes a longer time, especially if it's OK for other people to chim and amplify effort.

[galvesribeiro]

Ok... Will make some changes and reopen the PRs starting by #2007 and only do anything else after it is merged.

[shayhatsor]

@galvesribeiro, I'll also review #2007 (and obviously the membership and reminders PRs, just ping me when you're done). Note that @veikkoeeva has recently implemented and merged a completely rewritten ADO.NET storage provider, which IMHO makes him the best man for reviewing #2007. If I were you, I'd not merge it till he has time to take a look.

[MikeHardman]

If there's still a need for a customer willing to put the time in to properly exercise and harden an AWS implementation please put us on the list. We're a fair sized vehicle telematics company based in the UK and operating globally, we're building our first alpha of a realtime / reactive tracking platform to replace some of the harder to maintain aspects of our current offering. We're entirely sold on an Actor based approach for these components and after a few extremely positive spikes with Orleans over the past 6 months we're pushing ahead with a current target of the end of September to have a reasonable internal alpha running for further assessment by parties outside the development team.

I'm mostly dedicated over the next few weeks to piecing together a fairly complete AWS implementation for load testing where we'll be pushing telemetry from circa 1 million active vehicles and while I'd love to try and get a kinesis stream implementation in some kind of sensible shape, at this stage I'm not confident I'll be able to wrap my head entirely round how that'll sit with orleans streaming. We will however definitely be running on AWS with either a SimpleDB or DynamoDB store and quite possibly an S3 blob store for some of the more variably sized but less performance sensitive grains.

Apologies if this wasn't the right place to advertise these intentions, but I thought given the conversation here I'd at least like to let it be known that we're serious about using Orleans and we're currently fairly invested in the AWS PaaS in Europe and the US, and although I'm actively working to remove our hard dependency on various AWS offerings, it's unlikely we'll be moving to another provider any time soon.

[galvesribeiro]

Thanks @MikeHardman.

Good to know that you that you are going to use that. I should evolve more on the storage provider today. Ping me on gitter when you can so we can talk. Thanks

[pditterline]

Our company is using Orleans on the backend and will be using AWS, and I am currently also considering an Orleans Streams/Kinesis Stream Provider implementation for our telemetry system. If there is movement on that we would be very interested and would happily contribute.

We also want to run everything on Linux/CoreCLR in AWS, but that's a different issue. :)

[galvesribeiro]

@pditterline glad to know more people is coming :)

The Stream provider for Kinesis is on the radar. You, @MikeHardman and anyone interested on AWS can track on #2006 all related issues.

Regarding .Net Core, we are working #368 is the way to track it and we are working on that in parallel since it is not tied to any CSP.

Feel free to also ping us on Gitter.

See you there.

[sergeybykov]

I just read this thread after coming back. Selfishly glad I missed it while on vacation. Otherwise, I'm afraid my family would have complained. :-)

Reading it now, it is clear to me that this is an example of a misunderstanding between well-intended people that sometimes happen, especially when communicating in writing. I'm glad we have already figured it out.

I read #2045 before this one, and already commented there - #2045 (comment).

A general comment about OrleansAWSUtils .

It is great that we are adding direct and easy support for non-Azure clouds. Not only does this expand the "addressable market" and makes the codebase more portable, this also highlights and supports the important tenet of Orleans - that it runs anywhere you need, the way you need.

When we add similar direct support for GCP, we'll cover the "big three" players.

One thing that I think we need to be conscious of and communicate clearly is the current state of the project. Until somebody runs in production with a piece of tech, it's difficult to be sure that all major issues with it have been addressed.

In that light, I'm thinking that we should explicitly set the version of OrleansAWSUtils NuGet package to 1.0.0-beta or something like that, in order to communicate the state of it and set the expectations accordingly without slowing down iterations on the code. Once somebody confirms that they are using it in production, we'll promote it to the general version. I think we should have done the same with the initial version of OrleansSQLUtils , OrleansConsulUtils , etc., but we keep learning as we go.

Which seems to me pretty close to the conclusion here, and I even independently arrived to the same suggesting about a beta tag that @shayhatsor apparently already suggested.

@galvesribeiro Special thanks to you for taking the initiative and pushing for this. This is what makes our jobs best in the industry - because we get to collaborate with brilliant and passionate engineers all around the world that keep pushing for what it right.

Thanks to everyone who volunteered to help with this effort.

@MikeHardman @pditterline Thank you for sharing what your companies are doing with Orleans and your willingness to try this. Nothing beats hearing actual usage stories. If you are already running Orleans in production, please consider adding your company to http://dotnet.github.io/orleans/Who-Is-Using-Orleans.

[sergeybykov]

We already support Azure, AWS, and somewhat GCP. No need to track this as a separate issue anymore as new providers can be added to the main codebase or to OrleansContrib any time.