We are on the heels of the first anniversary of the release of Service Fabric, but there are still a lot of misconceptions that I would like to clear up.
Talking with different companies, I’ve heard every sort of thought on what Service Fabric is and what Service Fabric isn’t. At its heart, it is really a deployment management system. It creates a versioned deployable app for you to send out to a connected network of system resources. The servers in the system don’t have names and you can think of them like cattle. So, instead of sending your application to a specific machine, you are just sending it to the cluster. It manages where to place these services in order to evenly distribute hotspots across available resources. Service Fabric also has managed deployment rollback should a service fail to initialize.
Microsoft, being the kind of company they are, likes to give developers “easy buttons.” This is one of the things I like about working with their products. They have smart people working on tough infrastructural problems so you don’t have to. Service Fabric is no different. The Service Fabric SDK has some great tools for building out large complex systems of systems. It does this without a lot of the typical overhead you would normally have and saves the time you would spend thinking about what to do. Service communication, distribution patterns, scale patterns, service discovery – all are built right in. So, stop re-building that stuff over, and over, and over, and over again.
Have your own awesome communication stack? Just generally don’t like Microsoft? (You know who you are…) Good news! You don’t have to use their SDK. Any of it, really. You can use any communication stack, any communication protocol, or communication technology. The only thing you have to do is register your apps location so it can be found by the name service.
Whhhaatttt?!?! I know it seems like a bizarro world for Microsoft, but you can indeed run Service Fabric in Linux. You can also run Java, Node, Ruby, or any other kind of language project you want to on it. Because remember, at its heart, it is just a deployment management system.
The assumption is that you have to have Azure in order to leverage Service Fabric, which isn’t even slightly the case. You can leverage Service Fabric in your own data center or on any other cloud provider’s infrastructure. Granted, if you go down that path, you have to manage your own cluster, but that is always the trade-off.
If I hear one more person say, “I wouldn’t use Service Fabric because I’m using containers,” I’m going to scream. I have a lot of issues with the current mindset about containers in general, which is outside the scope of this article, but if you really feel that containers are a must have (reach out to me on linkedin; I’d love to know why you think that), then just know you can use Service Fabric to manage your container deployments as well as your application deployments. It has great support for containers and having containers still doesn’t solve 99% of the complexities of having a distributed system with runtime dependencies. Service Fabric’s SDKs do.
Special thanks to Chase Aucoin who contributed this article. Chase does consulting on Service Fabric, microservices, and anything .NET for Keyhole Software. You may see him around at various dev conferences as a speaker on the topics.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
