Open allanFunrock opened 6 years ago
Agreed and frankly if statefulnes is not support, I personally would considering to go to k8s instead because the ecosystem is bigger there for now.
The biggest advantage for Mesh would be that it abstracts away my cluster (which is a very big step)
The plan is to support the stateful programming models, but it would take some time to abstract away the cluster specific contexts from the models and make it ready for multi-tenant environment. We will provide some migration path but we do not have details on what it would look like at this time.
So does this mean that those of making heavy use of Remoting and Reliable Collections will not be able to use the SeaBreeze/Service Fabric Mesh any time soon? This is a major blocker for our project.
@idg10 Our current intention is to provide the same capabilities from a developers point of view in the "clusterless" experience (Mesh) as you have in clusters.
Can you shed some more light to your statement about this being a "major blocker"?
Our entire system is built on the current actor/service model so we'd have to do a very large rewrite if we were to adopt another model.
I suspect most existing systems on service fabric would consider a rewrite of that extent to be a blocker for upgrading
Good to hear it's coming though :) any hints or design docs on what it might look like? Just an aspiring.net middleware or something?
@allanFunrock for Reliable Collections, current thinking in asp.net core is what you consider.
To the larger point, knowing Mesh is an offering with no infrastructure control, at this point it cannot provide the granularity in control and density you can achieve in Service Fabric. I fully understand the wish to go from having to deal with servers to not deal with servers, but I'm interested in figuring out what would break or make the deal to move / not move.
Perhaps i'm misunderstanding what you're asking. But having to rewrite our entire system to not use actors and reliable services is what is blocking us from moving :)
@allanFunrock Yes - and we should definitely talk more. If you wouldn't mind sending an e-mail with contact info to mikhegn@microsoft.com, I'll reach out and it would be good to talk more about this.
Everybody else on the thread, please do the same :-)
@MikkelHegn to respond to your request for more info on how this is a "major blocker" all I mean is that our existing Service Fabric application makes heavy use of both Remoting and Reliable Collections. If Reliable Collections were to be unavailable in mesh, that would prevent us from using it (or at least would make it very expensive for us to move over).
Remoting would less work to live without, although I'd prefer it (or something like it) still to be available. (I've seen suggestions in a few places that one can "just use protobuf", but for us, the serialization isn't the hard part - if that were all SF Remoting did then we could dispense with it pretty quickly. The two bits we'd prefer not to have to recreate are cancellation support, and built-in support for talking to the right partition when you have a partitioned stateful reliable service.)
@allanFunrock and @idg10 - thank you for the insights. Let me know if you're interested in a follow-up call. Please just reach out via e-mail (see above).
I've got questions from customers about Mesh, and we always end up with the same conclusion that without Reliable Collections/Actors it's a show-stopper, at least for those who are already heavy SF users.
Mesh as managed infrastructure is just fine.
The new stuff looks really great!
However we're very heavily invested in the "old" programming models, actors in particular and reliable services (with remoting) as well. I understand there would be some modification needed, but what would the migration path be? I think a large majority of existing SF apps will be in a similar situation since the Actor/reliable service models have been pushed so heavily in the past.