Microservices and Service Fabric?
-
We have been using Service Fabric to host microservices for about a year while now. We created a few Stateless services with minimal use of the SF SDK so most of the time when developing you can ignore the fact they are hosted in SF, and moving away from SF should not be too expensive. You can run the SF host on your dev machine, but because we have kept the SF references to just the 'shell' we can also run the services locally in a console host if you want, which makes dev a little easier. Our deployments are via Octopus, which does have some built-in support for SF deployments, not great but you can get it running smoothly with a little fiddling. Later versions of Octopus might be better at this now. What I really like about SF is that zero-downtime deployments are easy and it manages the drain-stopping of load balancer for you. You can package up multiple services into single application package that is deployed as a unit (and rolled back as a unit in the case of failure), which is great, but of course, if you want that you should be thinking of containers anyway. So, we are looking at moving to containers this year (it is the MS recommended direction of travel too). You can currently host containers in SF but it is a bit awkward and there is some new stuff in the pipeline (Seabreeze) that supports server-less hosting of containers which is where I think we will end up. Adam
adambl wrote:
and moving away from SF should not be too expensive
Sounds good, especially taking Afzaal's comment into consideration. I deploy using VSTS, I'm guessing Microsoft has made deployment using their own products seamless (it's literally a button click for App Services).
adambl wrote:
we are looking at moving to containers this year (it is the MS recommended direction of travel too)
Are you saying SF will be discontinued in favor of Docker and Kubernetes or that it's better to take that route right away?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Sander Rossel wrote:
How is scaling up and down servers and spinning up new instances dynamically incredibly simple?
What does that have to do with microservices? (It's quite possible I'm demonstrating my ignorance of the topic here -- foot in mouth time?)
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Prepare to chew some foot :D One reason to work with microservices is that you can deploy the services independently. If you have a sales service and a stock service you can implement new features in sales and deploy them as a single unit, no need to build and test stock so deployments should be fast and cheap (and different teams can work on and deploy different services independently). That also means, unlike traditional monoliths, that some parts of the system can be way busier than others. Since the stock service is used by the sales, production, and purchasing services it's probably a lot busier than any of those other services. What Service Fabric (or Kubernetes) can do for you is scale up a couple of extra instances (on different servers if need be) of the stock service if the load is heavy and scale them down when the load decreases. Service Fabric also takes on the role of a load balancer in that case. Another benefit is that if you have multiple instances on different servers you can update a server and still have at least one instance of a service so a server update has no downtime for your applications. And, of course, the same goes for deployments, no downtime whatsoever :)
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
adambl wrote:
and moving away from SF should not be too expensive
Sounds good, especially taking Afzaal's comment into consideration. I deploy using VSTS, I'm guessing Microsoft has made deployment using their own products seamless (it's literally a button click for App Services).
adambl wrote:
we are looking at moving to containers this year (it is the MS recommended direction of travel too)
Are you saying SF will be discontinued in favor of Docker and Kubernetes or that it's better to take that route right away?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I haven't any knowledge of the MS roadmap for SF, but I guess they would keep support for both SF Apps and containers for the foreseeable future. For some (i.e. those .Net devs without container experience) the barrier to entry is lower for SF apps, as you can Project->New in VS, then right click and publish your app direct to SF. But as soon as you have multiple services to deploy as a unit, containers are your friend, and worth getting to grips with the new tech. Obviously if you are using containers outside the MS ecosystem, the fact MS now support them means that the entry barrier for you to start using MS hosting has lowered. Keeping both means that MS keeps both groups of people happy (= paying customers).
-
It seems my current project needs to hop on the Microservices boat. Does anyone have experience with Microservices on Service Fabric in Azure? If so, how's the learning curve, what are the gotcha's, and how's your overall experience? For now it seems I'll have four or maybe five services of which one or two will be web APIs. The others will read from a Service Bus queue.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
sorry for the late reply I love SF and highly recommend it. I used it for ~ 1 year and half. I will talk about the first version, a new one will soon complement it (without discontinuing the 1st) You can build highly scalable (planet scale) and reliable apps with just C# , visual studio (integrates perfectly) and an azure subscription. Containers are optional but you can do without. you need approximately 1 week to get started (the doc is excellent) 2 weeks start tinkering and 1 month to start being productive SF enforces some interesting paradigms to write better microservices apps . I love their reliable actors paradigm. The new version will target a "Serverless" approach so it will be quite different and containers here are required. I have not yet studied it but I'm sure the team will make a great work as usual. There is a great team with nice people, always ready to support the community, they do a monthly meeting, you could join to have a look (but community makes deep tech questions) Go for it ;) Antonio
-
sorry for the late reply I love SF and highly recommend it. I used it for ~ 1 year and half. I will talk about the first version, a new one will soon complement it (without discontinuing the 1st) You can build highly scalable (planet scale) and reliable apps with just C# , visual studio (integrates perfectly) and an azure subscription. Containers are optional but you can do without. you need approximately 1 week to get started (the doc is excellent) 2 weeks start tinkering and 1 month to start being productive SF enforces some interesting paradigms to write better microservices apps . I love their reliable actors paradigm. The new version will target a "Serverless" approach so it will be quite different and containers here are required. I have not yet studied it but I'm sure the team will make a great work as usual. There is a great team with nice people, always ready to support the community, they do a monthly meeting, you could join to have a look (but community makes deep tech questions) Go for it ;) Antonio
AReady wrote:
you need approximately 1 week to get started (the doc is excellent) 2 weeks start tinkering and 1 month to start being productive
I need it implemented yesterday :laugh:
AReady wrote:
The new version will target a "Serverless" approach so it will be quite different and containers here are required
Interesting! Do you know what this version is called?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
AReady wrote:
you need approximately 1 week to get started (the doc is excellent) 2 weeks start tinkering and 1 month to start being productive
I need it implemented yesterday :laugh:
AReady wrote:
The new version will target a "Serverless" approach so it will be quite different and containers here are required
Interesting! Do you know what this version is called?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
>
Quote:
I need it implemented yesterday
Take it easy, while doc is great and SF very interesting, you'll need some time to properly grasp and apply the new paradigms.
Quote:
Interesting! Do you know what this version is called?
it's called Service fabric mesh, I guess it's still preview, I have not studied it yet. Here are a couple of links Azure Service Fabric at Microsoft Build 2018 | Blog | Microsoft Azure[^] Azure Service Fabric: The road ahead for microservices | Microsoft Build 2018 | Channel 9[^] Best regards Antonio
-
>
Quote:
I need it implemented yesterday
Take it easy, while doc is great and SF very interesting, you'll need some time to properly grasp and apply the new paradigms.
Quote:
Interesting! Do you know what this version is called?
it's called Service fabric mesh, I guess it's still preview, I have not studied it yet. Here are a couple of links Azure Service Fabric at Microsoft Build 2018 | Blog | Microsoft Azure[^] Azure Service Fabric: The road ahead for microservices | Microsoft Build 2018 | Channel 9[^] Best regards Antonio
AReady wrote:
it's called Service fabric mesh
Cool :thumbsup:
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
