Service Fabric
Service Fabric is the most recommended micro-service architecture platform for .NET solutions. It gives flexibility to choose hardware configurations as well as the deployment platform. Service Fabric solutions can be deployed to Azure and any other cloud platform, like AWS and Google cloud as well, which makes it platform-independent. It gives ease of auto-scaling for any service by setting conditions for hardware/computation consumption or a timing schedule.
In terms of infrastructure security, it all depends on the security of the cloud on which the services are being deployed; typically, Azure Service Fabric cluster is totally secured by HTTPS, custom protocols and signed certificates.
Performance in Service Fabric is very high as inter-service communication is possible over remote and the reliable state stored with services is on the local disk of the same virtual machine on which the service is running which makes it fastest to access.
The availability is more than 99.99% for Service Fabric Cluster, and it takes no downtime to scale-up, scale-down or even to upgrade your application to a newer version.
The cost for Service Fabric in Azure Cloud is calculated as vCPU-S and Memory GB-S which makes it a little more costly in Azure but it is worth more than its cost if utilized in a better way.
Azure Functions
Azure Functions are serverless architecture by Microsoft Azure, that don’t give any command over the hardware being used to deploy, and are meant for independent tasks which don’t require much hassle of setting up the infrastructure. Serverless architecture makes it harder to communicate to another Azure Function other than the HTTP protocol as TCP or remoting is not possible.
These are auto-scalable up to 200 instances and can’t be scaled manually. All we can customize is its service plan.
The availability of Azure Functions is also more than 99.99% but at the time of upgrade/redeployment, it takes a bit of time to get them up.
The cost for Azure Functions is cheaper than any other service as it runs on the Consumption plan and also, it gives 400000 GBs and 1M Executions free every month.
Decision making
| Feature/Requirement |
Service Fabric |
Azure Functions |
Comments
|
| Security |
Higher |
Lower |
All AF are public to the web and inter-function calls are only over HTTP while SF gives flexibility of protocol and inter-service communication is possible under a VNET over remoting or TCP. |
| Development Efforts |
High |
Less |
It takes almost nothing to set up a development ready AF infrastructure but for SF it is a bit tricky and requires more development efforts. |
| Hardware control |
Higher |
Lesser |
AF doesn’t give any hardware access but SF lets us decide on VMs and their configurations. |
| Platform Independent |
Yes |
No |
AF can be deployed only with Azure but SF can be deployed in any cloud. |
| Availability |
Higher |
Lesser |
AF suffers from a cold-initialization problem whenever a new deployment is made, also if we use a consumption plan, it destroys all its running instances after a fixed time of no requests received which then requires a bit of time to serve the first request. SF keeps running all the way and makes sure at-least 3 instances of a service are always up. |
| State management |
Yes/Reliable |
No |
AF are purely stateless and can’t maintain any data. It is recommended to not use the static variables in Azure functions as they don’t guarantee to keep them alive. SF gives reliable services out of the box which can maintain plenty of data with reliable collections. |
| Recommendation for large size applications |
Yes |
No |
AF is meant for independent tasks as it doesn’t have any application pipeline to build Dependencies and their application lifetime is also shorter. SF is the best fit for any size of applications. |
| Scheduler Jobs |
Yes |
Yes |
AF gives out of the box CRON triggered Durable functions which can start over time and can run for hours. SF supports a number of libraries for the same. |
| Integration with webhooks |
Tricky |
Easy |
AF is developed in a manner to be attached with a number of webhooks for Azure Services. SF microservices need to be customized by a developer for receiving webhooks. |