Azure / service-fabric-mesh-preview

Service Fabric Mesh is the Service Fabric's serverless offering to enable developers to deploy containerized applications without managing infrastructure. Service Fabric Mesh , aka project “SeaBreeze” is currently available in private preview. This repository will be used for tracking bugs/feature requests as GitHub issues and for maintaining the latest documentation.
MIT License
82 stars 13 forks source link

Support for existing Service Fabric packages #127

Open ghost opened 6 years ago

ghost commented 6 years ago

Similar to the question about Kubernetes declarations, any thought given to supporting the Service Fabric cluster deployment model on Mesh, translating to Mesh native format behind the scenes? E.g. automatically containerize existing stateful and stateless applications; running existing containerized service packages, etc.

tomkerkhove commented 6 years ago

Interesting, do you mean as a transition period? Long term the current model will go away so that will be less interesting but I can see a benefit of having this as migration path.

mikkelhegn commented 6 years ago

@tomkerkhove - There are no plans for the manifest based model to go away. It provides a low-level control over apps, services and the cluster, which is useful in many scenarios. The biggest difference between that and the resource based model is the abstraction of the infrastructure, enabling these applications to run in a multi-tenant cluster environment.

@aaronla-ms We have a few options we want to look in to in more depth, but are focus on getting our public preview out at this point. The main thing, given what I wrote above, is that Reliable Services have access to cluster level operations and hooks in to the life-cycle of replicas etc.

Can you help me understand the main areas inside reliable services that you are relying on in your current applications? Reliable Collections and Queues? Metrics? etc.

ghost commented 6 years ago

@tomkerkhove Containerization is great for simplifying deployment and management, but our current apps are already "boxed up" in the sense that it's just a SF application to be dropped on a suitable cluster. We're mostly interested in the infra and devops savings of going serverless/clusterless. Many of our machines are near idle and exist just to hit minimum replica counts.

@MikkelHegn Just reliable collections and queues. However, incremental migration is a must-have for us.