Spring Boot - Running one specific background job per pod

Question

I'm coming from the PHP/Python/JS environment where it's a standard to run multiple instances of web application as separate processes and asynchronous tasks like queue processing as separate scripts.

eg. in the k8s environment, there would be

• N instances of web server only, each running in separate pod
• For each queue, dynamic number of consumers, each in separate pod
• Cron scheduling using k8s crontab functionality, leaving the scheduling process to k8s

Such approach matches well the cloud nature where the workload can be scheduled across both smaller number of powerful machines and lot of less powerful machines and allows very fine control of auto scaling (based on the number of messages in specific queue for example).

Also, there is a clear separation between the developer and DevOps responsibility.

Recently, I tried to replicate the same setup with Java Spring Boot application and failed miserably.

Even though Java frameworks say that they are "cloud native", it seems like all the documentation is still built around monolith application, which handles all consumers and cron scheduling in separate threads.

Clear answer to this problem is microservices but that's way out of scope.

What I need is to deploy separate parts of application (like 1 queue listener only) per pod in the cloud yet keep the monolith code architecture.

So, the question is:

How do I design my Spring Boot application so that:

• I can run the webserver separately without queue listeners and scheduled jobs
• I can run one queue listener per pod in the k8s
• I can use k8s cron scheduling instead of App level Spring scheduler?

I found several ways to achieve something like this but I expect there must be some "more or less standard way".

---

Alternative solutions that came to my mind:

• Having separate module with separate Application definition so that each "command" is built separately
• Using Spring Profiles to instantiate specific services only according to some environment variables
• Implement custom command line runner which would parse command name/queue name and dynamically create appropriate services (this seems to be the most similar approach to the way how it's done in "scripting languages")

What I mainly want to achieve with such setup is:

• To be able to run the application on lot of weak HW instead of having 1 machine with 32 cpu cores
• Easier scaling per workload
• Removing one layer from already complex monitoring infrastructure (k8s already allows very fine resource monitoring, application level task scheduling and parallelism makes this way more difficult)

Do I miss something or is it just that it's not standard to write Java server apps this way? Thank you!

Answer 1

What I need is to deploy separate parts of application (like 1 queue listener only) per pod in the cloud yet keep the monolith code architecture.

I agree with @jacky-neo's answer in terms of the appropriate architecture/best practice, but that may require you to break up your monolithic application.

To solve this without breaking up your monolithic application, deploy multiple instances of your monolith to Kubernetes each as a separate Deployment. Each deployment can have its own configuration. Then you can utilize feature flags and define the environment variables for each deployment based on the functionality you would like to enable.

In application.properties:

myapp.queue.listener.enabled=${QUEUE_LISTENER_ENABLED:false}

In your Deployment for the queue listener, enable the feature flag:

env:
  - name: 'QUEUE_LISTENER_ENABLED'
    value: 'true'

You would then just need to configure your monolithic application to use this myapp.queue.listener.enabled property and only enable the queue listener when the property is set to true.

Similarly, you could also apply this logic to the Spring profile to only run certain features in your app based on the profile defined in your ConfigMap.

This Baeldung article explains the process I'm presenting here in detail.

For the scheduled task, just set up a CronJob using a curl container which can invoke the service you want to perform the work.

Edit

Another option based on your comments below -- split the shared logic out into a shared module (using Gradle or Maven), and have two other runnable modules like web and listener that depend on the shared module. This will allow you to keep your shared logic in the same repository, and keep you from having to build/maintain an extra library which you would like to avoid.

This would be a good step in the right direction, and it would lend well to breaking the app into smaller pieces later down the road.

Here's some additional info about multi-module Spring Boot projects using Maven or Gradle.

Answer 2

According to my expierence, I will resolve these issue as below. Hope it is what you want.

I can run the webserver separately without queue listeners and scheduled jobs

Develop a Spring Boot app to do it and deploy it as service-A in Kubernetes. In this app, you use spring-mvc to define the controller or REST controller to receive requests. Then use the Kubernetes Nodeport or define ingress-gateway to make the service accessible from outside the Kubernetes cluster. If you use session, you should save it into Redis or a similar shared place so that more instances of the service (pod) can share same session value.

I can run one queue listener per pod in the k8s

Develop a new Spring Boot app to do it and deploy it as service-B in Kubernetes. This service only processes queue messages from RabbitMQ or others, which can be sent from service-A or another source. In most times it should not be accessed from outside the Kubernetes cluster.

I can use k8s cron scheduling instead of App level Spring scheduler?

In my opinion, I like to define a new Spring Boot app with spring-scheduler called service-C in Kubernetes. It will have only one instance and will not be scaled. Then, it will invoke service-A method at the scheduled time. It will not be accessible from outside the Kubernetes cluster. But if you like Kubernetes CronJob, you can just write a bash shell using service-A's dns name in Kubernetes to access its REST endpoint.

The above three services can each be configured with different resources such as CPU and memory usage.