Question 204588 in Azure Question posted in
The official documentation to get you started can be found here.

Alternative to Hangfire in Azure world

i’m using from several time Hangfire with SQL and i don’t have any problem.

Classic use cases that i will have are:

  1. From a web app, user enqueue an operation and can check all pending operations. Where operation ends he has a notification via SignalR and can check output of a job.
    An example is the same Azure Portal, where every operation is enqueued and status is visible in the bell on top right.
  2. Recurring job that runs every few seconds to perform scheduled operations indipendent from user’s interaction. Jobs must have a lock concept, so until one is running, nothing else of the same type should start for that user.

Recently i’m moving to Azure, using k8s for some microservices. I think that i will use a microservice with Hangfire, do you thiks that Hangfire and microservices can coexist?

If i don’t use Hangfire i have to replicate something similar using Azure Function (high cost), manage a storage for job’s state, so will worth it using something different?

How do you manage these scenario in microservice architecture?
Bye

I’m working on running Hangfire in a dockerized microservice.

Tags:

2

Answers


  1. 0

    Since you are using Kubernetes on the server you can use CronJobs.
    https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

    The upside to this instead of using Hangfire is that you have a pod for each actual job that is executed.

    There is also no extra pod that is running just to support hangfire itself as the K8 is managing that on its own.

    Additionally there are certain patterns can be used to have parallel execution for your jobs and maximizing the usage of K8
    https://kubernetes.io/docs/concepts/workloads/controllers/job/#job-patterns

    The downsides:
    Hangfire has a nice dashboard which you will have to replace with something like grafana or any other dashboard.

    Hangfire has the job details and state in the database – will have to adjust your jobs to work stateless and only with the cronjob config files and logs.

    Login or Signup to reply.
  2. 0

    @misha130 thanks for reply. In addition i’m also evaluating to process job handling messages from service bus, but i’ve found several issues:

    1. i have long jobs so i have to deal with autonewlock property

    2. i have to build a database that replicate status persistance as i have with Hangfire.
      At the end i think i will provide an architecture like this:

      pod1 -> worker hangfire for specific queue (to scale based on queue length)

      pod2 -> worker hangfire for specific queue (to scale based on queue length)

      pod3 -> standard microservice without Hangfire

      …

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search