search

dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
10.1k stars 2.03k forks source link

On-Premise Deployment without SDK #275

Closed davidpodhola closed 9 years ago

davidpodhola commented 9 years ago

We are happy to use Orleans in Sync.Today. Usually we are deploying Orleans using steps described in On-Premise Deployment and deploying Sync.Today from Chocolatey repository. Orleans deployement is done over VPN from admin's PC, Sync.Today from (private) Chocolatey repository. Do you think it would be possible/useful to create Chocolatey package from Orleans too? I already prepared one and I would be happy to share/publish/take care of/whatever if it makes sense. You can see the content by running choco install orleans -source http://sync-today-nuget.azurewebsites.net/nuget after you install Chocolatey.

The benefits:

jthelin commented 9 years ago

Yes, this is definitely something that would be very useful! To many people.

It is something that a few people have been experimenting with [along with some corresponding (experimental) scoop / homebrew / docker deployment packages] but never got the time to converge on a firm solution / proposal.

If you have already worked out the kinks and found soemthing that works for you, then I would definitely encourage you to post that as a pull request to start the discussion and share the choco-love ;)

Now that we seems to have many / most of the problems sorted out with the codegen tool / package integration in 1.0.5 NuGet's, we may not need to ship the ClientGenerator.exe in the "silo drop".

orleans v1.0.5
 ShimGen has successfully created a shim for ClientGenerator.exe
 ShimGen has successfully created a shim for OrleansManager.exe
 ShimGen has successfully created a shim for ClientGenerator.exe
 ShimGen has successfully created a shim for CounterControl.exe
 ShimGen has successfully created a shim for OrleansHost.exe
 ShimGen has successfully created a shim for OrleansManager.exe

However, that is a minor implementation detail we can talk about more later, along with such things as how we can integrate this it into the NuGet package build / publish workflow, which remains a very klunky process right now :sob:

gabikliot commented 9 years ago

@davidpodhola As Jorgen said, it would definitely be useful.

May I ask you 2 questions: 1) Is it OK to list Sync.Today as Orleans user here: https://github.com/dotnet/orleans/blob/master/misc/Projects-Applications-and-Companies-Using-Orleans.md 2) In your on-perm deployment, are you using Azure Table based membership or SQL server based membership (system store)?

davidpodhola commented 9 years ago

@jthelin cool, will remove ClientGenerator.exe, make it look better and submit a PR.

@gabikliot 1) of course, already created a PR 2) we just migrated about 5 midsized customers from our C#+PowerShell based solution and they all use on-prem SQL. However the small + some of the big are already fully migrated to the Azure so they will use the Azure Table one.

Since we are upgrading from our old 2013 C# version, there is still a lot of work ahead to be "100% Orleans positive", however the benefits are already clear and visible and I am sure mainly our SAP integration will be much better from both the customer/user and developer perspectives.

veikkoeeva commented 9 years ago

@davidpodhola Regarding SQL Server, I'll write some more specific thoughts tomorrow to #255. Feel free to point out anything you think should be taken into consideration.

gabikliot commented 9 years ago

Great! Thank you @davidpodhola. Please let us know how we can help to get you closer to "100% Orleans positive".

davidpodhola commented 9 years ago

@jthelin I added calling my CreateOrleansChocolateyPackage.bat to PostBuild.cmd, however I am still not sure, what to write to Chocolatey nuspec path to the compiled binaries. Any ideas? :confused: Thanks in advance! :smile:

sergeybykov commented 9 years ago

@davidpodhola This is very nice!

2) we just migrated about 5 midsized customers from our C#+PowerShell based solution and they all use on-prem SQL. However the small + some of the big are already fully migrated to the Azure so they will use the Azure Table one.

At the high risk of stating the obvious, I'll still stress that using of the Azure Table option for cluster membership is orthogonal to migration to Azure. One can create an Azure Storage account and run an on-premises deployment with it without/before migrating to Azure Compute. I presume that a storage account is a much cheaper, already highly available, and easy to manage option when compared to managing an op-prem SQL. Of course, if you are already running an on-prem SQL for other reason, the difference is much smaller.

davidpodhola commented 9 years ago

@sergeybykov thanks to reminding that!

The on-prem SQL I saw is usually required by an ERP so it is seen as an "automatically" selected option by the customer. Also according to my experience mid-size customers are usually pretty "pre-cloud-ish" running all their servers (Exchange etc.) on-prem and not willing to move to the cloud because of the potential "security" issues as they like to describe it. Just as a side note, they also do not upgrade because the solution they use "Simply Works TM" so we are regularly meeting Exchange 2007 there and I am still not sure how to handle SQL 2000 we are about to use at one customer. That is why we were also .NET 2.0 compatible with Sync.Today 2013, if I may add something to #273

Small and big customers are completely different story, they are usually much more TCO-sensitive and so adding Azure Storage would be probably the way thay would go either because it is easier for the IT department or simply overall cheaper then buying new licenses.

sergeybykov commented 9 years ago

@davidpodhola SQL 2000? I take my argument back. :-)

veikkoeeva commented 9 years ago

@sergeybykov @davidpodhola I have some experience on working various sized companies in Finland. One thing I see is that if there is data about persons (social security numbers), or other customer data, it is most likely stored to a high-security zone with isolated networks and so forth. The data storage is usually built on relational databases. Most likely Orleans would work side-by-side with existing technologies and use data from those, so there needs to be ensurance it wouldn't leaked out of the system in any way.

Even if that wasn't the case, at least here the IT infrastructure is outsource to service providers. Maybe more known names are CGI, CapGemini and somesuch. There are existing contracts and procedures on how to provision new databases and things move quite quickly. Anything other than that gets easily entangled to red tape, which easily means a sale lost or a sales cycle long enough not affordable to smaller companies. The buzzword of IoT is a yet another thing to consider with factory-floor equipment or moving machinery in conjunction various procedures, some of them induced by safety standards.

At Finnish Post the infrastructure was managed in-house (nowdays by IBM) and there was still significant resistance to anything other than chosen providers. Especially stiff resistance was if data storage was to be anything else than relational database, we (our department) did some POCs about using NoSQL technologies and they worked really well, but as far as I know, they didn't move much further than that -- even if TCO was lower and new prospects were opened. That was pretty much the name of the game, and it is in many places. Having a solid relational story here really helps.

sergeybykov commented 9 years ago

@veikkoeeva Thanks for the perspective. We haven't been exposed much to such markets. I see that even if no-SQL solutions like Azure Table for things like cluster membership are superior from technical perspective, the business realities may push for SQL-based options. This is a great opportunity to improve and harden the SQL option.

davidpodhola commented 9 years ago

Not to forget I wanted to easy the deployment first, I submitted PR #303

@veikkoeeva thanks I lot, I think I completely understand and agree.

davidpodhola commented 9 years ago

Added the check for cpack.exe, now the Chocolatey package should not build if cpack.exe is not present see https://github.com/NaseUkolyCZ/orleans/commit/a0589a11671c13db86b810b86ba28dacdaf8b8fd

gabikliot commented 9 years ago

Seems like this issue can be closed - we now have the support for Chocolatey and SDK was deprecated altogether (both for on prem and cloud based deployments).