6 myths about Service Fabric
More than a year has passed since the release of Service Fabric, and many misunderstandings have arisen around it, arising from misunderstanding on key issues. While I was preparing for our new OpenHack and communicating with partners, I saw an article in which the author gathered together all the key myths and dispelled them. She inspired me so much that I decided to translate it for you.
Communicating with different companies, I heard all the variations of what a Service Fabric is and what it is not. At its core, this is a deployment management system. The system creates a versioned, deployment-ready application to send to the associated set of system resources. The servers in the system have no names and you can consider them as a set of resources. So instead of sending your application to a specific machine, you simply send it to the cluster. It already controls where to place these services in order to evenly distribute the load among the available resources. Service Fabric also manages deployment rollback if the service is not initialized.
Microsoft is a company that likes to give developers "simple buttons." This is one of the things that I like when working with their products. They have smart engineers who solve complex infrastructural problems in products, so that you don’t need to deal with them. Service Fabric is one such product. The Service Fabric SDK contains an excellent set of tools for building large, complex systems. It allows you to do this without a lot of normal overhead and saves time for thinking about what and how to do. Interservice communication, distributed patterns, scaling patterns, service detection - everything is already built in. So stop redoing it again and again and again.
')
Do you have your own communication stack? Just do not like Microsoft? Great news! You do not need to use their SDK. None of them, really. You can use any communication stack, any communication protocol or technology. All you need is to register your application so that it is located through the name service.
Cheeeeeoooooo? I know it looks eccentric to Microsoft, but you can really run Service Fabric on Linux. You can also run a Java, Node, Ruby, or any other language you want to use on Service Fabric. Because, remember, by its very nature, this is a deployment management system.
It is assumed that you must have Azure to use a Service Fabric, which does not even come close to reality. You can use Service Fabric in your own data center or in any other cloud infrastructure provider. Of course, in this case you will have to manage your own cluster independently, but this is an understandable compromise.
If I hear someone say, “I would not use Service Fabric, because I use containers,” I start screaming. I see many problems with the current understanding of container technology in general, which is beyond the scope of this article. But if you really think that containers are what you absolutely need (email me on LinkedIn, I will be glad to know why you think so), just know that you can use Service Fabric to manage the deployment of containers, as well as the deployment of your applications. Service Fabric has excellent support for containers, despite the fact that containers still do not solve 99% of the difficulties of creating a distributed system with dependencies of execution time. Service Fabric SDK solves these difficulties.
As I wrote before the kata, we are now actively preparing for a new format of events - a three-day interactive practical workshop - OpenHack . It will be held in Moscow on March 22-24. If you are interested in “touching” and learning how to work with containers and microservices, join us. Everything is as always free, without SMS, but with registration .
What is Service Fabric in reality?
Communicating with different companies, I heard all the variations of what a Service Fabric is and what it is not. At its core, this is a deployment management system. The system creates a versioned, deployment-ready application to send to the associated set of system resources. The servers in the system have no names and you can consider them as a set of resources. So instead of sending your application to a specific machine, you simply send it to the cluster. It already controls where to place these services in order to evenly distribute the load among the available resources. Service Fabric also manages deployment rollback if the service is not initialized.
Service Fabric is an SDK for microservices
Microsoft is a company that likes to give developers "simple buttons." This is one of the things that I like when working with their products. They have smart engineers who solve complex infrastructural problems in products, so that you don’t need to deal with them. Service Fabric is one such product. The Service Fabric SDK contains an excellent set of tools for building large, complex systems. It allows you to do this without a lot of normal overhead and saves time for thinking about what and how to do. Interservice communication, distributed patterns, scaling patterns, service detection - everything is already built in. So stop redoing it again and again and again.
')
You do not need to use this SDK.
Do you have your own communication stack? Just do not like Microsoft? Great news! You do not need to use their SDK. None of them, really. You can use any communication stack, any communication protocol or technology. All you need is to register your application so that it is located through the name service.
You do not need to use .NET or Windows
Cheeeeeoooooo? I know it looks eccentric to Microsoft, but you can really run Service Fabric on Linux. You can also run a Java, Node, Ruby, or any other language you want to use on Service Fabric. Because, remember, by its very nature, this is a deployment management system.
You can use Service Fabric in your datacenter, in Azure or AWS
It is assumed that you must have Azure to use a Service Fabric, which does not even come close to reality. You can use Service Fabric in your own data center or in any other cloud infrastructure provider. Of course, in this case you will have to manage your own cluster independently, but this is an understandable compromise.
You can use containers
If I hear someone say, “I would not use Service Fabric, because I use containers,” I start screaming. I see many problems with the current understanding of container technology in general, which is beyond the scope of this article. But if you really think that containers are what you absolutely need (email me on LinkedIn, I will be glad to know why you think so), just know that you can use Service Fabric to manage the deployment of containers, as well as the deployment of your applications. Service Fabric has excellent support for containers, despite the fact that containers still do not solve 99% of the difficulties of creating a distributed system with dependencies of execution time. Service Fabric SDK solves these difficulties.
As I wrote before the kata, we are now actively preparing for a new format of events - a three-day interactive practical workshop - OpenHack . It will be held in Moscow on March 22-24. If you are interested in “touching” and learning how to work with containers and microservices, join us. Everything is as always free, without SMS, but with registration .
Source: https://habr.com/ru/post/350982/
All Articles