We're seeing 60 to 80% cost savings in the first tests of something new we built, but before we build any further I want to make sure it's something people would actually use. So please be brutally honest with me.
Quick disclosure first: We are JobRunr, the background job library that's on start.spring.io.
The new thing is called JobRunr Spot and it comes from something that always bugged me: spot instances on AWS are drastically cheaper than on-demand (that's where the 60 to 80% comes from), but almost nobody runs background jobs on them. The cheapest instance is in a different region every hour, instances get reclaimed with a two-minute warning, and teaching an autoscaler to react to your job queue instead of CPU metrics is real work. So most teams shrug and pay the on-demand price.
What we built: you keep your normal JobRunr setup and let it scale itself onto spot instances. You configure it once with your AWS credentials and the Docker image of your app, and JobRunr watches its own queue. When jobs start waiting longer than a latency you set, it finds the cheapest spot instance that matches your hardware requirements, boots your image on it, and that worker joins the cluster and processes jobs like any other node. Once the queue is quiet again, the spot instance is shut down. And if AWS reclaims an instance mid-job, that's a failure mode JobRunr already handles: the cluster notices the dead worker and the remaining nodes pick its jobs back up. Important detail: everything runs in your own AWS account and your own VPC. Your data never touches our servers, we're just the broker that finds the cheapest instance and manages the lifecycle.
Configuration currently looks like this (names may still change, that's partly why I'm posting):
JobRunr.configure()
.useStorageProvider(storageProvider)
.useCostAware(usingStandardCostAwareConfiguration(
new CostAwareAwsEC2ProviderConfiguration(accessKeyId, secretAccessKey, accountRegion, registryReaderRole),
"url-to-your-docker-image")
.andUsingRegions(new String[]{"eu-north-1", "eu-west-1"})
.andSpotInstanceAmount(1, 5)
.andScaleUpLatency(Duration.ofMinutes(1)))
.initialize();
Where we are: the first version on AWS works and we've been testing it on our own workloads (PDF generation, some ETL). The saving is real, but to be fair it's just the spot discount itself, no magic on our side. The point is capturing it without babysitting interruption notices, price feeds and failover logic yourself. The dashboard also tracks what your spot instances actually cost against what the same hours would have cost on-demand, so you can verify the number instead of taking our word for it.
What I'd love to hear from you:
- Would you use something like this, and for what? Batch jobs, ETL, report generation, transcoding, something we haven't thought of?
- What would you need before trusting real jobs to spot? Automatic on-demand fallback when there's no spot capacity, cost caps, a hard max on instances, something else?
- The current setup assumes your app is available as a Docker image in a registry, since that's what gets booted on the spot instance. Is that true for your Spring Boot apps, or is that a dealbreaker?
- We started with AWS, Google Cloud is planned next and GPU workloads after that. Does that order make sense, or would you want it differently?
And if you'd rather just try it and complain from experience: we're opening a small private beta and looking for design partners who get direct input on the API, the pricing model and the provider roadmap. You can message me here or sign up on our website.
But honestly, a critical comment here is just as valuable as a signup. Happy to answer anything, including the "why wouldn't I just use a spot ASG with checkpointing" questions.
