Packaging System for Applications & Services
Currently, Fabric apps are folders containing Fabric services, tied together by a manifest and Fabric services are folders containing packages (code, config, data), tied together by another manifest.
This works alright when apps and services are developed within a company/team and not broadly distributed, but it falls apart when trying to distributed things more broadly.
For example, what if I wanted to distributed fabric versions of Redis, Elastic Search, or Orleans?
This proposal is to create a system which lets us package and distribute applications and services similarly to NuGet.
Reuben Bond
shared this idea
7 comments
-
Alex Stracker
commented
Haishi Bai (Microsoft) has built SFNuget which does the trick: http://haishibai.blogspot.co.at/2016/08/how-is-it-made-nginx-as-pre-packaged.html
Unfortunately there are not many "public" packages yet on nuget: https://www.nuget.org/packages?q=sfnuget
-
Facundo
commented
If the solution is use Docker to build container images and use Service Fabric as an orchestrator of containers, then might as well use Azure Container Service and Kubernetes.
-
Christopher Boarman
commented
Won't this be solved with support of Docker Windows container images, assuming said images can be deployed directly to the Fabric?
-
Alex Stracker
commented
There are 2 reasons why I would be keen having this feature:
1) I've made bad expereinces with Visual Studio Solutions that contained >30 of projects.
So we are working with several smaller Solutions with CI-Builds on VSTS and our final artefacts are Nuget-Packages (these are automatically released to our private Nuget-Server).
It would be really cool if there would be a VS-Solution that describes all the Services that are pulled from Nuget-Packages (= our Microservices) that describe the Integration-tested and versioned Application.2) I think it would be really cool if the community would get the chance to prepare Packages (with guest-executables) that allow us to run things like Redis, ElasticSearch, Couch DB, Mongo DB with little effort
...on the Service-Fabric-Cluster - close to the Services. -
Nicholas Lechnowskyj
commented
We don't use one application > multiple services because this creates a dependency that microservices conceptually attempt to avoid. Each service is a completely independent unit, they have their own git repository, solution, build and release definitions. If you use one application and just want to deploy one service you'd have to share a common application manifest which I think is a big no no. So in other words we have 30 applications with 1 service inside each of them.
As with most things, Microsoft is trying to support multiple use cases and fast time to delivery, however Service Fabric is an enterprise tool so I'm not sure why they are supporting "small mom and pop" use cases. If you're using Service Fabric and deploying to a Production environment from Visual Studio for instance that is absolutely ridiculous and honestly annoying that Microsoft actually spent the time to build out that type of tooling. It only serves to confuse people new to the platform and unsure of what best practices are.
-
Christian Weiss
commented
I think there's no real disadvantage in having multiple >applications< in ServiceFabric, so in case of distributed teams you could create separate applications.
However I do agree that there should be tooling support for >publishing< one/some services from your application. It would be great if you could select the services you would like to publish in the Visual Studio publish dialog.
-
Vassil Kovatchev
commented
This is a must if you are going to call Azure Service Fabric a microservices development platform.
One of the main reasons people move from monolithic to microservices architectures is to allow for the work to be split across loosely coupled teams who can develop and release services independently from each other.